简介：这份PDF面向需要将工业现场数据接入关系型数据库的自动化工程师、上位机开发者和系统集成人员，围绕Kepserver与MySQL的数据对接，梳理从软件环境准备到数据库连通验证的完整流程。文档共1个PDF文件，压缩包约3.89MB，内容覆盖Kepserver安装与运行准备、MySQL数据库部署、Navicat可视化管理工具配置、32位ODBC驱动安装，以及连接参数设置与Excel数据导入等关键环节，便于按步骤搭建测试环境并排查常见连接问题。已有2631人学习，适合作为Kepserver采集数据写入MySQL的入门操作参考，也可为现场调试、数据表结构准备和连接测试提供一份较清晰的流程清单。

1. 设备数据要落库，卡住的往往不是采集而是 Kepserver 到 MySQL 这一段

做过几个产线数据入库的项目之后我发现，真正让人熬夜的环节通常不在 PLC 侧，而在 Kepserver 采上来的值不知道往哪儿落。KEPServerEX 的定位是协议网关，它把 Modbus、S7、OPC UA 这些五花八门的协议统一成一套标签命名空间，但它本身不是历史库，要留下记录就得往外开一条通道，MySQL 是最常见的一站。这条链路里最容易翻车的是位数：MySQL 装的是 64 位，KEPServerEX 却是 32 位进程，中间那层 ODBC 驱动一旦装错版本，配置界面里连数据源都刷不出来，报错还特别含糊。下面按我实际搭过的一套环境，把软件安装顺序、32 位 DSN 配置、Navicat 建表、Excel 批量导入这几件事的参数和坑点写清楚，适合第一次做数据入库、或者接手别人半截工程要继续往下调的人。

2. 先把链路拆开：从 PLC 标签到 MySQL 表，中间隔着四层

动手之前先花十分钟把链路画清楚，比装完再回头找问题省事得多。这条链路不是「KEPServerEX 连 MySQL」一句话能概括的，它是四个职责完全不同的层叠在一起，任何一层配置错位，表现出来的症状都差不多是「数据没进去」，但真正的原因可能在天上也可能在地下。

2.1 四层链路各自的职责与故障特征

第一层是设备层，PLC、仪表、称重器、温控表，跑的是 Modbus TCP、S7、OPC UA 这些协议。这一层出问题，KEPServerEX 里标签质量会直接变成 Bad，或者干脆连不上设备。第二层是采集层，KEPServerEX 里的 Channel、Device、Tag 三级结构，负责把设备地址翻译成有名字的标签，比如Line1.Oven.Temp1。这一层的典型故障是扫描周期设得太短导致设备响应超时，或者地址偏移量填错，读出来永远是 0。

第三层是传输层，也就是 ODBC。KEPServerEX 不直接说 MySQL 的协议，它只认 ODBC 数据源，由驱动去做协议转换。这一层出问题的特征是：标签值明明是 Good，日志里也有写入动作，但表里就是没数据，或者偶尔有偶尔没有。第四层是存储层，MySQL 的库、表、字段类型、字符集、账号权限，这一层出错通常会在 KEPServerEX 的 Event Log 里留下明确的 SQL 错误码。

有了这张表，现场排查就不用瞎猜。我一般的做法是先打开 OPC Quick Client 看标签值是不是在跳，跳了就说明前两层没问题，问题一定在 ODBC 和 MySQL 这边；不跳就先查设备和扫描周期，别在数据库上浪费时间。

2.2 为什么 32 位 ODBC 是硬约束，而不是建议

这是整条链路里最反直觉的一点。KEPServerEX 的主进程是 32 位应用，它在调用 ODBC API 时加载的是 32 位版本的驱动管理器。Windows 的 ODBC 体系里，32 位进程只能看见 32 位 DSN，64 位进程只能看见 64 位 DSN，两套配置完全隔离，互不可见。也就是说，如果你的机器上只装了 64 位 MySQL ODBC 驱动，在 KEPServerEX 的配置界面里点开数据源下拉框，会看到一个空的列表，而且不会有任何提示告诉你原因。

更坑的是 ODBC 管理器本身的路径。64 位 Windows 上，从控制面板或开始菜单点开的「ODBC 数据源」默认是 64 位版本；32 位版本藏在C:\Windows\SysWOW64\odbcad32.exe。这个目录名和位数的对应关系是反的，System32 下放的是 64 位程序，SysWOW64 下放的是 32 位程序，这是历史遗留的命名，第一次接触的人几乎都要踩一次。

