MySQL等值比较全面指南：NULL处理、大小写敏感与最佳实践
在MySQL数据库操作中，判断两个值是否相等是最核心的查询操作之一。然而，这个看似简单的任务却涉及NULL值陷阱、大小写敏感性和操作符选择等多个关键细节。本文将深入解析MySQL等值比较的机制，帮助开发者规避常见错误，写出高效可靠的SQL语句。
MySQL中=与
核心区别在于NULL值处理：标准等号=遇到NULL时会返回NULL（既非TRUE也非FALSE），而是“安全等于”操作符，NULL NULL会返回TRUE。这是底层逻辑的本质不同，而非编码风格问题。
一个典型错误是使用WHERE column = NULL查询，这种写法永远无法返回任何行，甚至无法筛选出NULL值记录。因为=无法判断NULL相等性，正确写法应为WHERE column IS NULL。
=适用场景：适用于对非空字段进行常规值比较，如status = 'active'、user_id = 1001。适用场景：需要将NULL视为有效值进行比较的场景，例如表连接时使用ON a.id b.id，可避免因NULL导致关联失败。- 性能与语义考量：两者性能无明显差异，但语义截然不同。需注意
col = NULL可能被查询优化器识别为无效条件，从而影响索引使用效率。
为什么MySQL中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，升级MySQL后需调整对应的方言配置。
MySQL字符串比较：如何控制大小写敏感性
关于=和比较字符串时是否区分大小写，关键点在于：**这完全由字段的排序规则（collation）决定，而非操作符本身。** 例如，使用utf8mb4_general_ci（ci表示case-insensitive）时不区分大小写，而utf8mb4_bin（二进制比较）则区分大小写。
常见误解是预期'MySQL' = 'mysql'返回FALSE，实际却得到TRUE。这并非系统错误，而是collation规则在起作用。
- 查看字段排序规则：执行
SHOW FULL COLUMNS FROM table_name LIKE 'column_name';，查看Collation列即可获知字段的排序规则。 - 临时强制区分大小写：可通过
COLLATE子句临时指定，如'ABC' = 'abc' COLLATE utf8mb4_bin，此时将返回FALSE。 - 建表时明确指定：最可靠的方法是在建表时直接定义：
username VARCHAR(50) COLLATE utf8mb4_bin，这比每次查询都添加COLLATE更清晰高效。 - 重要提示：
操作符同样受collation影响，它仅解决NULL比较问题，不改变底层的大小写比较逻辑。
JOIN操作中=与
在表连接操作中，绝大多数情况应使用=，除非业务逻辑明确要求NULL值也能成功匹配。关键细节在于：**在JOIN ... ON条件中使用=时，遇到NULL值该条件评估为NULL，导致整行被过滤；而使用则允许NULL与NULL匹配成功。**
典型误用场景：使用LEFT JOIN希望保留右表为NULL的记录，但ON条件写了a.id = b.id。结果发现b.id为NULL的行未出现在结果集中——因为=返回NULL，被MySQL视为条件不满足。
使用时机：当业务逻辑允许NULL作为有效关联值时（如代表未分配ID的临时记录），可使用a.id b.id。- 注意笛卡尔积风险：但需警惕可能产生的笛卡尔积。例如左表有10个NULL，右表有5个NULL，使用
关联将产生10×5=50行匹配结果。 - 更安全的替代方案：通常更稳妥的做法是提前清洗数据，或使用
COALESCE(a.id, -1) = COALESCE(b.id, -1)（前提是-1等占位符在实际业务中不存在）。
复杂情况出现在嵌套子查询中混用=和，特别是子查询可能返回NULL时。例如WHERE id = (SELECT ...)这样的条件可能永远为假，甚至无法处理NULL结果。应对策略包括改用IN子句、确保子查询添加WHERE ... IS NOT NULL条件，或换用操作符（但需确认业务逻辑允许NULL匹配）。
