大家好，我是数据库小学妹 👋
上个月底，财务的老李找到我，说月度报表和实际对不上，差了十几万。
我打开数据库查订单表，发现有一批金额字段是负数。正常情况下金额不可能是负的。追查下去，发现这批数据是三个月前一次批量导入进来的。导入的时候没报错，日志显示全部成功。但数据本身就有问题。
那天我花了一整天，一条一条地追根溯源。最后发现不是数据库坏了，是我们从来没想过"数据库怎么保证数据是对的"这个问题。
能跑和跑得对是两回事，这个教训是财务那十几万差额教我的。
那天追下来，我发现脏数据不是单一原因造成的。不同来源的问题混在一起，互相掩盖，才让这批数据在系统里藏了三个月。查完之后我重新审视了整个项目的数据流转，从入库校验到存储机制再到日常监控，发现几乎每个环节都有隐患。
脏数据的四种典型来源与排查方法
字符集截断。客户备注字段里，有些记录末尾突然截断，后面跟着几个问号。不是源文件的问题，是数据库建库时用了utf8，不支持四字节的emoji和特殊符号。MySQL默认不会报错，直接把不能存的部分截掉，日志显示插入成功，数据已经坏了。
这个限制的根源要追溯到MySQL早期。MySQL的utf8字符集在设计时把每个字符的最大字节数固定为三字节，这在当时覆盖了大部分常用字符。但emoji和某些生僻字属于四字节，落在utf8mb4的范围。很长一段时间里MySQL的默认字符集还是utf8，大量项目在建库时没有显式指定utf8mb4，留下了隐患。
修复需要把库、表、列都改成utf8mb4。但改之前得先排查库里有多少数据已经被截断了。我写了个SQL把所有包含问号或特殊截断标记的记录筛出来：
-- 查找可能存在截断的备注记录
SELECT id, remark
FROM customers
WHERE remark LIKE '%?%'
OR LENGTH(remark) != CHAR_LENGTH(remark) * 3;
LENGTH返回字节数，CHAR_LENGTH返回字符数。utf8编码下一个中文字占3字节，如果字节数不等于字符数乘3，说明里面混了非三字节的字符或者被截断了。跑出来三千多条，只能从源文件重新导入。
迁移utf8mb4不是ALTER一下就完了。正确的步骤是：先备份全库，再改列的字符集，再改表，最后改库。每一步都要验证。改之前别忘了应用层的连接字符串也要同步设utf8mb4，不然数据库改了，应用写入还是按utf8，白改。
隐式类型转换。一批订单在应用里显示"已完成"，数据库状态码却是0（待处理）。应用层用字符串比较，数据库存的是整数。MySQL做隐式类型转换时，VARCHAR和数值比较会把VARCHAR转成数值。字符串'01'转成数值是1不是0，查询条件WHERE status = 0会漏掉所有'01'、'001'的记录。
更严重的是，这种跨类型比较会让B+树索引失效，变成全表扫描。数据量小的时候看不出问题，大了查询慢十倍。
MySQL的B+树索引是按字段声明的类型构建的。VARCHAR字段的索引树存的是字符串的二进制排序值。当WHERE条件里拿数值去比较时，MySQL必须把索引树里每个节点的字符串值都转成数值再做比较。这意味着优化器放弃走索引，直接全表扫描。
用EXPLAIN就能直接看到：
EXPLAIN SELECT * FROM orders WHERE status = 0;
-- type: ALL（全表扫描），key: NULL（没走索引）
-- 加上引号改成字符串比较后：
EXPLAIN SELECT * FROM orders WHERE status = '0';
-- type: ref（走索引），key: idx_status
这个EXPLAIN输出里，type字段告诉你访问类型，ALL是最差的，意味着扫了整张表。改成字符串比较后变成ref，走了索引，扫描行数从几万降到几百。
更隐蔽的是，隐式类型转换还可能把脏数据也匹配出来。比如WHERE phone = 13800138000，phone是VARCHAR类型。这个查询不走索引不说，还会把'13800138000a'这种脏数据也匹配出来，因为'13800138000a'转成数值就是13800138000。你以为是精确匹配，实际上匹配了一堆脏数据。
批量查找这类问题，可以开Performance Schema：
-- 开启语句事件收集
UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME = 'events_statements_history';
-- 查看执行过的涉及隐式转换的查询
SELECT DIGEST_TEXT, COUNT_STAR
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT LIKE '%CONVERT%'
ORDER BY COUNT_STAR DESC;
时区漂移。一批跨月订单算错了月份。应用用了UTC时间，数据库session设成了东八区。同一个时间戳2025-01-31 23:00 UTC，数据库按东八区解析成2025-02-01 07:00。月底的订单变成了月初的。
要理解这个问题，得先分清MySQL的TIMESTAMP和DATETIME两个类型的本质区别。TIMESTAMP存的是Unix时间戳的整数，读取时自动按session的time_zone转换成对应的日期时间。DATETIME存的是"字面值"，比如你插进去2025-01-31 23:00:00，它就读出来就是这个值，不进行时区转换。
两种类型没有绝对的好坏，关键在于全链路一致。你的应用、数据库、连接池、报表系统，如果混用TIMESTAMP和DATETIME，又有时区差异，那统计数据一定会出错。
连接池里每个连接的时区设置还可能不同。有的连接继承了全局时区UTC，有的连接被之前的SQL设成了东八区。同一个查询，拿到不同的连接，返回的结果不一样。这个问题难复现，因为结果取决于碰巧拿到哪个连接。
用SELECT @@session.time_zone就能查到当前会话的时区配置。但你不可能在每个查询前后都查一遍，所以需要从根本上解决。
最根本的方案是在my.cnf里统一设置：
[mysqld]
default-time-zone = '+00:00'
然后在应用层的连接池初始化时统一设置会话时区。我的建议是全链路统一UTC，只在最终展示给用户时才转成当地时区。跨时区的业务不用操心转换逻辑，数据统计也不会因为时区差异出错。
并发写入覆盖。同一条用户记录，姓名是最新的，手机号却是旧的。两个服务同时更新同一条记录，A更新了姓名，B执行UPDATE user SET phone='xxx' WHERE id=1，把整行覆盖回去，包括A刚更新的姓名。
MySQL的行级锁锁的是整行，不是单个列。两个UPDATE并发执行，后到的覆盖先到的。这不是锁的问题，而是业务逻辑的并发冲突没被处理。
解法有两种。第一种是乐观锁，给每条记录加版本号：
CREATE TABLE users (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
phone VARCHAR(20),
version INT DEFAULT 0
);
-- 更新时检查版本号
UPDATE users
SET phone = '13800138000', version = version + 1
WHERE id = 1 AND version = 5;
-- 影响行数为0说明版本号被别人改了，需要重试
应用层检查UPDATE的影响行数。如果是0，说明版本号被别人改了，需要重试。适合读多写少的场景。
第二种是悲观锁，用SELECT...FOR UPDATE显式加行锁：
START TRANSACTION;
SELECT * FROM users WHERE id = 1 FOR UPDATE;
-- 拿到锁之后再更新
UPDATE users SET phone = '13800138000' WHERE id = 1;
COMMIT;
事务开启后，FOR UPDATE会锁住这行，其他事务的FOR UPDATE必须等锁释放。但要注意，FOR UPDATE只锁其他事务的FOR UPDATE和UPDATE/DELETE，不锁普通的SELECT。如果有服务不通过事务直接UPDATE，还是会覆盖。
分布式场景下，如果多个服务实例并发操作同一行，光靠数据库锁不够。常见做法是在Redis里加分布式锁，或者用消息队列把写操作串行化。我的做法是核心写操作通过消息队列串行处理，牺牲一点延迟，换来确定的写入顺序。
约束：数据库的最后一道防线
老李报表里那批负数金额，就是最典型的例子——应用层没拦住，数据库也没有CHECK约束卡住。
很多人把数据校验全放在应用层，数据库只负责存。但应用代码会改、人会犯错。数据库的约束才是最后一道防线。
我开始给核心表加CHECK约束。逻辑很简单：能用约束卡死的，绝不用代码校验。
ALTER TABLE orders ADD CONSTRAINT chk_amount
CHECK (amount >= 0);
ALTER TABLE orders ADD CONSTRAINT chk_status
CHECK (status IN (0, 1, 2, 3, 4));
ALTER TABLE users ADD CONSTRAINT chk_email
CHECK (email LIKE '%_@__%.__%');
金额不能是负数，状态码只能在预设范围里，邮箱必须符合基本格式。这些约束在数据库层面拦住异常数据，应用层出了错也写不进去。有人担心CHECK约束影响性能。我的经验是，加上之后INSERT慢了不到百分之一，比脏数据进来后花几天排查的代价小得多。
跨列约束。单列CHECK不够用，很多业务规则是跨列的。比如退款金额不能超过订单金额，结束时间不能早于开始时间：
ALTER TABLE orders ADD CONSTRAINT chk_refund
CHECK (refund_amount <= total_amount);
ALTER TABLE campaigns ADD CONSTRAINT chk_time
CHECK (end_time >= start_time);
JSON字段校验。MySQL 5.7之后支持JSON类型。JSON字段也可以用CHECK约束做结构校验：
ALTER TABLE products ADD CONSTRAINT chk_product_attrs
CHECK (
JSON_VALID(attributes) = 1
AND JSON_EXTRACT(attributes, '$.price') > 0
);
JSON_VALID确保插入的是合法JSON，JSON_EXTRACT可以提取JSON里的字段做逻辑判断。这在商品信息、用户画像这种半结构化数据的场景里特别有用。
实际推的时候有阻力。有些同事觉得"数据库只管存，校验是应用的事"。我的做法是从金额、状态码这种零争议的字段开始加，跑一个月没问题再扩展。用事实说服人，比争论有效。
外键约束的取舍。很多人一上来就禁用外键，理由是"影响性能"和"耦合太紧"。这在互联网高并发场景下确实有道理。但在政企和金融系统里，数据一致性的要求远高于性能要求。外键能确保父表删了，子表不会有孤儿记录；子表插入时，父记录必须存在。这种引用完整性检查，用代码写很容易漏。
我的折中方案是：核心表（订单、用户、权限）保留外键，高并发日志表和临时表不设外键。用之前做压力测试，确认外键带来的性能损耗在可接受范围内。在政企和金融场景里，数据一致性的要求更严格。我之前参与过一个项目，用的是KingbaseES，他们对数据校验的要求几乎是苛刻的。KES内置了更完善的数据完整性检查机制，包括字段级约束、跨表约束和业务规则校验。金融级系统里，数据错了就是事故，没有任何商量余地。
从被动救火到主动发现问题
亡羊补牢还不够。你得有一套主动发现问题的机制，不能等用户来投诉"数据不对"。
我设计了一套日常数据校验流程，每天定时跑。
跨表一致性校验。同一份数据在不同表中的状态必须一致。比如订单表和订单明细表的总金额要相等：
SELECT o.order_id, o.total_amount, SUM(d.amount) as detail_sum
FROM orders o
LEFT JOIN order_details d ON o.order_id = d.order_id
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount != IFNULL(detail_sum, 0)
OR d.order_id IS NULL;
这条SQL会找出所有订单总额和明细总额不一致的记录，以及有订单头但没有明细的孤儿记录。每天凌晨跑一次，有异常就发邮件告警。
业务规则扫描。一组SQL每天检查有没有违反业务逻辑的数据：
-- 已完成的订单金额为零
SELECT order_id FROM orders
WHERE status = 2 AND total_amount = 0;
-- 重复手机号
SELECT phone, COUNT(*) as cnt
FROM users
GROUP BY phone
HAVING cnt > 1;
-- 退款金额超过订单金额
SELECT o.order_id, o.total_amount, r.refund_amount
FROM orders o
JOIN refunds r ON o.order_id = r.order_id
WHERE r.refund_amount > o.total_amount;
这些规则看起来简单，但一旦漏掉，脏数据会悄悄扩散到下游报表系统。
唯一索引是防止重复数据的最后一道防线。别相信应用层的去重逻辑，数据库里的UNIQUE索引才是真的管用。
每次批量操作之后，做一次数据抽样检查。导入一万条数据，随机抽一百条手动核对。花不了十分钟，但能发现大问题。
数据变更审计与回溯
查脏数据的时候我最头疼的不是找到问题，而是追不到"谁在什么时候改的"。没有审计记录，你只能看到当前的脏数据，看不到它是怎么变脏的。
MySQL的binlog可以帮你。开启ROW格式的binlog后，每一行数据的变更都会被记录下来。用mysqlbinlog工具可以回溯某个时间段内某张表的所有变更：
mysqlbinlog --base64-output=decode-rows -v \
--start-datetime="2025-01-15 00:00:00" \
--stop-datetime="2025-01-15 23:59:59" \
mysql-bin.000042 | grep -A 20 "### UPDATE"
binlog的输出里会显示UPDATE前后的值。但有个前提：binlog_format必须是ROW。默认的STATEMENT格式只记录SQL语句，不记录行级变化。查binlog适合事后追溯，不适合实时监控。
审计表方案。binlog是运维工具，业务层最好自己建审计表。关键表加一个对应的_audit表，记录每次变更的旧值、新值、操作人、操作时间：
CREATE TABLE users_audit (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_id BIGINT,
old_phone VARCHAR(20),
new_phone VARCHAR(20),
operator VARCHAR(50),
changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
配合TRIGGER自动写入审计记录：
DELIMITER //
CREATE TRIGGER users_audit_trigger
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.phone != NEW.phone THEN
INSERT INTO users_audit (user_id, old_phone, new_phone)
VALUES (OLD.id, OLD.phone, NEW.phone);
END IF;
END//
DELIMITER ;
TRIGGER的好处是自动、不遗漏。只要走了数据库层的UPDATE，审计记录就会生成。应用层不用额外写代码。缺点是TRIGGER多了会影响写性能，所以要谨慎选择哪些字段需要审计。通常只审计核心字段：金额、状态、联系方式、权限。
有了审计表，数据出了問題就不只是"看到脏数据"，而是能完整还原变更链路：谁改的、改之前是什么、改之后是什么。这在排查并发冲突和追溯误操作时非常有用。
数据校验实践要点
建表的时候就把约束写好。哪些字段不能为空、哪些字段有取值范围、哪些组合必须唯一，规矩写在前面，后面省十倍力气。别等脏数据进来了再补救，那时候改约束可能修复不了已有的问题。
批量导入或迁移数据之后必须做抽样核对。不能只看"导入成功"的日志就完事，日志告诉你操作完成了，但不告诉你数据对不对。随机抽几十条手动核对是最直接的办法。
字符集统一用utf8mb4，建库的时候就定好。等数据进来了再改，已有的截断数据不一定能自动修复。
核心表的设计评审时，把约束和索引作为必查项。表结构设计不是定好列名和类型就完了，约束定义是结构的一部分，不能后补。
数据质量体系的搭建，我总结为三个层次：事前用约束和唯一索引拦截异常数据入库，事中外键和TRIGGER确保变更过程的一致性，事后定时校验脚本加binlog审计做兜底和追溯。任何一层都不能省。
那天查完脏数据，我跟财务老李说："问题找到了，但解决不了。"那批数据已经在系统里混了三个月，订单发货的、退款的，全搅在一起。强行修正只会引发更多问题，最后只能标记这批数据，新报表单独统计，旧数据不再修正。能跑和跑得对是两回事，这个教训从那十几万差额开始，我一直记到现在。数据质量不该是出了问题才去管的事——它应该在表设计的时候就写进约束里，在批量操作之后做抽样检查，在日常运维中持续校验。能跑只是起点，跑得对才是目标。
你在数据校验上踩过哪些坑？欢迎在评论区聊聊。
我是数据库小学妹，咱们下篇见 👋