判断当前 KEPServerEX 是几位，最直接的办法是打开任务管理器，在「详细信息」里看进程名后面有没有标注「32 位」。有标注就是 32 位，必须配 32 位驱动。另一种验证方式是看安装目录，32 位程序通常装在Program Files (x86)下。确认完位数再决定装哪个驱动，能省掉后面一大堆「为什么数据源是空的」的困惑。

提示：装完 32 位驱动后，一定要用SysWOW64\odbcad32.exe去建 DSN，用默认那个管理器建出来的 DSN，KEPServerEX 一样看不见。

2.3 写入方式的选型：直写、转发还是自己写客户端

确定用 ODBC 之后，还有一层选择：数据怎么从 KEPServerEX 送到 MySQL。常见做法有三种。第一种是用 KEPServerEX 自带的 Data Logger 功能，直接配置一个 ODBC 目标，按标签变化或固定周期把值写进表里。这是最省事的方案，不用额外写代码，配置完就能跑，适合点位不多、写入频率在秒级的场景。

第二种是走 IoT Gateway 或 REST 把数据推给一个中间服务，由中间服务批量写库。这种方案的好处是可以在中间层做清洗、聚合、断网缓存和补传，缺点是多了个要维护的服务，出问题的时候排查链路变长。第三种是自己写一个 OPC UA 客户端订阅标签，再写库，灵活性最高，但相当于把 KEPServerEX 已经做好的事情又做了一遍，除非有特殊的数据处理需求，一般不建议。

我一般会先按最简的 Data Logger 方案跑通，确认数据能稳定落表，再根据业务方对补传和聚合的要求决定要不要上中间服务。一上来就搭全套架构，往往在还没验证通的时候就把自己绕进去了。

3. 三个组件的落地顺序：KEPServerEX、MySQL 与管理客户端

安装顺序有讲究。我的习惯是先装 MySQL 并建好库表，再装 KEPServerEX，最后装管理客户端和 ODBC 驱动。原因很实际：KEPServerEX 装完会注册一堆服务，占着 1024 以下的端口和一堆系统资源，先装它再装 MySQL，偶尔会遇到服务启动顺序冲突；而且先把数据库准备好，配置 ODBC 的时候可以一边配一边测，不用来回切换。

3.1 KEPServerEX 安装与运行时服务要点

安装包建议从正规渠道获取。网上流传的那些替换 DLL 的做法尽量不要碰，一是版权问题，二是替换后安装目录的数字签名校验会失败，运行中可能出现服务随机停止、配置丢失这类没有日志的玄学问题，排查起来极其痛苦。官方提供有时长受限的演示模式，用来做方案验证和功能测试是够的，正式上线还是要走授权。

安装过程本身不复杂，右键以管理员身份运行，选择「典型」安装，勾选示例工程和文档，一路下一步即可。真正需要注意的是安装完成后的两件事。第一件是确认所有 KEPServerEX 相关的服务都已经启动，在服务管理器里能看到以 KEPServerEX 开头的若干服务项，任何一个处于停止状态都可能导致运行时行为异常。第二件是确认运行时以管理员权限启动，否则在写入注册表和访问某些系统目录时会被拦。

安装完成后打开 KEPServerEX Configuration，先建一个模拟设备做自测。用内置的 Simulation 驱动建一个通道，加几个标签，类型分别设为 Float 和 String，让值自动变化。这一步的目的是把采集层和传输层解耦验证：如果模拟标签都写不进数据库，那就跟现场设备一点关系都没有，问题必然在 ODBC 或 MySQL 侧。

3.2 MySQL 社区版安装：字符集、时区与账号三个必改项

MySQL 用社区版就够，不需要企业版。安装时选 Custom 模式，把 MySQL Server 和命令行工具加进去即可，图形化管理工具可以后面单独装。装完之后有三项一定要改，否则后面必然踩坑。

第一项是字符集。MySQL 8.0 默认已经是 utf8mb4，但如果实例是从旧版本升级或者用了自定义配置，仍然可能是 latin1。KEPServerEX 写入的标签名、设备名里只要有中文，就会变成问号或者直接报错。检查方法是执行SHOW VARIABLES LIKE 'character_set%';，确认character_set_server和character_set_database都是 utf8mb4。

