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，
utf8mb4_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) = 2023 看似直观，但 MySQL 无法用 create_time 上的索引，因为函数改变了字段原始值。同理，UPPER(name) = 'JOHN'、DATE(update_at) = '2024-06-01' 都有这个问题。
- 改写为范围查询：用
WHERE create_time >= '2023-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 会把字段转成数字比对，同样导致索引失效 —— 这类问题在线上慢查日志里才容易暴露出来。
