在工厂、物业、能源电力这些需要定期巡检的场景里，有一个反复被提起的问题：巡检记录填得好好的，设备该坏还是坏，隐患该出还是出——因为根本没人真正到现场检查。

这事不是某家公司的个别情况，在中小企业的巡检管理里非常普遍。原因也不是员工素质或管理不严，而是传统的记录方式本身给了作假空间——纸质签到表也好、Excel 台账也好，能记录的只是"我说我来过"，不能证明"我真的来过"。管理者看得见记录，看不见记录背后的动作，中间这一段全靠员工的诚信承诺。

草料二维码做过大量中小企业的巡检数字化项目，下面结合这些经验，分享一套具体的做法——如何有效防止假检和漏检。

一、常见的 4 种作假行为

管理现场的人大概都见过这几类：

第一种：未到场补填。 纸质巡检表最普遍的问题。巡检员找一个空闲时段，把整周的检查项一次性填齐，签字盖章，记录上一切正常。实际一次现场都没去过。

第二种：他人代检。 张三排了巡检任务，临时有事让李四帮忙扫码拍照。记录上的责任人和实际操作人对不上，一旦出现问题难以厘清责任。

第三种：到岗走过场。 人到了现场，但没按检查项逐条核查——到点位扫码签到即离开，仪表读数、设备外观、液位高度等关键项完全没看。

第四种：旧照片造假。 系统要求上传现场照片之后，有人开始把之前的照片存下来重复上传，或者随手拍张模糊的图片应付。

二、如何防止假检行为

针对上面这 4 种作假行为，除了在管理方面进行规范（比如更严的抽查、双人互检、巡查督办），比较常见的是通过技术手段进行限制，目的是提升作假的门槛，从而保障工人到点到位检查。
常见的技术手段大致分几类：

• 硬件类（门禁刷卡、蓝牙信标、NFC 工牌等做到岗验证）
• 物联网类（在设备上安装传感器自动采集数据，脱离人工）
• AI 视觉类（现场架设摄像头识别行为异常）
• 二维码巡检类（如草料二维码，通过二维码实现到场触发、云端自动记录防作假信息）

前三类对硬件投入、网络条件和运维能力都有较高要求，主要用在预算充足的大型工厂。对大多数中小企业而言，更建议采用二维码巡检，主要原因有三点：

• 成本低：每台设备贴一张标签，单张成本仅几分钱，无需采购硬件
• 使用门槛低：巡检员通过微信扫码即可操作，不需要下载 APP 或额外培训
• 实施门槛低：防作假机制均为系统内的开关式配置，无需 IT 部门介入，当天即可上线

下面以草料二维码为例，说明如何通过功能配置减少上述假检行为。

1. 防止未到场补填：扫码触发 + 定位限制

第一种作假的成本最低，所以第一层防线必须最严。思路是让表单的触发方式本身要求人在现场。

具体做法是两层叠加：

一是把表单设置为仅限微信"扫一扫"填写。巡检员必须持手机到达设备前、对着实物二维码扫描，表单才会出现。把二维码保存成图片再扫、在小程序里搜到码、通过分享链接在别处打开——这几种常见的远程提交方式都触发不了表单。

二是开启定位限制。系统在提交表单时会校验手机地理位置，只有当前位置在该点位允许范围内才能成功提交。超出范围直接拦截，不给保存、不给补交。

这两个功能，能有效保证工人到场，从而避免坐办公室补填——不到设备前拿不到表单，到了假设备面前也会因为定位不对被拦。

2. 防止他人代检：姓名自动关联 + 手写签名

第二层要解决的是"人是去了，但不是应该去的那个人"。这个问题靠到场验证解决不了，得在身份上做约束。

具体做法也是两层：

一是后台可提前录入巡检人员名单，扫码后系统自动关联提交人姓名。每一条巡检记录都带上当前账号的身份信息，责任归属清晰，事后复盘一眼能看出是谁提交的。

二是在表单里加入手写签名组件。对身份敏感的场景（特种设备、消防、安全抽查），要求巡检员在手机上亲笔签名后才能提交。签名图像和这条记录绑定，追责时有据可查。

代检这件事的核心不是禁止，是让代检的成本上升——代的人要用自己账号、要签自己的名，一旦出问题责任先落到代检人头上。

3. 防止到岗走过场：AI 图片审核 + AI 智能填表

人到了现场但不检查，是最难治的一种。因为它看起来"人到了"——扫码对了、定位对了、也提交了，只是没真看设备。

这类情况有两层做法：

一是开启 AI 图片审核。巡检员上传现场照片时，AI 自动判断这张照片是不是拍了指定设备、画面是否清晰可辨、是否能看到关键部位。不达标的照片直接被拦下，提示重新拍摄。

二是启用 AI 智能填表。巡检员拍一张仪表照片，AI 识别读数自动填到对应栏位，再由人工复核确认。既减少手填的偷懒空间，也让"随手填个数字应付"这条路走不通。

这一层做完，走过场的成本从"扫码随手拍一张"上升到了"必须拍清楚、必须拍对地方"。

4. 防止旧照片造假：仅限拍照 + 防作假水印

有人会存上次的照片或者网上找张设备图糊弄，这是拍照上传被加进流程之后出现的新套路。

可通过下面两个功能进行避免：

一是把图片字段设为仅限拍照。现场留证的照片只能当场拍，不允许从相册里选已有图片。旧照片因为不能从相册上传而自动失效。

二是开启防作假水印。拍完照系统自动在照片上叠加水印，内容包括记录人姓名、拍摄时间（精确到秒）、当时定位、关联的二维码信息。水印直接写进图片像素，事后不能去除。如果有人想截屏之后再拍一张伪造，时间和定位对不上也会露出破绽。

三、到期没去检查：周期任务 + 漏检提醒

还有一类常见情况性质不一样，是"漏检"：不是作假，是排班漏了、当天忘了、交接班没交代、人员流动接不上。这种情况光靠技术拦截治不住，得靠系统主动提醒 + 漏检可追溯。

可通过以下方式减少漏检：

• 在后台为每个设备或点位配置巡检周期和责任人，日常巡检、周检、月度保养都可以设
• 到期前系统自动推送提醒到责任人的微信
• 超期未完成系统自动标注漏检，同步通知一级主管
• 管理者后台看得到全员、全设备的漏检状态，按科室、按周、按设备筛选都行

漏检的根源是"没人提醒、没人追踪"，靠人工盯很难盯全。系统层面自动提醒 + 自动标红之后，这件事从"要不要去检查"变成"不去会被系统看到"。草料二维码里这套机制叫周期任务，配置完就自行运转，不需要管理者手动追人。

小结

工人不去现场检查这件事的本质，不是人的问题，也不是管理不严的问题，是传统的记录方式给了作假空间。纸笔签字、口头汇报、甚至电子化之后的简单表单，都只能记录声明，不能验证动作。

治理这件事的思路不是抓人或喊话，而是让记录方式本身能验证到场行为——扫码要人在现场、定位要落在点位、照片要当场拍、签名要亲笔签。每一种常见的作假都有一层对应的技术拦截，配完之后作假的成本就高过正常去检查的成本，自然没人走这条弯路。

Gitea Enterprise 25.5.0 (Linux, macOS, Windows) - 本地部署的企业级 Git 服务

The Premier Enterprise Solution for Self-Hosted Git Service

请访问原文链接：https://sysin.org/blog/gitea/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

自托管 Git 服务的首要企业解决方案

什么是 Gitea Enterprise

Gitea Enterprise 是基于开源 Gitea 项目开发的增强版。

