col1 = col2在WHERE中合法但需警惕NULL、类型转换和排序规则：NULL比较恒为UNKNOWN；等值需显式处理NULL相等；字符串注意大小写与尾部空格；数值与字符串比较须显式CAST；JOIN中NULL导致行丢失。
WHERE中用=比较两个字段是否相等，基本写法就是col1 = col2
直接在WHERE子句里写字段对字段的等于判断是完全合法的，比如SELECT * FROM users WHERE name = nickname。这种写法会逐行比对两列值是否严格相等——注意：NULL参与比较时结果恒为UNKNOWN，不是TRUE也不是FALSE，所以该行不会被选中。
常见错误现象：WHERE col1 = col2返回空结果，但肉眼可见有相同值的行。大概率是因为其中一列或两列存在NULL，比如name = NULL或nickname IS NULL时，=不成立。此时不能靠IS NULL补救，因为要同时处理“都非空且相等”和“都为NULL”的情况。
- 若需把NULL也视为“相等”，改用
col1 col2（MySQL专属安全等于操作符） - 标准SQL写法是
(col1 = col2) OR (col1 IS NULL AND col2 IS NULL) - PostgreSQL可直接用
col1 IS NOT DISTINCT FROM col2，语义更清晰
字符串字段比较要注意大小写和尾部空格
多数数据库默认使用区分大小写的排序规则（collation），'ABC' = 'abc'结果为FALSE；同时，SQL标准规定字符串比较会**忽略右端空格**，所以'abc' = 'abc '恒为TRUE。这容易导致误判，尤其当业务逻辑依赖精确字符匹配时。
- MySQL中可通过
BINARY col1 = BINARY col2强制字节级区分大小写比较 - PostgreSQL中用
col1::bytea = col2::bytea或encode(col1::bytea, 'escape') = encode(col2::bytea, 'escape')避开collation影响 - 想保留空格语义？先用
TRIM(BOTH FROM col1) = TRIM(BOTH FROM col2)统一处理，但要注意TRIM本身不改变原始数据
数值字段隐式类型转换可能引发意外结果
当比较如id = version这类字段时，如果id是INT、version是VARCHAR，数据库会尝试隐式转换。MySQL可能把字符串转成数字（'123abc' → 123），PostgreSQL则直接报错operator does not exist: integer = text。
- 显式转换最稳妥：
CAST(col1 AS TEXT) = CAST(col2 AS TEXT)或col1::TEXT = col2::TEXT（PostgreSQL） - 避免在WHERE中对字段用函数（如
STRVAL(id) = version），会导致索引失效 - 检查执行计划（
EXPLAIN）确认是否走了索引——哪怕语法正确，类型不一致也可能退化为全表扫描
JOIN中用字段相等做关联条件，NULL值会让整行丢失
ON t1.a = t2.b是JOIN最常见写法，但只要t1.a或t2.b任一为NULL，该行就不会出现在结果集中。这不是BUG，是SQL三值逻辑的必然表现，但常被当成数据“丢失”。
- 若需保留NULL关联行，必须拆解：
ON (t1.a = t2.b) OR (t1.a IS NULL AND t2.b IS NULL) - LEFT JOIN + 上述OR条件仍可能因重复NULL产生笛卡尔积，需配合
DISTINCT或子查询去重 - 某些场景更适合用
LATERAL（PostgreSQL）或CROSS APPLY（SQL Server）替代硬关联
真正麻烦的从来不是写=，而是没意识到NULL、类型、collation这些隐形因素正在悄悄改写你的逻辑。每次写完col1 = col2，花十秒想想：这两列有没有NULL？类型一样吗？排序规则允许多大偏差？值真的“看起来一样”就等于“数据库认为一样”吗？
