查数据异常需用sql函数精准检测：null用count(*)与count(字段)对比；空字符串用length=0；非法字符用regexp；数字类型错位用!=cast；时间有效性用is_valid_date或str_to_date。
查完数据后怎么快速发现字段值缺失或异常
直接看 SELECT 结果容易漏掉隐性问题：空字符串、NULL、默认值（比如 '0000-00-00'）、超长截断、类型错位（数字存成字符串）。验证不能只靠肉眼。
- 先用
COUNT(*)和COUNT(字段名)对比，差值就是该字段的NULL数量 - 对文本字段加
WHERE LENGTH(字段名) = 0检查空字符串；用REGEXP或LIKE排查非法字符（如WHERE 字段名 REGEXP '[^a-zA-Z0-9_\- ]'） - 数值字段用
WHERE 字段名 != CAST(字段名 AS SIGNED)快速揪出“看着像数字实为字符串”的脏数据 - 时间字段优先用
IS_VALID_DATE()（MySQL 8.0.22+）或STR_TO_DATE(字段名, '%Y-%m-%d')是否返回NULL来判断格式有效性
JOIN 后数据行数突变，怎么定位是哪张表丢/多数据
常见于 LEFT JOIN 后总行数比左表少（说明 ON 条件太严），或多出几倍（右表有重复关联键）。关键不是看结果，而是分别验证连接键的分布。
- 查左表连接键的去重数：
SELECT COUNT(DISTINCT key_col) FROM left_table - 查右表连接键的去重数 + 出现频次：
SELECT key_col, COUNT(*) FROM right_table GROUP BY key_col HAVING COUNT(*) > 1 - 用
SELECT left_table.key_col, COUNT(right_table.key_col) FROM left_table LEFT JOIN right_table ON ... GROUP BY left_table.key_col HAVING COUNT(right_table.key_col) = 0找出没匹配上的左表记录
分页查询时 LIMIT OFFSET 越往后越慢，验证逻辑也跟着失效
偏移量大时，数据库仍要扫描前 N 行，不仅慢，还可能因并发写入导致跳过或重复数据——验证逻辑如果依赖“第 10001 条应该是什么”，就不可靠。
- 改用游标分页：用上一页最后一条的
id或created_at作为下一页起点，例如WHERE id > 12345 ORDER BY id LIMIT 100 - 验证时别比“绝对位置”，改比“相对一致性”：比如取当前页首尾两条记录的
id，再反查是否仍能通过相同 WHERE 条件捞出——避免依赖 OFFSET - 禁止在验证脚本里拼接
LIMIT 10000, 100，尤其当表有频繁更新时，结果不具备可重现性
导出 CSV 后 Excel 打开乱码或字段错位，验证逻辑全跑偏
根本原因常是导出没指定编码或没处理分隔符。CSV 不是“随便逗号分隔就行”，Excel 默认用 ANSI（如 GBK），而数据库和脚本多用 UTF-8，且字段含换行、逗号、引号时会直接破坏结构。
- 导出必须显式声明编码：MySQL 用
INTO OUTFILE ... CHARACTER SET utf8mb4；PostgreSQL 用COPY ... WITH (ENCODING 'UTF8') - 字段值含特殊字符时，确保用双引号包裹，并转义内部双引号（变成两个双引号），否则
"name":"Alice"Smith"会被 Excel 当成两列 - 验证脚本读 CSV 时，别用简单
split(',')，要用标准 CSV 解析器（如 Python 的csv模块），否则字段错位会导致完整性校验完全失真
真正麻烦的不是写验证逻辑，而是验证所依赖的数据本身是否被中间环节悄悄篡改过——导出编码、JOIN 语义、分页机制、甚至客户端显示层，都可能让“看到的数据”和“实际数据”不一致。