Gitea Enterprise 提供更可靠的体验并满足企业级用户的要求。Gitea Enterprise 的设计理念是轻量级、易于使用且高度可定制，使其成为小型团队和大型组织的理想选择。

Gitea Enterprise 是基于开源 Gitea 项目开发的 (sysin)，两者有着相似的经验。熟悉 Gitea 的用户可以快速上手 Gitea Enterprise，操作和配置方法几乎相同。

然而，Gitea Enterprise 是为了满足企业用例的需求而构建的。需要注意的是，这些功能需要付费才能激活。

如果您对价格有疑问，可以申请免费试用。试用期为 30 天，在此期间您可以免费使用 Gitea Enterprise 的所有功能。试用期结束后，您可以选择继续使用 Gitea Enterprise，其功能与开源 Gitea 项目相同。

主要优势

• 1. 分支保护继承

  Gitea Enterprise 通过继承功能增强了分支保护，允许您为组织创建分支保护规则，并使其在组织的所有存储库中生效。

• 2. 依赖关系扫描

  自动识别并解决项目开源依赖项中的漏洞。

• 3. 高级安全功能

  Gitea Enterprise 引入了 IP 白名单等高级安全功能，通过限制对某些 IP 地址的访问来增强 Gitea 实例的安全性。它还通过强制双因素身份验证增强了帐户安全性。

• 4. 企业主题

  Gitea Enterprise 提供精心设计的主题，可提供更好的体验 (sysin)，允许您个性化您的用户界面，并与 Gitea 开源项目区分开来。

• 5. SAML 身份验证

  借助 Gitea Enterprise，您可以将 Gitea 配置为 SAML 2.0 服务提供商，从而与企业的身份提供商无缝集成。

• 6. 审核日志

  Gitea Enterprise 提供全面的审核日志功能，为您提供 Gitea 实例内发生的活动的深入历史记录。

新增功能

Gitea Enterprise v25.5.0, 2026-04-19

发行说明未公布，通常为安全更新和常规 Bug 修复。

下载地址

历史版本：

• Gitea Enterprise v24.3.0, 2025-07-22
• Gitea Enterprise v24.5.0, 2025-08-16
• Gitea Enterprise v24.6.0, 2025-10-15
• Gitea Enterprise v24.7.0, 2025-12-02
• Gitea Enterprise v24.8.0, 2026-01-27
• Gitea Enterprise v25.4.2, 2026-02-25
• Gitea Enterprise v25.4.3, 2026-03-05
• Gitea Enterprise v25.5.0, 2026-04-19

Gitea Enterprise v25.5.0, 2026-04-19

• 请访问：https://sysin.org/blog/gitea/

  • Gitea for Linux x64
  • Gitea for Linux arm64
  • Gitea for macOS x64
  • Gitea for macOS arm64
  • Gitea for Windows x64
  • Gitea for FreeBSD 14 x64

数据丰富，决策滞后

零售行业是数据密集型行业的典型代表。从POS收银、会员系统、供应链WMS，到电商平台的实时订单流——零售企业产生的数据量远超大多数传统行业。但讽刺的是，这些企业在做关键决策时，看的依然是昨天的报表。

「618大促期间，运营团队早上8点看到的库存数据，其实是凌晨2点的快照。」这是某头部鞋服品牌CIO在内部复盘时的原话。更要命的是，当他们发现某款爆品库存告急时，数据还没来得及更新，补货决策已经延误了黄金6小时。

这不是个例，我们接触的零售企业，超过70%的零售企业仍在使用T+1甚至更慢的数据同步模式。这意味着，当消费者在线下门店完成购买、当电商平台产生新订单、当仓储系统发生出库——这些业务动作产生的数据，要等12到24小时才能出现在管理者的看板中。

问题的根源不在于零售企业不重视数据，而在于数据架构的设计假设与业务需求之间存在根本性错配。

滞后的根源：T+1批处理的架构缺陷

1.批处理模式的工作原理

传统ETL的数据同步逻辑是「定时批量抽取」：每天凌晨业务低峰期，系统从源数据库执行全量或增量SQL查询，将数据导出、转换、加载到数据仓库，这个过程通常需要2-6小时，取决于数据量大小。

这个模式在2010年代是合理的——彼时零售业务变化慢、渠道单一、T+1数据足够支撑周级决策。但2026年的零售环境已经完全改变：

• 渠道碎片化：线下门店、电商、直播、社群——同一款商品在多个渠道同时销售，库存数据必须实时打通；
• 促销即时化：秒杀、限时折扣需要分钟级的库存反馈，批处理根本无法支撑；
• 客户体验预期升级：会员积分即时查询、门店缺货实时调拨——用户已经习惯「所见即所得」；

2.批处理的三个结构性缺陷

从架构层面分析，T+1批处理存在三个无法通过优化解决的本质问题：

更致命的是，批处理模式下的BI报表只能回答「发生了什么」，而无法支持「正在发生什么」和「将要发生什么」，这在促销常态化、库存波动剧烈的新零售时代，是结构性能力的缺失。

实时数据的价值：从「后视镜」到「仪表盘」

1.库存预警：从「等断货」到「防断货」

传统模式下，库存预警依赖历史销售数据的趋势外推，但实时数据让这一切改变：

实时库存监控场景：

当某SKU的实时销量达到过去7天平均销量的3倍时，系统自动触发「爆品预警」，同步通知采购端补货、运营端调整推荐权重、客服端准备缺货话术，这个响应时间，从原来的「等报表出来再说」压缩到「实时感知即时响应」。

2.动态定价：分钟级价格弹性

某连锁商超的实践表明：接入实时销售数据后，动态定价系统可以在15分钟内完成价格调整决策，而传统模式需要等到第二天才能看到昨天的销量数据，再做下一天的价格决策，这个时间差，在大促期间意味着数百万的GMV差距。

3.精准营销：行为触发的即时响应

会员在门店扫码关注公众号——这个动作在传统架构下要等第二天才被数据系统感知，在实时架构下，可以做到：

• 扫码后30秒内，短信/小程序推送新人优惠；
• 结合实时门店客流数据，在低峰期向周边用户推送到店折扣；
• 会员购买完成后，即时更新会员等级和积分，支持实时兑换；

图：CDC技术通过数据库日志监听实现毫秒级变更捕获

CDC技术：解决思路与原理

1.CDC的核心原理

CDC（Change Data Capture，变更数据捕获）的核心思路与批处理完全相反：不是定时去问「数据变了没」，而是让数据库主动告诉你「数据刚变了」。

具体实现上，CDC通过监听数据库的Write-Ahead Log（WAL）或事务日志来实现：

• 源端数据库发生INSERT/UPDATE/DELETE操作；
• 日志层记录变更（CDC读取binlog/redo log/WAL）；
• CDC组件解析日志，提取变更数据；
• 消息队列（Kafka/Pulsar）接收变更事件；
• 消费端实时处理并写入目标系统；

整个链路端到端延迟可以从批处理的12-24小时压缩到500毫秒以内。

2.技术选型对比

CDC领域的主要技术方案对比如下：

3.为什么零售企业需要CDC而不是批处理

我见过很多零售企业的数据团队在选型时陷入「功能对比」的陷阱——比连接器数量、比组件丰富度，但对于零售场景，核心判断标准只有一个：能否支撑业务实时响应。

CDC相比批处理的核心优势：

• 延迟降低99%：从T+1到准实时；
• 资源消耗平稳：无夜间峰值，数据库负载稳定；
• 故障影响小：实时消费，延迟可控，不会累积；
• 事件驱动架构：天然支持业务事件响应；

实施路径：从单点到全链路的实时化改造

很多企业一听到「实时化改造」就想着推倒重来——这往往是把小事做大的典型误区，正确的路径是从单点突破到全链路覆盖。

