普通等号=在遇到NULL时返回NULL，而（安全等于）使NULL=NULL返回TRUE；WHERE col = NULL永不生效，须用IS NULL；现代MySQL已移除EQUAL()函数；大小写敏感性由字段collation决定；JOIN中通常用=，仅当需NULL匹配时才用。
MySQL里=和
直接说结论：普通等号=在遇到NULL时会返回NULL（不是TRUE也不是FALSE），而是“安全等于”，NULL NULL返回TRUE。这不是风格选择，是逻辑结果差异。
常见错误现象：WHERE col = NULL永远不生效，查不到任何行，连NULL值都过滤不掉——因为=不能判断NULL相等，得用IS NULL。
-
=适用于确定非空字段的常规比较，比如status = 'active' -
适合需要把NULL当普通值参与比较的场景，比如合并两个表时做ON a.id b.id，避免NULL导致关联失败 - 性能上无差别，但语义不同：用
=写col = NULL会被优化器识别为无效条件，可能跳过索引
为什么EQUAL()函数几乎没人用
MySQL确实有EQUAL()这个函数，但它只存在于极老版本（5.0之前），**现代MySQL（5.7+）已移除该函数**。你如果在文档或旧代码里看到EQUAL(col1, col2)，运行时会报错：ERROR 1305 (42000): FUNCTION db.EQUAL does not exist。
使用场景几乎不存在——它当年的设计意图就是模仿，但语法更啰嗦、无索引支持、无法下推到存储引擎。现在所有合理需求都由覆盖。
- 别在新项目里找
EQUAL()函数，它不在手册里，也不在INFORMATION_SCHEMA.ROUTINES中 - 如果迁移老系统遇到这个报错，直接替换成
即可，行为完全一致 - 注意：某些ORM（如旧版Django）生成的SQL曾带
EQUAL()，升级MySQL后必须调整方言配置
字符串比较时大小写敏感怎么控制
MySQL的=和是否区分大小写，**取决于字段的排序规则（collation）**，不是操作符本身决定的。比如utf8mb4_general_ci不区分，utf8mb4_bin就区分。
容易踩的坑：你以为'ABC' = 'abc'该返回FALSE，结果却是TRUE——不是bug，是collation在起作用。
- 查字段排序规则：
SHOW FULL COLUMNS FROM table_name LIKE 'col_name';，看Collation列 - 临时强制二进制比较：
'ABC' = 'abc' COLLATE utf8mb4_bin→ 返回FALSE - 建表时明确指定：
name VARCHAR(50) COLLATE utf8mb4_bin，比每次加COLLATE更可靠 - 注意：
同样受collation影响，它不改变比较逻辑，只解决NULL问题
JOIN里用=还是
绝大多数JOIN应该用=，除非你明确要让NULL值也能匹配上。但这里有个关键细节：**标准SQL的JOIN ... ON条件中，=对NULL的处理会导致整行被过滤掉；而会让NULL与NULL配对成功**。
典型误用：LEFT JOIN后想保留右表NULL记录，却在ON里写了a.id = b.id，结果b.id为NULL的行根本不出现在结果里——因为=返回NULL，被当作不满足条件。
- 如果业务允许
NULL作为有效关联值（比如未分配ID的临时记录），用a.id b.id - 但要注意：这样可能导致笛卡尔积风险，比如左表10个
NULL，右表5个NULL，会产出50行 - 更稳妥的做法是提前清洗数据，或用
COALESCE(a.id, -1) = COALESCE(b.id, -1)，前提是-1不会真实存在
真正麻烦的是嵌套子查询里混用=和，尤其当子查询可能返回NULL时——一个没注意，WHERE id = (SELECT ...)就变成永假，连NULL结果都吃不进去。这时候要么改用IN，要么确认子查询加WHERE ... IS NOT NULL，或者干脆换但得同步检查业务含义是否允许NULL匹配。