第二项是时区。MySQL 默认用系统时区，而 KEPServerEX 写入的时间戳通常带本地时区偏移，两边不一致就会出现「数据是刚写的，查出来却是八小时前」的情况。在配置文件里显式设置default-time-zone='+08:00'，比依赖系统时区可靠得多。

第三项是账号。不建议直接用 root 给 KEPServerEX 用，单独建一个只有目标库增删改查权限的账号，出问题的时候权限范围清晰，也便于审计。建账号的语句大致如下。

-- 创建专用写入账号，限制来源主机，避免使用 root CREATE USER 'kep_writer'@'%' IDENTIFIED BY 'YourStrongPass_2024'; -- 只授予目标库的增删改查权限，不给 DDL 权限 GRANT SELECT, INSERT, UPDATE ON scada.`tag_history` TO 'kep_writer'@'%'; -- 如果 ODBC 驱动是较老的 5.x 版本，需要改成兼容的认证插件 ALTER USER 'kep_writer'@'%' IDENTIFIED WITH mysql_native_password BY 'YourStrongPass_2024'; FLUSH PRIVILEGES;

这段语句的逻辑是：先建账号并限定来源，再按最小权限原则授权，最后处理认证插件兼容问题。参数上，'%'表示允许任意主机连接，如果 KEPServerEX 和 MySQL 在同一台机器上，改成'localhost'更安全；YourStrongPass_2024要换成实际密码，注意 MySQL 8 默认有密码强度插件，太简单的密码会被拒绝。最后那条ALTER USER是关键，MySQL 8.0 默认用caching_sha2_password，而很多 32 位 ODBC 驱动版本较老，不支持这个插件，连接时会报认证插件加载失败。要么升级驱动，要么把账号降级成mysql_native_password，二选一。

3.3 管理客户端：Navicat 试用与两个开源替代

Navicat 是很多人习惯的工具，界面友好，导入导出向导做得不错。它提供有期限的试用版本，用来建表、导数据、看结果完全够用。如果不想受试用期限制，DBeaver 社区版和 HeidiSQL 都是免费且够用的替代品，前者跨平台、支持多种数据库，后者轻量、启动快，做日常的建表和查询没有任何问题。

装完客户端第一件事是验证连通性。新建连接时填主机、端口 3306、账号密码，点「测试连接」。这里有个高频问题：命令行mysql -u root -p能连上，但客户端连不上，报Authentication plugin cannot be loaded或Access denied。前者是客户端自带的驱动版本不支持caching_sha2_password，在连接设置里把「使用 SSL」或认证方式调整一下通常能解决；后者多半是账号的 host 限制，'kep_writer'@'localhost'和'kep_writer'@'%'是两个不同的账号，从别的机器连必须用%那个。

3.4 先建表：给标签值留好字段

表结构不要等 KEPServerEX 配好了再回头建，那时候改字段要停采集。我的习惯是先按标签清单把表建出来，字段类型宁宽勿窄。下面这张表是一个常见的标签历史表结构。

CREATE TABLE `tag_history` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键', `tag_name` VARCHAR(128) NOT NULL COMMENT '标签全名，如 Line1.Oven.Temp1', `tag_value` DOUBLE DEFAULT NULL COMMENT '数值型标签值', `tag_text` VARCHAR(255) DEFAULT NULL COMMENT '字符串型标签值', `quality` VARCHAR(16) DEFAULT NULL COMMENT '质量码 Good/Bad/Uncertain', `collect_time` DATETIME(3) NOT NULL COMMENT '采集时间，毫秒精度', PRIMARY KEY (`id`), KEY `idx_tag_time` (`tag_name`, `collect_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='标签历史数据';

几个参数值得说明。tag_value用 DOUBLE 而不是 FLOAT，是因为 FLOAT 在累计量场景下精度损失明显，跑到几十万的时候小数位已经开始飘。collect_time用DATETIME(3)保留毫秒，秒级精度在设备状态跳变分析时不够用。tag_name上建联合索引，是因为最常见的查询是「某个标签某段时间的数据」，没有索引的话数据量上百万之后查询会明显变慢。另外留了tag_value和tag_text两个字段，是因为 KEPServerEX 的标签类型可能混着数值和字符串，硬塞进一个字段会出类型转换错误。

