查出有记录但字段为空或为默认值的行需显式检查null、空字符串及业务占位值，如select from users where email is null or trim(email) = ''；关联缺失用not exists；数量比对用count()与count(字段)；隐式类型问题须正则或函数校验。
查出有记录但字段为空或为默认值的行
实际业务里，“存在但不完整”通常指某条记录在表里确实存在，但关键字段是 NULL、空字符串 ''、或占位值如 'N/A'、0（对非数值字段而言）。不能只用 SELECT * 然后肉眼扫——得靠条件过滤。
常见错误是只写 WHERE column = ''，漏掉 NULL；或者用 != 判断时，NULL 会意外被跳过（因为 NULL != 'x' 结果是 UNKNOWN，不满足 WHERE 条件）。
- 用
IS NULL显式检查空值，别用= NULL - 对字符串字段，同时检查
IS NULL和TRIM(column) = ''，避免空格干扰 - 对数值字段，留意业务中是否把“未填写”存为
0或-1，需按约定加判断 - 示例：查用户表里邮箱缺失的记录：
SELECT * FROM users WHERE email IS NULL OR TRIM(email) = '';
用 EXISTS + 子查询定位关联缺失
“存在但不完整”也常出现在关联场景：主表记录存在，但关联的子表数据没补全。比如订单存在，但订单明细为空；用户存在，但没填地址。
这时候 LEFT JOIN 配合 IS NULL 最直接，但要注意驱动表顺序和索引——如果主表很大，而子表筛选条件弱，性能容易崩。
- 优先用
EXISTS而非IN，尤其当子表可能含NULL时，IN行为不可靠 - 示例：查有用户但没创建过任何订单的人：
SELECT id, name FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
- 确保子查询里的关联字段（如
o.user_id）有索引，否则EXISTS也会慢
用 CHECKSUM 或 COUNT(*) 比对预期与实际数量
有些“不完整”是批量级的：比如导入了 1000 条原始数据，但下游处理只生成了 982 条结果记录。这时单查字段没用，得比数量。
别依赖人工数——用聚合和子查询交叉验证。注意 COUNT(*) 和 COUNT(column) 的区别：COUNT(column) 自动忽略 NULL，而 COUNT(*) 统计所有行。
- 查某类业务单据“已创建但未审核”的数量差异：
SELECT COUNT(*) AS total, COUNT(approved_at) AS approved FROM documents;
- 若要定位具体哪些单据没审核，再结合
WHERE approved_at IS NULL - 复杂场景下，可先用
WITHCTE 把各环节数量算出来，再JOIN对比，避免重复扫描大表
警惕隐式类型转换导致的“假完整”
字段看着有值，但实际是错的类型或格式，也算逻辑不完整。比如手机号存成 INT 导致前导零丢失，或时间字段是 VARCHAR 里存了 '2023-13-01' 这种非法日期。
这类问题不会报错，但后续计算或展示会出错。必须用显式校验，不能靠肉眼或简单 IS NOT NULL。
- 日期字段用
IS DATE(column)（MySQL 8.0+）或正则匹配（如column REGEXP '^\d{4}-\d{2}-\d{2}$'） - 数值字段用
column REGEXP '^-?[0-9]+\.?[0-9]*$'防止存了文本如'abc' - 对 JSON 字段，用
JSON_VALID(column)（MySQL）或IS_JSON()（PostgreSQL）确认结构有效
真正难的不是写这条 SQL，而是想清楚“什么才算完整”——这得和业务方一起定义，而不是仅靠技术判断。字段有值，不等于它合法、可用、符合上下文。