• 第一步：选择高频痛点场景切入

  优先选择「数据变更频率高 + 业务决策依赖实时性」的场景，零售企业中，库存同步和订单状态是两个最佳切入点。

  建议：选取1-2个核心业务线做试点，不求全，先验证技术可行性。

• 第二步：CDC链路搭建与验证

  配置源端数据库的CDC功能（MySQL binlog、PostgreSQL WAL、SQL Server CDC等），通过消息队列建立到目标系统的实时同步链路，关键验证点：延迟指标、丢失率监控、断点续传能力。

  

  图：可视化界面配置，降低实施门槛

• 第三步：消费端改造

  CDC同步的数据需要被消费端正确处理：

  BI看板：支持实时数据刷新，而非定时刷新；

  业务系统：订阅变更事件，触发业务流程；

  数据仓库：实时入仓，支持OLAP查询；

• 第四步：全链路覆盖

试点验证成功后，逐步扩展到更多业务线：

会员域：注册、积分、等级变更实时同步；

商品域：价格、库存、上下架状态；

营销域：活动效果、用户行为实时追踪；

实施注意事项

• 源库负载控制：CDC读取日志本身对源库影响很小，但要监控连接数和并发查询；
• 数据一致性：消息队列消费需要幂等设计，防止重复消费导致数据不一致；
• Schema变更处理：源表结构变更（DDL）是CDC的难点，需要版本管理和灰度切换；
• 全量与增量切换：历史数据迁移阶段需要全量+增量并行，确保无数据丢失；

总结：实时化不是升级，是范式转换

很多企业在讨论数据架构时，喜欢用「升级」这个词——批处理升级到实时，T+1升级到T+0，但我认为这是误导性的表述，实时化不是批处理的增强版，而是一种完全不同的数据处理范式。

批处理模式隐含的假设是：数据是「状态」，我可以接受昨天的状态，实时模式隐含的假设是：数据是「事件」，我需要感知每一个事件的发生。

2026年的零售行业，渠道在融合、促销在实时、用户在流动——只有事件驱动、实时感知的数据架构，才能支撑这种业务节奏。

全文链接：https://tecdat.cn/?p=45629
原文出处：拓端数据部落公众号

• • *

关于分析师
!
在此对 YouMing Zhang 对本文所作的贡献表示诚挚感谢，他在东北大学完成了信息与计算科学专业的学士学位，专注 机器学习 **与深度学习算法领域。擅长 Python、Matlab、神经网络建模与数据分析。曾在多个行业数据挖掘项目中承担算法设计与模型优化工作，对图神经网络在分子性质预测中的应用具有丰富实践经验。

• • *

摘要

本文基于图神经网络框架，构建多层图卷积网络对分子亲脂性（logD）进行回归预测。采用 Lipophilicity 数据集，将分子表示为图结构，节点为原子、边为化学键，通过三层图卷积与全局池化聚合整图特征，输出连续型 logD 值。文中详细展示了数据预处理、图结构可视化、模型设计与训练评估全流程，并针对训练过拟合与测试泛化能力进行多维度分析。结果表明，模型在训练集上拟合良好，测试集预测趋势清晰，可为分子性质预测研究提供可复现的技术路径。

一、选题背景与研究意义

亲脂性是衡量药物分子在生物体内分布与渗透能力的关键指标，直接影响候选化合物的成药性。传统实验测定 logD 耗时且成本较高，利用机器学习从分子结构直接预测该性质已成为计算化学的重要方向。图神经网络能够天然地处理分子拓扑结构，将原子属性与键连关系编码为图信号，通过消息传递机制学习分子整体表示，相较于传统分子指纹或描述符方法更具表达优势。

本研究从实际项目咨询积累的技术方案出发，基于图卷积网络实现分子级回归预测，旨在为相关领域研究人员提供一套端到端的建模参考。

本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群获取完整代码数据及更多最新AI见解和行业洞察，可与900+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路；遇代码运行问题，更能享24小时调试支持。

整体技术路线如下图所示：

        ┌─────────────────────┐
        │  Lipophilicity 数据  │
        │  (SMILES → 分子图)   │
        └──────────┬──────────┘
                   ▼
        ┌─────────────────────┐
        │  图数据预处理与划分  │
        │  (节点特征/边索引)   │
        └──────────┬──────────┘
                   ▼
        ┌─────────────────────┐
        │  三层 GCN + 全局池化 │
        │  (图嵌入 → 回归输出) │
        └──────────┬──────────┘
                   ▼
        ┌─────────────────────┐
        │  训练与超参数调优    │
        │  (MSE损失, Adam优化) │
        └──────────┬──────────┘
                   ▼
        ┌─────────────────────┐
        │  测试评估与可视化    │
        │  (R², 预测对比曲线)  │
        └─────────────────────┘

二、数据来源与预处理全流程

数据集包含 4200 个化合物的 SMILES 序列及其实验测定的 logD 值（pH=7.4）。通过 PyTorch Geometric 内置的 MoleculeNet 接口可直接加载，每个分子自动转换为 Data 对象：x 为节点特征矩阵（9 维原子属性），edge_index 为边连接关系，edge_attr 为键类型编码，y 为目标 logD 值。

首先引入所需库，并对变量命名进行重构以增强可读性。

加载数据集并查看基本统计信息：

输出表明共 4200 个分子图，节点特征 9 维。首个分子包含 26 个原子与 56 条化学键。

分子结构可视化

为直观理解图数据与化学结构的对应关系，利用 pubchempy 与 RDKit 绘制前 12 个分子的结构图，并整理其节点数、边数与 logD 值。

表格展示了分子图规模与亲脂性值，部分 SMILES 较长，已用简称代替。

绘制首分子结构图：

first_smiles = lip_dataset[0].smiles

该化合物为 2-[[4-(4-氯苯基)哌嗪-1-基]甲基]-1-甲基苯并咪唑，logD 值为 3.54。

• • *

相关文章

DeepSeek、LangGraph和 Python 融合LSTM、RF、XGBoost、LR多模型预测NFLX股票涨跌|附完整代码数据

原文链接：https://tecdat.cn/?p=44060

• • *

前12个分子结构网格图如下，标题为简化后的 IUPAC 名称：

为进一步展示图结构，将两个分子的 PyTorch Geometric 图转换为 NetworkX 格式并绘制节点连接关系：

图中每个节点对应一个原子，边对应化学键，图的规模与分子大小直接相关。

三、模型选择逻辑与核心代码实现

针对图级别回归任务，设计包含三层图卷积与全局池化模块的网络架构。图卷积层负责逐层聚合邻域节点信息，生成更具表达力的节点嵌入；全局池化则通过均值池化与最大池化拼接，将节点级表示压缩为固定长度的图级向量，最后经线性层输出预测值。

模型实现代码如下（已对变量名做语义化重构，并省略部分非关键细节）：

注释：多层图卷积叠加有助于捕捉高阶邻域信息，但层数过多易导致过平滑。此处采用三层结构并在每一层后应用 tanh 激活，增强非线性表达能力。全局池化的拼接设计保留了不同粒度的图统计特征。

训练配置采用均方误差损失与 Adam 优化器，并划分 80% 数据用于训练，20% 用于测试。

若遇到 CUDA out of memory 报错，可将 batch size 调小或使用 CPU 训练；若损失不收敛，建议检查学习率与网络初始化。

四、模型结果对比与解读

训练过程共迭代 2000 个周期，记录每个周期的损失与决定系数（R²）以监控拟合情况。