4. 32 位 ODBC 打通：DSN 配置、标签写入与 Excel 数据入库

这一章是整篇的核心，前面所有准备工作都是为了这一步能一次跑通。顺序上建议是：装 32 位驱动、建 DSN、用测试工具验证连通、再回 KEPServerEX 配置写入，最后处理 Excel 批量导入这类离线数据。

4.1 安装 32 位驱动并确认它真的被注册了

去 MySQL 官方下载 Connector/ODBC，注意选 32 位（x86）的 MSI 包，不要选 x64。安装过程中会有一个组件选择界面，把 Driver 装上即可，不需要装完整的 Connector。装完之后必须验证：打开C:\Windows\SysWOW64\odbcad32.exe，切到「驱动程序」选项卡，列表里应该能看到MySQL ODBC 8.0 Unicode Driver和MySQL ODBC 8.0 ANSI Driver两项。

如果打开的是默认的 ODBC 管理器，看到的是 64 位驱动列表，看不到刚才装的 32 位驱动，这属于正常现象，不是安装失败。判断自己打开的是哪个版本，可以看窗口标题栏，32 位版本的标题会明确写出「ODBC 数据源管理器(32 位)」。这个细节在远程协助的时候特别重要，我见过不止一次对方信誓旦旦说「装了但列表里没有」，结果只是打开错了管理器。

4.2 建系统 DSN 并做连通性自检

DSN 分用户 DSN 和系统 DSN。KEPServerEX 通常以服务方式运行，服务账号和当前登录用户不是一回事，所以必须建系统 DSN，用户 DSN 它读不到。在 32 位管理器里点「系统 DSN」→「添加」→ 选 MySQL ODBC 8.0 Unicode Driver，然后填连接参数。

关键参数有几个。TCP/IP Server填127.0.0.1或实际 IP，端口 3306；User和Password填 3.2 节建的专用账号；Database选目标库。字符集一栏建议显式选utf8mb4，不要用默认值，否则中文标签名写入会出现乱码。点「Test」按钮，弹出Connection Successful才算过。

有些版本在 Test 之后还需要在Details里勾选「允许大结果集」之类的选项，这个按实际数据量决定，一般标签写入场景不需要。建完之后，DSN 的名字会出现在系统数据源列表里，记住这个名字，KEPServerEX 配置时会用到。

如果 Test 报[MySQL][ODBC 8.0(w) Driver]Authentication plugin 'caching_sha2_password' cannot be loaded，回到 3.2 节，把账号的认证插件改成mysql_native_password，或者换一个更新的驱动版本。如果报Can't connect to MySQL server on '127.0.0.1'，先确认 MySQL 服务在跑，再用命令行telnet 127.0.0.1 3306确认端口通，最后检查 MySQL 的bind-address是不是只绑了localhost。

4.3 在 KEPServerEX 里把标签值写进 MySQL

回到 KEPServerEX Configuration，右键项目树里的 Data Logger（有些版本叫 Logger，位置在插件列表里），新建一个 Logger。目标类型选 ODBC，数据源下拉框里应该能看到刚才建的 DSN 名字。如果下拉框是空的，百分之百是位数问题，回到 4.1 重来。

映射关系这一步最容易出错。Logger 需要你把标签和表的列对应起来，标签名对应tag_name，值对应tag_value，质量码对应quality，时间戳对应collect_time。时间戳的处理有两种：用 KEPServerEX 自己生成的采集时间，或者用 MySQL 的NOW()。前者更准确，因为数据在采集那一刻就有了时间，后者会受写入延迟影响。我一般用前者，并且确认格式是YYYY-MM-DD HH:MM:SS.mmm，跟DATETIME(3)对齐。

触发方式按业务需求选。「On Data Change」是标签值变化时写一条，适合状态量和报警；「On Timer」是按固定周期写，适合温度、压力这种连续量。周期不要设得太短，1 秒一条在几十个点位的情况下一天就是几百万行，没有分区和清理策略的话，几个月后查询会明显变慢。

配置完保存，启动 Logger，然后去 OPC Quick Client 里改一个模拟标签的值。回到 MySQL 客户端执行查询，看有没有新行进来。这一步做通了，整条链路的技术障碍就清掉了，剩下的就是点位数扩容和性能调优。

