where子句必须紧跟在select/update/delete后且在from之后，字符串需加引号、null用is null判断、混用and/or须加括号、in遇null失效、between为闭区间、like通配符影响索引、字段函数调用导致全表扫描。
WHERE 子句的基本写法和常见错误
WHERE 是 MySQL 中执行行级过滤的核心，它必须紧跟在 SELECT、UPDATE 或 DELETE 语句之后（且在 FROM 之后），不能单独使用。最常见的错误是把字符串值漏掉引号，比如写成 WHERE name = zhangsan —— 这会让 MySQL 把 zhangsan 当作列名或未定义变量，直接报错 Unknown column 'zhangsan' in 'where clause'。
正确写法必须加引号：WHERE name = 'zhangsan'（单引号是标准，双引号在 SQL_MODE 允许下也可用，但不推荐）。
- 数字类型可不加引号：
WHERE id = 123 - 日期建议用标准格式字符串：
WHERE created_at >= '2024-01-01' - NULL 判断不能用
=，必须用IS NULL或IS NOT NULL
多个条件组合：AND、OR、NOT 和括号优先级
实际查询中很少只用一个条件。AND 和 OR 控制逻辑关系，但它们有默认优先级：AND 优先于 OR。不加括号容易出意料结果，比如 WHERE status = 'active' OR type = 'vip' AND score > 80 实际等价于 WHERE status = 'active' OR (type = 'vip' AND score > 80)，而不是你可能想表达的「活跃用户且（VIP 或高分）」。
实操建议：
- 只要混用
AND和OR，一律显式加括号，比如：WHERE status = 'active' AND (type = 'vip' OR score > 80) -
NOT尽量作用于最小逻辑单元，如NOT (a = 1 AND b = 2)比NOT a = 1 AND NOT b = 2更易读且不易错 - 避免过度嵌套，复杂条件可考虑拆到应用层拼接，或用视图/CTE 简化
IN、BETWEEN、LIKE 这些“快捷条件”的坑
IN 看似简单，但遇到 NULL 值会静默失效：WHERE id IN (1, 2, NULL) 实际等价于 WHERE id IN (1, 2)，因为 id = NULL 永远返回 UNKNOWN，不参与匹配。
BETWEEN 是闭区间，WHERE age BETWEEN 18 AND 25 包含 18 和 25，这点和某些编程语言的 range 习惯不同。
LIKE 的通配符要小心索引失效：
-
name LIKE 'abc%'可走索引（前缀匹配） -
name LIKE '%abc'或name LIKE '%abc%'通常无法使用普通 B+Tree 索引，除非用了全文索引或倒排索引（如 MySQL 8.0+ 的 ngram） - 如果字段是大小写敏感 collation，
LIKE 'ABC%'不会匹配小写数据；不确定时用LOWER(name) LIKE LOWER('abc%')，但会进一步抑制索引
WHERE 中函数调用对性能的影响
在 WHERE 条件里对字段使用函数（如 WHERE YEAR(created_at) = 2024 或 WHERE UPPER(name) = 'ZHANG'）会导致该字段无法使用索引，MySQL 必须全表扫描计算每行函数值。
更高效的做法是让条件适配索引结构：
- 时间范围改用区间：
WHERE created_at >= '2024-01-01' AND created_at - 大小写统一改在写入时处理，或建函数索引（MySQL 8.0.13+ 支持）：
CREATE INDEX idx_name_upper ON users ((UPPER(name))) - 模糊搜索需求高，考虑引入 Elasticsearch 或用 MySQL 的
FULLTEXT索引 +MATCH ... AGAINST
WHERE 看似简单，但每个字符都可能决定是毫秒还是秒级响应——尤其是当表超过百万行后，函数、隐式类型转换、NULL 处理这些细节会立刻暴露出来。