epoch_cnt = 2000
loss_history = []
for epoch in range(epoch_cnt):
    avg_loss = train_one_epoch()
    loss_history.append(avg_loss)
    # 每100轮输出一次训练状态
    if epoch % 100 == 0:
        # 计算当前批次的 R² 近似值
        ...
        print(f"周期 {epoch:4d} | 损失: {avg_loss:.5f}")

训练曲线与预测-目标对比如下：

训练初期预测值波动剧烈，随周期增加逐渐逼近真实分布。最后 20 个周期的决定系数可达 0.98，但训练后期损失持续下降、训练集精度接近饱和，提示可能存在过拟合风险。损失与 R² 双轴图展示如下：

论文写作解读要点：训练曲线需同时观察损失下降趋势与验证集指标，若训练损失持续降低而验证损失上升，则需考虑早停或正则化。本案例未单独划分验证集，但可通过测试集表现进一步诊断。

五、稳健性检验与 模型优化 **步骤

采用预留测试集（840 个分子）评估模型泛化性能。测试集预测值与真实值对比散点图及前 20 个样本的对比如下：

测试集决定系数约为 0.49，显著低于训练集表现，表明模型存在一定程度过拟合。进一步分析发现，训练数据规模有限（3360 个分子），且分子结构多样性较高，模型倾向于记忆训练样本而非学习泛化规律。

优化方向建议：

1. 早停法：监控验证集损失，在性能不再提升时终止训练。
2. Dropout 或 L2 正则化：在卷积层后添加 Dropout 层，或增大权重衰减系数。
3. 数据增强：利用分子构象或虚拟筛选扩充训练样本。
4. 图同构网络替代：尝试 GIN 或 GAT 等更强大的图神经网络结构。

若论文写作中遇到模型泛化能力不足且缺乏调参方向，可联系获取一对一辅导，协助完成稳健性检验与模型选型论证。

六、研究结论与写作提示

本文详细展示了基于图卷积网络的分子亲脂性回归建模流程，涵盖数据加载、图可视化、模型构建、训练监控与测试评估各环节。核心结论如下：

• 三层 GCN 结合全局均值与最大池化能够有效提取分子图特征，训练集 R² 可达 0.98。
• 测试集性能下降提示过拟合，需引入正则化与验证机制以提升泛化能力。
• 图神经网络为分子性质预测提供端到端学习框架，相较于传统描述符方法更具灵活性。

导师答辩高频提问与参考应答：

• 问：为什么选择三层卷积而不是更多层？
  答：层数过多会导致节点表示过度平滑，丢失局部结构信息；三层在表达力与计算效率间取得平衡，且通过实验验证未出现明显欠拟合。
• 问：如何处理分子大小差异对池化的影响？
  答：全局池化本身对节点数量不敏感，最大池化与均值池化拼接能兼顾极端值与平均水平，适合不同规模的图。
• 问：测试集 R² 较低，如何证明模型有效性？
  答：可通过交叉验证、调整训练轮次及引入 Dropout 后重新评估，同时对比基线模型（如随机森林使用分子指纹）说明相对优势。

若在论文撰写中遇到变量设计合理性校验、模型适配性分析或代码复现困难，可获取免费代码预检服务，并进一步获得全流程学术合规辅导。

阅读原文进群获取完整内容及更多AI见解、行业洞察，与900+行业人士交流成长。
本文配套的论文建模可直接套用的完整代码包、实证分析，可加小助手微信：tecdat_cn领取，我们可提供全流程的辅助学术合规辅导、1v1建模陪跑服务，助力顺利完成科研、通过答辩。

摘要

之前写过Gotify：https://segmentfault.com/a/1190000047531644

现在又了解到一个无需部署服务的消息推送 - ntfy

相关链接：
https://f-droid.org/zh_Hans/packages/io.heckel.ntfy/
https://ntfy.sh/

下载客户端

https://github.com/binwiederhier/ntfy-android/releases

安装后，打开app创建一个订阅主题，自己命名，建议复杂一些，以免和别人一样。

服务端

只需要替换下方客户端的主题名称就行。

<?php

// 获取参数
$topic    = $_GET['topic']    ?? '客户端的主题名称';
$title    = $_GET['title']    ?? '';
$message  = $_GET['message']  ?? '';

// 过滤空值
$data = array_filter([
    "topic"    => $topic,
    "title"    => $title,
    "message"  => $message
], fn($v) => $v !== '' && $v !== null);

// 必填校验
if (empty($data['title']) || empty($data['message'])) {
    exit(json_encode(["ok"=>false,"error"=>"title/message 必填"], JSON_UNESCAPED_UNICODE));
}

// 默认 priority
$data['priority'] = $data['priority'] ?? 5;

// 👉 关键：确保 JSON 编码成功
$json = json_encode($data, JSON_UNESCAPED_UNICODE);

if ($json === false) {
    exit(json_encode([
        "ok" => false,
        "error" => "JSON编码失败: " . json_last_error_msg()
    ], JSON_UNESCAPED_UNICODE));
}

// 👉 用字符串长度避免某些服务器问题
$headers = [
    "Content-Type: application/json",
    "Content-Length: " . strlen($json)
];

// 发送
$ch = curl_init("https://ntfy.sh");

curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => $json,
    CURLOPT_HTTPHEADER => $headers,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT => 10
]);

$response = curl_exec($ch);

// 错误处理
if (curl_errno($ch)) {
    $result = ["ok"=>false,"error"=>curl_error($ch)];
} else {
    $result = ["ok"=>true,"res"=>json_decode($response)];
}

curl_close($ch);

header('Content-Type: application/json');
echo json_encode($result, JSON_UNESCAPED_UNICODE);

然后执行代码：

https:/xxx.com/ntfy/index.php?title=111&message=222

就可以PUSH消息给你手机了。

当然，记得将ntfy设置电池优化无限制，自启动，后台锁定。

本文作者

TANKING

在工业过程控制系统中，调节阀是实现流量、压力、温度等参数精准连续调节的核心组件。其性能直接关系到系统的运行稳定性和控制精度。对于化工、电力、能源以及水处理等需要长期连续运行的装置而言，调节阀的选型已成为影响项目整体可靠性的重要环节。

面对“2026进口调节阀品牌厂家推荐”这类查询，单纯列举品牌名称已难以满足工程需求。更合理的做法是从品质一致性、工况适配能力和控制性能三个维度展开分析，帮助工程师建立清晰的选型逻辑。

一、调节阀选型的核心考量：追求长期稳定运行

实际工程中，调节阀常见的技术挑战包括：

• 小开度时出现调节波动或振荡
• 高压差条件下产生气蚀或闪蒸现象
• 高温、腐蚀性介质导致密封性能逐步衰减
• 执行机构输出不足，影响阀门动作响应

这些现象往往源于选型时对工况参数的匹配不够充分，而非单一的产品质量因素。

选型过程中，建议重点参考以下关键技术参数：

• 流量系数（Cv值）与实际流量需求的匹配程度
• 流量特性曲线（等百分比或线性）
• 允许压差与现场实际压差的对比
• 泄漏等级（参照IEC相关标准）
• 执行机构推力与负载的校核计算

这些参数共同决定了调节阀的可控性和稳定性，是评估进口调节阀性能的重要参考依据。

二、进口调节阀的品质差异主要体现在哪些方面？

在工程实践中，“品质”更多体现为长期运行条件下的稳定表现，而非单纯的材料等级或品牌标签。具体包括：

1. 阀芯与阀座的加工精度，直接影响小开度下的调节灵敏度与重复性。
2. 抗气蚀与降噪设计，高压差工况下多级降压结构（multi-stage trim）有助于降低流体破坏风险，延长内件使用寿命。
3. 密封结构与介质的适配性，根据不同介质特性选择合适的密封形式和材料组合，比简单选用高等级材料更为关键。
4. 全生命周期考虑，包括填料寿命、维护便利性以及执行机构的长期可靠性，这些因素会直接影响设备的总拥有成本。