4.4 Excel 批量导入：两条路径与字段映射的坑

现场经常会遇到一种情况：设备还没接进来，或者历史数据存在 Excel 里，需要先把基础数据灌进 MySQL。可选的做法有两种。第一种是用 Navicat 的导入向导，右键表选「导入向导」，选 Excel 文件，然后一步步做字段映射。这条路对新手友好，但有几个地方要注意：Excel 里的日期列经常被识别成字符串，导入后变成0000-00-00；数值列里混了空单元格，会被当成 0 或者 NULL，取决于列设置；表头行如果有空格或特殊字符，映射会上错列。

第二种是转成 CSV 后用命令行导入，适合数据量大、需要重复执行的场景。

# 把 Excel 另存为 CSV，注意选 UTF-8 编码，Windows 默认的 GBK 会乱码 # 登录 MySQL 后执行 mysql -u kep_writer -p scada LOAD DATA LOCAL INFILE '/tmp/tag_base.csv' INTO TABLE tag_history CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (tag_name, tag_value, tag_text, quality, collect_time);

这段命令的逻辑是：从本地 CSV 读数据，按逗号分隔、双引号包裹的规则拆字段，跳过第一行表头，按顺序塞进五个列。几个参数必须解释清楚。CHARACTER SET utf8mb4要跟文件实际编码一致，Excel 在中文 Windows 下另存 CSV 默认是 GBK，直接导入中文会变乱码，要么在另存时选 UTF-8，要么把这里改成 gbk。LINES TERMINATED BY '\r\n'对应 Windows 换行，如果是 Linux 上生成的文件要改成'\n'，写错会导致所有数据挤成一行。LOCAL关键字要求客户端开启local_infile，MySQL 8 默认是关闭的，需要执行SET GLOBAL local_infile = 1;，这一点在托管数据库上经常没有权限，得提前确认。

如果字段顺序和表结构不一致，(tag_name, tag_value, ...)这行要按实际顺序写，不能想当然。我吃过一次亏：表里中间加了一列备注，导入语句没改，结果quality的值全进了备注列，跑了一周才发现。

5. 避坑排查：五条血泪记录

下面这几条都是我在现场真实遇到过的，每条按「现象 → 原因 → 解决」写，照着对照能省不少时间。

5.1 数据源下拉框是空的，看不到任何 MySQL 选项

现象：KEPServerEX 里配置 ODBC 目标，数据源下拉框完全空白，重装驱动也没用。

原因：装的是 64 位驱动，或者 DSN 建在 64 位管理器里。KEPServerEX 是 32 位进程，只能看到 32 位系统 DSN。

解决：卸载 64 位驱动，装 32 位版本；用C:\Windows\SysWOW64\odbcad32.exe打开管理器，在「系统 DSN」里重建。重建后不需要重启电脑，但建议重启一下 KEPServerEX 的运行时服务，让进程重新加载驱动列表。

5.2 Test 连接成功，但写入一直失败且日志里只有一行 SQL 错误

现象：DSN 测试通过，Logger 启动后 Event Log 里刷[MySQL][ODBC]Column count doesn't match value count或类似错误。

原因：Logger 里配置的列和表的实际列数对不上，最常见的场景是表后来加了字段，或者映射时漏配了collect_time。

解决：打开 Logger 的映射界面，逐列核对一遍，确认列名、顺序、数据类型三者都对得上。如果表结构变过，先在测试库上跑一遍插入语句验证，再改配置。改完记得保存并重启 Logger，有些版本改完不重启不生效。

5.3 跑了几小时之后写入停止，重启服务又能跑一段

现象：数据正常写入几个小时后突然断掉，MySQL 侧没有任何新行，KEPServerEX 的 Logger 状态显示运行中但没输出。

原因：大概率是连接被 MySQL 的wait_timeout回收了，而驱动没有正确处理断线重连。MySQL 默认wait_timeout是 28800 秒，但如果实例被调小到几分钟，空闲连接就会被踢掉。

解决：先执行SHOW VARIABLES LIKE 'wait_timeout';确认当前值。可以在 DSN 配置里把连接超时和自动重连选项打开，或者在 MySQL 侧把超时调大。更稳的做法是在 DSN 里勾选「Enable automatic reconnect」，让驱动在检测到断连时自己重建连接。

