17370845950

MySQL中=与的区别在于：=遇NULL返回UNKNOWN导致不匹配，为空值安全等号，NULLNULL返回TRUE；查NULL必须用IS NULL或，参数化查询需注意驱动是否自动转换。

WHERE 子句里用 = 和 的区别必须分清

MySQL 中 = 是常规等值判断，但遇到 NULL 会返回 UNKNOWN（即不匹配），而 是“空值安全等号”，NULL NULL 返回 TRUE。实际查数据时如果字段允许为 NULL，又想把空值也纳入条件，用 = 会漏掉记录。

常见错误现象：SELECT * FROM user WHERE phone = NULL 查不到任何结果，哪怕表里真有 phone 为 NULL 的行。

• 查明确为 NULL 的数据，写成 WHERE phone IS NULL 或 WHERE phone NULL
• 查非空且等于某个值的，仍用 =，比如 WHERE status = 'active'
• 做参数化查询时（如 PHP PDO），绑定 NULL 值后，底层可能生成 = ?，此时若字段含空值，逻辑就和预期不符 —— 得确认驱动是否自动转成 ?，否则手动改写

字符串模糊匹配别只靠 LIKE，注意 ESCAPE 和大小写

LIKE 看似简单，但 % 和 _ 是通配符，如果要查真实包含下划线的用户名（如 'user_name'），直接写 WHERE name LIKE '%_name%' 会误匹配 'username'、'usename' 等。

• 指定转义字符：加 ESCAPE '\' 后，写成 WHERE name LIKE '%\_name%' ESCAPE '\'
• 大小写敏感性取决于字段的 collation，utf8m

  

  b4_bin 下 'A' != 'a'，而 utf8mb4_general_ci 默认忽略大小写；不确定时用 BINARY 强制： WHERE BINARY name = 'Admin'
• 性能提示：前导通配符（如 LIKE '%abc'）无法走索引，尽量用 LIKE 'abc%' 或考虑全文索引、生成列 + 普通索引

多个条件组合时 AND/OR 优先级容易出错

MySQL 中 AND 优先级高于 OR，没加括号时，WHERE status = 'active' OR type = 'vip' AND level > 5 实际等价于 WHERE status = 'active' OR (type = 'vip' AND level > 5)，而不是你以为的 (status = 'active' OR type = 'vip') AND level > 5。

• 所有含 OR 的复合条件，只要逻辑不是纯线性叠加，一律显式加括号
• 用 IN 替代一长串 OR： WHERE id IN (1, 5, 9, 12) 更清晰，也更易维护
• 注意 IN 对 NULL 的处理： WHERE id IN (1, 2, NULL) 整个条件恒为 FALSE，因为 id = NULL 永远不成立 —— 如果需要兼容空值，拆开写或用 IS NULL

WHERE 中函数操作会让索引失效，得看执行计划

写 WHERE YEAR(create_time) = 2025 看似直观，但 MySQL 无法用 create_time 上的索引，因为函数改变了字段原始值。同理，UPPER(name) = 'JOHN'、DATE(update_at) = '2025-06-01' 都有这个问题。

• 改写为范围查询：用 WHERE create_time >= '2025-01-01' AND create_time
• 对固定格式转换，可建函数索引（MySQL 8.0+）：CREATE INDEX idx_upper_name ON user ((UPPER(name)))
• 务必用 EXPLAIN 验证：重点关注 type（应为 ref/range）、key（是否用了预期索引）、rows（扫描行数是否合理）

复杂点在于，有些隐式转换更难察觉，比如字段是 VARCHAR 却传入数字参数：WHERE mobile = 13812345678，MySQL 会把字段转成数字比对，同样导致索引失效 —— 这类问题在线上慢查日志里才容易暴露出来。