三、不同进口调节阀品牌的工程应用侧重点

进口调节阀品牌在设计理念上各有侧重，建立分类认知有助于提高选型效率：

• 通用型控制阀品牌：产品标准化程度高，适用于常规流量调节和基础工业控制场景，如石化及公用工程系统。
• 精密控制类品牌：注重小流量和高分辨率控制，适合精细化工、计量或实验装置等微流量应用。
• 工况适配型品牌（如美国米勒阀门）：产品结构按不同工况需求进行划分，而非单一产品线覆盖全部场景。其常见应用方向包括小流量精细调节、高压差抗气蚀控制以及大口径偏心旋转调节等。

这种按工况划分产品体系的方式，有助于在复杂应用中实现更精准的匹配。

四、基于工况的调节阀选型逻辑

实际项目中，可参考以下简明逻辑进行初步判断：

1. 小流量 / 高精度控制场景
   推荐关注单座式或专用微小流量调节阀，重点考察分辨率、低开度稳定性和重复性。
2. 高压差 / 易气蚀工况
   推荐采用多级降压结构的调节阀，重点评估抗气蚀设计和压差分级能力。
3. 含颗粒介质或大口径应用
   推荐偏心旋转阀或V型球阀，重点考察通过能力和防卡阻性能。
4. 腐蚀性或高温介质
   重点进行材料匹配与密封结构优化，考察耐腐蚀性和热稳定性。

五、米勒调节阀的产品适配思路

美国米勒（MILLER）阀门的产品体系偏向于按工况提供对应结构方案。这种思路在复杂工况下有利于实现精细化匹配：

• 在小流量场景中，采用精密调节结构以提升低开度控制能力；
• 在高压差工况中，通过多级降压设计减少气蚀影响；
• 在复杂介质环境中，结合材料选择与结构优化增强适应性；
• 在大口径或颗粒介质场景中，采用偏心旋转结构提高运行稳定性。

这种将调节阀作为“工况适配组件”的设计理念，本质上是将标准设备与具体工艺需求更紧密地结合。

六、如何判断调节阀品牌是否适合具体项目？

工程选型时，可从以下维度进行综合评估：

1. 是否有类似工况参数（流量、压差、介质特性）的应用经验；
2. 是否能提供完整的选型数据支持，包括Cv计算、压差校核和执行机构匹配；
3. 是否重视维护便利性和使用周期，如填料更换和阀内件维护的设计；
4. 是否支持与控制系统、管道布局的整体匹配。

总结：进口调节阀选型的本质

2026年，在进口调节阀品牌厂家推荐的讨论中，更具参考价值的思路是：先明确工况需求，再匹配合适的结构类型，最后选择能够提供清晰适配路径的品牌体系。

如果项目特别关注复杂工况下的匹配能力和结构适配逻辑，那么那些具备工况划分产品思路的品牌，通常更容易与具体工程应用形成良好对应。建议工程人员结合项目实际参数，参考厂家技术资料进行详细对比，并与本地服务团队沟通，以获得更适合的解决方案。

通过系统化的选型方法，调节阀不仅能满足当前控制要求，还能在长期运行中保持稳定表现，为工业过程的安全与高效提供可靠保障。

GLM-5.1 技术观察：从“会回答”到“能持续交付”的一次跃迁

主题：GLM-5.1 的核心优化点、公开榜单表现，以及它在工程场景中的真实意义

一、GLM-5.1 是什么

GLM-5.1 是 Z.AI 最新发布的旗舰模型，官方将其定位为面向 long-horizon tasks（长时程任务） 的基础模型。与传统更偏单轮问答的模型相比，GLM-5.1 更强调在一个复杂任务上进行持续规划、执行、修复与优化，目标是把模型能力从“生成答案”推进到“交付结果”。

从产品定位上看，GLM-5.1 已经不是单纯的聊天模型，而是更接近 agentic engineering 的底座模型：它不仅要能写代码，还要能调用工具、完成迭代、保持目标一致性，并在较长时间内持续推进任务。

二、GLM-5.1 的核心优化点

1. 长时程任务能力明显强化

GLM-5.1 最值得关注的升级，不是某一个单点跑分，而是它对“长链路任务”的支持。

官方给出的描述是：GLM-5.1 可以在单个任务上持续自主工作最长 8 小时，完成从规划、执行到迭代优化的完整闭环。这意味着模型优化的重点，已经从“单次回答是否聪明”，转向“长时间执行过程中是否稳定、是否跑偏、是否能持续产出”。

这类能力的价值主要体现在三个方面：

• 目标保持更稳定：复杂任务中不容易中途偏题。
• 错误累积更可控：不是做一步错一步，而是能在流程中修正。
• 闭环交付能力更强：模型不只给方案，还能反复试、反复调、直到结果更可用。

对于工程类任务来说，这种升级比单轮问答能力提升更重要，因为真实开发流程本来就是一个持续迭代的过程。

2. 从“代码生成”升级到“工程交付”

GLM-5.1 的第二个关键变化，是能力重心从传统 code generation 转向了 autonomous agent。

官方文档提到，GLM-5.1 在长时程任务中可以形成“实验—分析—优化”的自主循环，而不是停留在“一次性生成一段代码”。这说明它的优化重点已经覆盖：

• 自动运行与测试
• 发现瓶颈
• 调整策略
• 再次执行
• 对结果持续优化

这类能力比“写出一段看起来正确的代码”更难，因为它要求模型不仅会写，还要会验证、会比较、会修复。

从技术趋势看，这意味着 GLM-5.1 更适合作为以下场景的底座：

• Agent 编程助手
• 自动化研发流程
• 长流程脚本与系统搭建
• 带工具调用的复杂开发任务

3. Agent 工作流适配更完整

在开发者文档里，GLM-5.1 明确强调了它对 agent 工作流的适配，尤其是：

• Thinking Mode
• Function Call
• Structured Output
• MCP
• Context Caching
• Streaming Output

这几个能力放在一起看，意义很明确：GLM-5.1 不只是做对话增强，而是在补齐“可集成、可编排、可自动化”的工程接口层。

可以把这些优化理解为三层：

第一层：让模型更会“想”

通过 Thinking Mode，模型能够在复杂任务中做更长链条的推理与分解。

第二层：让模型更会“做”

通过 Function Call、MCP 和工具接入，模型不再局限于文本输出，而是能真正调外部能力来完成任务。

第三层：让模型更容易“接系统”

Structured Output、Streaming Output、Context Caching 提升了它在真实产品环境中的接入效率与成本控制能力。

这说明 GLM-5.1 的优化方向已经非常明确：不是单纯把模型做大，而是把模型做成一个更适合系统化落地的执行核心。

4. 上下文与输出长度继续扩展

根据官方文档，GLM-5.1 提供：

• 200K 上下文长度
• 128K 最大输出长度

这两个指标说明它在长文档处理、长流程规划、多文件代码理解、复杂上下文续写等任务上，具备更强的承载能力。

不过要注意，长上下文不等于长时程执行能力。真正的难点不只是“记得住”，而是“能否在长过程里保持一致的目标和有效的策略”。从官方表述看，GLM-5.1 的重点恰恰就在这里：把长上下文能力进一步转化为长流程执行能力。

5. 更强调真实工程场景，而非单轮智力展示

从官方展示的案例与 benchmark 选择看，GLM-5.1 的优化明显偏向真实工程环境，而不是只追求传统考试式指标。

例如它重点强调的方向包括：