5.4 客户端能连，KEPServerEX 写入却报 Access denied

现象：Navicat 用同一个账号密码能正常查询，KEPServerEX 写入时报Access denied for user 'kep_writer'@'localhost'。

原因：账号的 host 匹配问题。Navicat 是从本机连的，走的是localhost；KEPServerEX 作为服务运行，可能通过127.0.0.1或者主机名连接，匹配的是另一条账号记录。MySQL 里'user'@'localhost'和'user'@'127.0.0.1'是两个独立账号。

解决：执行SELECT user, host FROM mysql.user WHERE user = 'kep_writer';看清楚实际有哪些记录，然后按需补一条'kep_writer'@'127.0.0.1'并授权。或者干脆统一用'%'，但生产环境不建议这么做，权限范围太大。

5.5 数据写进去了，但时间戳差了八小时

现象：刚写入的记录，用SELECT NOW()对比发现collect_time比当前时间早八小时。

原因：MySQL 服务端时区和 KEPServerEX 运行机器的时区不一致，或者驱动在转换时按 UTC 处理了。还有一种情况是DATETIME和TIMESTAMP混用，TIMESTAMP会自动做时区转换，DATETIME不会。

解决：先在 MySQL 里执行SELECT @@global.time_zone, @@session.time_zone;确认时区设置，在配置文件里显式写default-time-zone='+08:00'并重启服务。表字段统一用DATETIME，避免自动转换带来的不确定性。改完之后用一条新数据验证，不要拿历史数据判断。

6. 联调验证：用一条会变的假数据把整条链路压一遍

链路配通不等于链路可靠。我习惯在交付前做一轮验证，用一个会自动变化的模拟标签，把写入、查询、断线恢复三个环节都走一遍，确认没问题再上真实设备。

验证的第一步是造数据。在 KEPServerEX 里建一个 Simulation 设备的标签，值设成随时间递增的浮点数，更新周期 1 秒。Logger 配置成 On Data Change，跑十分钟。然后到 MySQL 里执行下面这段查询，看行数增长速度是不是接近每分钟 60 行，以及时间戳是不是连续。

-- 看最近十分钟的写入速率和值域，判断是否有丢点或异常值 SELECT DATE_FORMAT(collect_time, '%Y-%m-%d %H:%i') AS minute_bucket, COUNT(*) AS rows_cnt, MIN(tag_value) AS min_val, MAX(tag_value) AS max_val, MAX(tag_value) - MIN(tag_value) AS delta FROM tag_history WHERE tag_name = 'Simulation.Device1.Tag1' AND collect_time >= NOW() - INTERVAL 10 MINUTE GROUP BY minute_bucket ORDER BY minute_bucket DESC;

这段查询的逻辑是按分钟分桶，统计每分钟的行数、值域和增量。正常情况下rows_cnt应该稳定在 60 左右，delta应该接近 60（因为值是每秒加 1）。如果某几分钟rows_cnt明显偏低，说明那段时间有丢点，需要回头看 Logger 的日志和网络状态；如果delta是 0，说明标签值没在变，问题在采集侧而不是写入侧。

第二步是断线演练。把 MySQL 服务停掉，等五分钟，再启动，观察 KEPServerEX 的 Logger 是否能自动恢复写入。这一步能暴露 5.3 里说的连接重连问题。如果恢复不了，说明驱动的自动重连没开，或者 Logger 需要手动重启才能重新建立连接，那就得在运维手册里写清楚处理流程。

第三步是对账。随机抽十条记录，把collect_time和tag_value跟 OPC Quick Client 里显示的值对一遍，确认没有行列错位。这一步看着笨，但能抓住字段映射错位这种最难发现的问题，因为数据一直在增长，肉眼很难判断某个值到底属于哪个标签。

最后说个习惯。从那以后我每次配完 ODBC 链路，都会在表里插一条带特殊标记的测试数据，比如tag_name写成__selftest__，交付前删掉。这样做的好处是任何时候怀疑链路有问题，查一下这条数据在不在，就能立刻判断是「根本没写进去」还是「写进去了但查错了表」。这个习惯帮我省过至少两次深夜排障的时间。

希望帮到你。

本文还有配套的精品资源，点击获取