sql中where col_a = col_b无法匹配null值，因null=anything结果为unknown；安全写法需显式处理：非空相等用“and col_a is not null and col_b is not null”，空安全相等用“or (col_a is null and col_b is null)”或mysql特有运算符。
WHERE 中直接用 = 比较两列是否相等，但 NULL 会导致意外结果
直接写 WHERE col_a = col_b 看似合理，但只要其中一列（或两列）某行值为 NULL，这一行就**永远不会被选中**——因为 SQL 中 NULL = anything 的结果是 UNKNOWN，而 WHERE 只接受 TRUE 的行。
这不是 bug，是三值逻辑的必然行为。常见于用户表中 email 和 backup_email 对比、日志表中 old_value 与 new_value 是否变更等场景。
实操建议：
- 若业务上明确要排除
NULL参与比较，且只关心非空相等，WHERE col_a = col_b AND col_a IS NOT NULL AND col_b IS NOT NULL是最安全写法 - 若想把“都为
NULL”也视为“相等”，必须显式写出：WHERE (col_a = col_b) OR (col_a IS NULL AND col_b IS NULL) - 某些数据库（如 PostgreSQL）支持
IS NOT DISTINCT FROM，可简化为：WHERE col_a IS NOT DISTINCT FROM col_b—— 它天然把两个NULL当作相等，但注意 MySQL 和 SQL Server 不支持该语法
MySQL 中用
MySQL 提供了空安全等于运算符 ，它把 NULL NULL 视为 TRUE，其他行为与 = 一致。这是 MySQL 特有语法，不跨数据库兼容，但对快速验证两列逻辑一致性很实用。
示例：
SELECT * FROM users WHERE email backup_email;
这会返回所有 email 和 backup_email 值相同（含两者均为 NULL）的记录。但要注意：
-
不能用于索引优化：即使email有索引，email 'xxx'通常仍能走索引，但email NULL在老版本 MySQL 中可能无法使用索引，建议执行EXPLAIN确认 - 它不适用于
ORDER BY或函数参数位置（比如不能写IF(col_a col_b, 1, 0)），部分版本会报错，应改用IS NULL显式判断
需要统计“相等/不等比例”时，别在 WHERE 里硬过滤，改用 CASE 行内判别
如果目标不是筛选数据，而是看两列匹配率（比如审计字段一致性），在 WHERE 中反复加条件容易漏掉统计基线。更稳的方式是在 SELECT 中用 CASE 计算布尔状态，再聚合。
示例（兼容所有主流 SQL）：
SELECT<br> COUNT(*) AS total,<br> COUNT(CASE WHEN col_a = col_b THEN 1 END) AS equal_count,<br> COUNT(CASE WHEN col_a = col_b OR (col_a IS NULL AND col_b IS NULL) THEN 1 END) AS equal_nullsafe_count<br>FROM my_table;
这样避免了因 WHERE 过滤导致分母丢失，也清晰分离了“严格相等”和“空安全相等”两种口径。尤其当表很大、且 NULL 占比高时，这种写法还能减少重复扫描。
WHERE 中比较两列前，先确认数据类型是否隐式转换
如果 col_a 是 VARCHAR 而 col_b 是 INT，某些数据库（如 MySQL）会在比较前自动转成数字，导致 '123abc' 变成 123，和 123 判定为相等——这显然违背语义。PostgreSQL 则直接报错，SQL Server 可能截断或抛异常。
排查方法：
- 查表结构：
DESCRIBE table_name或SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE ... - 临时加 CAST 强制统一类型：
WHERE CAST(col_a AS CHAR) = CAST(col_b AS CHAR)（注意长度截断风险） - 生产环境强烈建议在建表时就对齐语义相同的列类型，避免后期靠函数补救
类型不一致带来的问题往往藏得深：查询结果看似正确，但索引失效、排序错乱、或某天导入新数据后突然不等了。