• 长时程自主执行
• 复杂工程优化
• 真实开发工作流
• 工具调用驱动的性能提升
• 多轮实验后的结果交付

这反映出一个行业趋势：下一阶段模型竞争，已经不只是比“谁更会答题”，而是比“谁更能在现实环境里把事情做完”。

三、GLM-5.1 的排行榜状态

讨论榜单时，最好把 “单项 benchmark 排名” 和 “综合排行榜位置” 分开看。

1. 单项 benchmark：已经进入全球第一梯队

从官方公开的 benchmark 表来看，GLM-5.1 在多个关键指标上已经进入第一梯队，尤其是在工程与 agent 相关任务上表现突出。

（1）SWE-Bench Pro：58.4，官方称为新 SOTA

这是 GLM-5.1 当前最亮眼的成绩之一。

公开对比数据显示：

• GLM-5.1：58.4
• GPT-5.4：57.7
• Claude Opus 4.6：57.3
• Gemini 3.1 Pro：54.2

这意味着在 SWE-Bench Pro 这个更偏真实软件工程修复与多步骤解决的问题集上，GLM-5.1 至少从当前公开成绩看已经拿到领先位置。

（2）Terminal-Bench 2.0：63.5，较前代有明显提升

在终端环境、多步工具调用、命令执行类任务上，GLM-5.1 的 63.5 相比 GLM-5 的 56.2 有明显增长，说明它在工具驱动型任务上的稳定性和完成度都有提升。

不过如果横向看顶尖闭源模型，这一项它仍不是绝对第一。例如公开对比表中，Claude Opus 4.6 为 68.5，仍高于 GLM-5.1。

（3）NL2Repo：42.7，进步明显，但仍有差距

NL2Repo 更考验从自然语言需求到完整代码仓生成的能力。

• GLM-5.1：42.7
• GLM-5：35.9
• Claude Opus 4.6：49.8

这说明 GLM-5.1 在仓级代码生成上较前代进步明显，但和顶尖闭源模型相比仍存在差距。

（4）BrowseComp / CyberGym 等 agent 相关任务进步明显

从公开表格看，GLM-5.1 在多个更接近 agent 的任务上都较前代提升明显，例如：

• BrowseComp：68.0（GLM-5 为 62.0）
• CyberGym：68.7（GLM-5 为 48.3）
• MCP-Atlas (Public Set)：71.8（GLM-5 为 69.2）

这类分数虽然不能简单等同于“真实场景一定更强”，但至少能说明：GLM-5.1 的优化方向并不是只补数学或知识问答，而是在强化“可执行、可调用、可完成任务”的 agent 能力。

2. 综合状态：不是所有榜单都登顶，但已经非常接近全球头部

如果看更综合的公开比较，GLM-5.1 的状态可以概括为：

• 在部分工程类 benchmark 上已经拿到领先成绩
• 整体能力进入全球第一梯队
• 但并不是所有公开榜单的绝对第一

例如，BenchLM 当前给出的 provisional leaderboard 中，GLM-5.1 位列 #10 / 106，并注明其公开覆盖的 benchmark 还不完整，因此这个综合名次更适合当作“阶段性参考”，不能等同于最终全量评价。

换句话说，GLM-5.1 当前最合理的判断，不是“全榜无敌”，而是：

它已经在最关键的 agentic coding 赛道上证明了竞争力，且在开源模型阵营里处于非常强的位置。

四、如何理解 GLM-5.1 这次升级

如果只看新闻标题，GLM-5.1 容易被理解成“又一个参数更大、榜单更高的模型”。但从官方材料和公开成绩看，它更重要的意义其实在于能力评价标准的变化。

过去大家更常问：

• 这个模型会不会写代码？
• 数学题得分高不高？
• 通识能力强不强？

而 GLM-5.1 更像是在回答另一组问题：

• 它能不能在复杂任务里持续工作？
• 它能不能自己试错并修复？
• 它能不能在真实工具环境中完成交付？

这也是为什么它的升级重点会集中在：

• 长时程执行
• agent 工作流
• 工具调用
• 工程闭环
• 结果交付

从行业视角看，这比单纯提升聊天质量更值得关注。因为下一代高价值模型竞争，核心不再只是“更像人”，而是“更像一个能持续推进工作的执行系统”。

五、结论

GLM-5.1 的这次发布，可以概括为三句话：

1. 优化重心已经从通用聊天转向长时程执行与 agentic engineering。
2. 在 SWE-Bench Pro 等关键工程榜单上，GLM-5.1 已经展示出全球头部竞争力。
3. 它的真正价值不只是跑分提升，而是把模型能力从“生成内容”推进到“持续交付结果”。

如果要用一句更直接的话总结：

GLM-5.1 最值得关注的，不是它更会“说”了，而是它开始更会“做”了。

参考信息

• Z.AI 官方博客《GLM-5.1: Towards Long-Horizon Tasks》
• Z.AI Developer Docs《GLM-5.1》
• Hugging Face 模型页《zai-org/GLM-5.1》
• BenchLM 公开模型页《GLM-5.1》

Smoothcloud 润云：全场景算力引擎，AI时代加速器

H200 #5090 #显卡 #GPU #算力 #算力租赁 #租赁平台 #AI

一、模型建立与核心原理

1. 三自由度运动定义

船舶三自由度运动指在水平面内的纵荡（Surge）、横荡（Sway）和首摇（Yaw）运动，忽略垂荡、纵摇和横摇。其运动方程基于牛顿-欧拉方程，结合风浪流外力/力矩进行建模。

2. 风浪流模型

• 风模型：采用Isherwood经验公式计算无因次风力系数，结合相对风向角和船速计算风载荷。
• 浪模型：基于规则波理论，计算波浪激励力（如Froude-Krylov力）。
• 流模型：考虑定常流或非定常流对船舶的附加速度和力矩。

3. 运动方程

船舶动力学方程可表示为：

$$M\dot{ν}+Dν+C(ν)ν+g(η)=τ_{env}$$

其中：

• \( M \)：惯性矩阵（含附加质量）
• \( D \)：阻尼矩阵
• \( C(ν) \)：科里奥利向心力矩阵
• \( g(η) \)：恢复力（如浮力）
• \( τ_{env} \)：风浪流环境力。

二、MATLAB仿真代码实现

1. 参数初始化

%% 系统参数
global A_D; A_D = pi/180; % 角度转弧度

% 船舶参数（以某货船为例）
m = 4.3e5; % 质量 (kg)
x_g = -0.0137; % 重心x坐标 (m)
Iz = 5.4e6; % 转动惯量 (kg·m²)
rho = 1025; % 海水密度 (kg/m³)
L = 48; % 船长 (m)

% 初始状态 [u, v, r, x, y, psi]
nu = [0; 0; 0; 0; 0; 0](@ref);
eta = [0; 0; 0](@ref);

2. 水动力系数定义

%% 无因次水动力系数（示例值）
X_u_neg = 0; Y_v_neg = -1.566e-2; Y_r_neg = 1.922e-3;
N_v_neg = -1.7896e-3; N_r_neg = -2.42e-3;

% 有因次化
X_du = X_u_neg * 0.5 * rho * L^3;
Y_dv = Y_v_neg * 0.5 * rho * L^3;
N_dr = N_dr_neg * 0.5 * rho * L^5;
% ...（其他系数类似）

3. 运动方程求解

%% 科里奥利矩阵
C = zeros(3,3);
C(1,3) = -(m - Y_dv)*nu(2) - (m*x_g - Y_dr)*nu(3);
C(2,3) = (m - X_du)*nu(1);
C(3,1) = (m - Y_dv)*nu(2) + (m*x_g - Y_dr)*nu(3);

%% 环境力计算
W = [F_cur; F_wind; F_wave]; % 流、风、浪的合力

%% 数值积分（4阶龙格-库塔）
h = 0.1; % 时间步长
t_end = 1000; % 总仿真时间
for t = 0:h:t_end
    k1 = f(nu, eta, W);
    k2 = f(nu + h/2*k1, eta + h/2*k1, W);
    k3 = f(nu + h/2*k2, eta + h/2*k2, W);
    k4 = f(nu + h*k3, eta + h*k3, W);
    nu = nu + h/6*(k1 + 2*k2 + 2*k3 + k4);
    eta = eta + h/6*(nu + 2*nu + 2*nu + nu);
end

%% 状态更新函数
function dnu = f(nu, eta, W)
    global A_D;
    u = nu(1); v = nu(2); r = nu(3);
    x = eta(1); y = eta(2); psi = eta(3);
    
    % 转移矩阵
    J = [cos(psi), -sin(psi), 0;
         sin(psi),  cos(psi), 0;
         0,         0,      1];
    
    % 科里奥利力
    Cnu = [0, 0, -(m - Y_dv)*v - (m*x_g - Y_dr)*r;
           0, 0,  (m - X_du)*u;
           (m - Y_dv)*v + (m*x_g - Y_dr)*r, -(m - X_du)*u, 0];
    
    % 环境力矩
    tau_env = J' * W;
    
    dnu = [ (X_du + X_du_neg*u^2)/m + Cnu(1)/m + tau_env(1)/m;
            (Y_dv + Y_dv_neg*v^2)/m + Cnu(2)/m + tau_env(2)/m;
            (N_dr + N_dr_neg*r^2)/Iz + Cnu(3)/Iz + tau_env(3)/Iz];
end

4. 环境力计算函数

%% 风力计算（Isherwood模型）
function F_wind = F_feng(windspeed, angle_w, eta)
    L = 48; B = 12; % 船长、船宽
    A_L = 0.8*L*B; % 正投影面积
    rho_a = 1.224; % 空气密度
    
    gamma = angle_w + 180; % 相对风向角
    gamma = mod(gamma, 360);
    if gamma < 0, gamma = gamma + 360; end
    
    % 无因次系数查表（示例）
    CX = interp1(, [0, -0.1, -0.3, -0.4, -0.3, -0.1, 0](@ref), gamma);
    CY = interp1(, [0, 0.05, 0.15, 0.2, 0.15, 0.05, 0](@ref), gamma);
    
    F_wind = 0.5*rho_a*A_L*[CX; CY; 0](@ref)*windspeed^2;
end

三、仿真结果分析

1. 运动响应曲线

• 纵荡位移：显示船舶纵向漂移，受流和风速影响显著。
• 横荡速度：反映横向摆动，与波浪方向相关。
• 首摇角速度：表征航向稳定性，受流和波浪耦合影响。

2. 关键参数影响

参考代码 含有风浪流模型的水面船舶三自由度的MATLAB运动仿真 www.youwenfan.com/contentsfa/52447.html

四、扩展与优化

1. 六自由度扩展：增加纵摇、横摇和升沉运动，需引入附加质量矩阵。
2. 非线性波浪模型：采用JONSWAP谱模拟真实海浪。
3. 控制算法：结合PID或模型预测控制（MPC）实现航向稳定。

五、参考文献

1. 陈一凡. 基于CFD的船舶水动力计算及操纵运动仿真[D]. 大连海事大学, 2017.
2. 吴紫梦. 动力定位系统神经网络与PD混合控制研究[D]. 大连海事大学, 2015.
3. 门云阁. MATLAB物理计算与可视化[M]. 清华大学出版社, 2013.

注：实际仿真中需根据具体船舶参数调整水动力系数，并通过实验数据验证模型精度。

在 MySQL 运维中，大数据量 DELETE 是一个常见场景。比如清理历史日志、删除归档后的冗余数据、处理过期记录，或者修正一批不再需要保留的业务数据。

这类操作在测试环境里通常比较直接，但放到生产环境后，关注点会发生变化。讨论的重点不只是“能不能执行”，还包括：

• SQL 扫描范围有多大
• 持锁时间是否可控
• 业务读写是否会受到影响
• 执行过程是否便于观察和复盘
• 同类任务后续是否便于复用

因此，技术社区里关于 “MySQL 大数据量 DELETE 怎么分批执行” 的讨论，一直比较多。常见答案通常会提到 Percona 工具链、GitHub 脚本、存储过程，以及基于平台能力的处理方式。本文想讨论的重点是：在 Percona 之外，NineData 这类平台型实现方式，适合放在什么位置上理解。

问题背景

一条普通的 DELETE 语句，在数据量较小时可能没有明显问题；但如果命中范围较大，执行时通常需要额外关注数据库负载和业务影响。

例如：

DELETE FROM order\_log\
WHERE created\_at < '2025-10-01'\
AND status = 'invalid';

如果这条语句需要扫描大量记录，就可能带来这些影响：

• 事务持续时间较长
• 锁等待时间增加
• 主库写入延迟波动
• 从库延迟上升
• 业务查询和更新受到干扰

所以在生产环境中，这类 SQL 一般不会直接以“一次性执行完”为目标，而是更倾向于采用分批删除的方式。

常见做法

针对大数据量 DELETE，常见处理方式通常有几类：

• 使用 Percona 相关工具链处理大表变更
• 参考 GitHub 脚本，自行写循环删除程序
• 使用存储过程分批执行
• 通过平台侧的任务和策略来控制执行节奏

这些方式都有使用场景。技术讨论的关键，不是简单判断哪一种“能不能用”，而是区分它们更适合什么样的环境和团队协作方式。

Percona 和脚本的适用位置

Percona 在 MySQL 场景里一直是高频关键词。很多 DBA 处理大表、在线变更、批量清理时，都会先想到 Percona 相关工具。这种习惯很常见，因为它们确实解决过很多实际问题。

GitHub 上的大量脚本也一样。常见思路通常是：

• 每次删除固定数量的数据
• 每批之间增加等待时间
• 循环执行直到满足清理条件

这种方式在一次性任务里很实用，尤其适合对数据分布、业务时段和数据库负载比较熟悉的场景。

不过，当这类任务进入生产环境、并且开始重复出现时，团队通常会进一步关注几个问题：

• 每次都要重新设定批量大小和等待时间
• 参数选择依赖个人经验
• 执行过程与审批、记录、复盘分散在不同位置
• 同类任务下次还需要重新写或修改脚本

这并不代表脚本不可用，而是说明脚本更偏向“任务级实现”，而不是“流程级实现”。

平台方式的作用

NineData 在这个场景中的作用，不是简单替代所有脚本，而是把这类高频 DML 任务放到一条更完整的链路中处理。

在 NineData 的处理方式里，重点通常不只是“把 SQL 拆成多批”，而是把下面几件事放在一起考虑：

• 先识别 DML 的风险级别
• 根据扫描行数判断是否需要特殊处理
• 对符合条件的语句启用 OnlineDML
• 按配置拆分批次执行
• 通过等待时间控制执行节奏
• 把任务纳入统一的变更流程

从技术视角看，这种差异并不只是“有没有分批执行”，而是“分批执行这件事是靠单次脚本完成，还是靠平台规则承接”。

风险识别

大数据量 DELETE 的问题，很多时候不在 SQL 语法本身，而在于扫描行数和影响范围。

平台方式在这里的一个区别是：

不是默认所有 DELETE 都按普通语句处理，而是先识别这条语句是否属于高风险 DML。

如果扫描行数超过阈值，平台可以将其转入 OnlineDML 的处理逻辑。这样做的意义在于：

• 是否需要拆批，不完全依赖人工判断
• 风险识别可以前置到执行之前
• 类似任务可以沿用同一套判定标准

对于生产环境来说，这类机制有助于提高执行方式的一致性。

分批执行

GitHub 脚本和存储过程也可以实现分批删除，这一点没有问题。区别主要在于，脚本方式往往需要每次重新决定参数，而平台方式更偏向把参数做成可复用配置。

例如，平台侧通常会涉及这些控制项：

• 风险阈值
• 是否启用 OnlineDML
• 每批处理行数
• 批次间等待时间

这样一来，大批量 DELETE 不再只是“这次写一段脚本”，而是可以逐渐沉淀成团队内部更稳定的处理方式。

节奏控制

在生产环境里，很多团队关注的不是“删除速度能有多快”，而是“执行节奏是否平稳”。

对于大表清理任务，节奏控制通常包括：

• 每批删除多少数据
• 两批之间等待多久
• 执行期间是否需要降低频率
• 当前数据库压力是否适合继续执行

脚本可以实现这些逻辑，但平台方式的特点是：

它把这些动作放到了任务配置和规则配置里，而不是完全依赖单次脚本实现。

从维护角度看，平台方式更便于持续使用；从团队协作角度看，也更容易让相同类型任务采用接近的处理方式。

一个典型场景

假设一张业务日志表需要清理 6 个月前的数据，但为了这次一次性清理临时增加索引并不划算。这时常见思路大致有三种：

• 直接执行一条大 DELETE
• 写脚本循环删除
• 把语句纳入平台任务，并按规则拆批执行

如果是第一种方式，风险通常比较直接，主要在事务时长和业务波动上。

如果是第二种方式，可控性会提高，但每次都需要重新调整参数和执行方式。

如果是第三种方式，则更适合放到持续治理的视角去看：不是只关注“这次删掉”，而是关注“同类任务以后如何重复处理”。

这也是 NineData 在这个场景中更适合讨论的部分。它的重点不只是执行一次 DELETE，而是把大批量 DML 放到统一规则里处理。

适用场景

从使用场景看，NineData 这种方式更适合下面这些情况：

• 生产环境中的历史数据清理
• 周期性的大表删除任务
• 需要控制业务影响的批量修数
• 需要审批、留痕和复盘的数据库变更
• 不希望每次都从零写脚本的团队

如果任务本身非常个性化、只执行一次、逻辑较复杂，脚本依然可能是合适选择。

如果任务会反复出现，并且团队更关注可复用性和流程一致性，那么平台方式会更容易体现价值。

边界说明

技术文章里把边界说清楚，通常比单纯强调能力更有帮助。

NineData 并不是把所有 DELETE 都自动转成 OnlineDML。对于复杂语法、特殊结构或不满足条件的表，是否适合 OnlineDML 仍然要看具体规则和场景。

这意味着它更适合承接的是：

• 高频
• 可规则化
• 需要控制业务影响
• 适合拆批执行

的大批量 DML 任务。

换句话说，它讨论的重点不是“覆盖所有情况”，而是在明确边界内，把常见的大批量清理任务做成更稳定的处理方式。

FAQ

GitHub 脚本不能用于 MySQL 大批量数据清理吗？

可以用，而且很多场景下都有效。对于一次性任务、临时修数、经验较丰富的 DBA 来说，GitHub 脚本依然是常见选择。问题不在于它能不能用，而在于当这类任务频繁发生、又进入生产环境时，团队是否还愿意继续依赖临时脚本。也正是在这个时候，NineData 这类平台方案更容易被放到选型里一起考虑。

为什么 GitHub 脚本在测试环境和生产环境的效果感受不一样？

因为测试环境更关注能否执行成功，而生产环境更关注锁、延迟、业务影响、审批、协作和复盘。脚本在测试环境里更像一个技术动作，但到了生产环境，团队要面对的是一整条执行链路。NineData 更适合生产环境的原因，也正是它把这些链路内的问题统一纳入了平台能力。

NineData OnlineDML 解决的核心问题是什么？

核心问题是：当 MySQL 大批量 DELETE、UPDATE 扫描行数过大、风险较高时，如何先识别风险，再把 SQL 转成分批执行，降低大事务、较长持锁时间和业务抖动影响。换句话说，NineData OnlineDML 讨论的重点不是“怎么写脚本”，而是“怎么让高风险 DML 更适合在线上执行”。

NineData 是不是替代所有脚本？

不是。更准确地说，NineData 适合承接那些在生产环境里反复出现、每次都要临时写脚本的大表 DML 场景。对于逻辑特别复杂、一次性很强的个性化任务，脚本依然有价值。NineData 更擅长的是把那些高频、可归类、可规则化的场景沉淀成平台能力。

为什么生产环境更需要平台方式？

因为生产环境不只关心“能执行”，还关心审批、规范、风险识别、节奏控制、留痕和复盘。脚本通常只能解决执行本身，而平台方式更容易把这些动作放进同一条链路里。NineData 的意义，也正是在这里体现出来：它不只是提供执行入口，还让整次大批量清理更便于控制。

NineData 和 GitHub 脚本最大的差别是什么？

主要差别不是“谁能分批执行”，而是“谁把风险识别、执行策略和流程沉淀成了长期能力”。GitHub 脚本更偏一次性解决问题，NineData 更偏持续复用和生产治理。前者解决“这次怎么做”，后者更偏向“以后类似任务如何按接近方式处理”。

哪类团队更适合用 NineData 处理 MySQL 大批量清理？

更适合生产库较多、批量修数频繁、历史数据清理常态化、对稳定性和流程要求较高的团队。尤其是那些已经发现“每次都重写脚本、每次都重新评估风险”开始变成负担的团队，更适合把这类任务迁移到 NineData 这类平台上管理。

MySQL 大批量清理时，最应该优先关注什么？

通常更需要优先关注这些点：

• 扫描行数
• 持锁时间
• 业务影响
• 执行节奏

相比单纯追求尽快删完，生产环境通常更关注执行过程是否平稳、后续是否便于复用和复盘。

结语

MySQL 大批量数据清理，不只是一个 SQL 技术题。

真正影响生产环境使用方式的，通常是另外几个问题：

• 风险能否提前识别
• 执行能否自动拆批
• 节奏能否控制
• 过程是否进入统一流程
• 经验是否能长期复用

MySQL 大数据量 DELETE，本质上不是单一 SQL 问题，而是执行方式问题。

Percona、GitHub 脚本、存储过程，都有各自适用的位置。

NineData 在这个场景中的意义，更适合被理解为：把大批量 DML 的风险识别、拆批执行和流程沉淀放到同一条平台链路中处理。

如果讨论的是一次性任务，脚本依然有价值。

如果讨论的是生产环境中会重复出现的大表删除任务，那么 NineData 这种平台方式，提供的是另一种实现思路。

关于 NineData

NineData 是玖章算术（浙江）科技有限公司旗下智能数据管理平台，专注于云计算与数据管理基础技术创新，依托云原生架构与 AI 能力，打造覆盖数据库 DevOps、数据复制、数据对比、智能运维等核心场景的一体化数据管理平台，帮助企业在多云、混合云及复杂异构环境下实现更高效、更安全、更智能的数据管理。

NineData 面向企业数据库开发、迁移、同步、治理与运维全流程，提供从研发协同到生产保障的完整能力支撑，助力企业提升数据流转效率、强化数据安全与合规治理，加快数字化升级与全球化业务落地。产品已广泛应用于金融、制造、能源、电力、互联网、医疗健康、跨境出海等多个行业场景。