where条件顺序影响执行效率，数据库默认从左到右评估布尔表达式，高选择性条件前置可减少后续判断行数，但需结合索引、数据分布及避免null、前导like、隐式转换等陷阱。
WHERE条件顺序影响执行路径，不是语法要求而是执行逻辑
MySQL、PostgreSQL、SQL Server 等主流数据库在解析 WHERE 子句时，**默认按从左到右顺序逐个评估布尔表达式**（除非优化器重排）。这意味着：第一个条件匹配失败的行，后续条件根本不会执行。所以把高选择性（即过滤掉最多行）的条件放前面，能直接减少后续判断的行数。
这不是 SQL 标准规定的语法规则，而是底层执行引擎的现实行为。你写 WHERE a=1 AND b LIKE '%x%'，如果 a=1 只命中 0.1% 的数据，那 99.9% 的行在第一步就被筛掉，b 字段根本不用读、不用比——这对 I/O 和 CPU 都是实打实的节省。
高选择性 ≠ 字段值多，而是“结果集缩小比例”高
别被“字段取值种类多”误导。真正关键的是该条件在当前查询上下文中的**实际过滤能力**。比如：
-
order_date > '2024-01-01'在千万级订单表里可能只过滤掉 5%，但若查的是最近 7 天数据，它就是最强条件 -
status = 'cancelled'表面看只有几个枚举值，但如果取消单仅占 0.02%，它就比country = 'CN'（占比 60%）更值得前置 -
user_id IN (1001, 1002, 1003)比created_at BETWEEN ...更早执行，往往更快，尤其当user_id有索引时
判断依据只能是业务数据分布 + EXPLAIN 输出的 rows 估算值，不能凭感觉。
索引存在时，顺序影响可能被优化器覆盖，但不可依赖
现代优化器（如 MySQL 8.0+、PostgreSQL 12+）会基于统计信息重排条件执行顺序，理论上你写错顺序它也能“纠正”。但现实中有几个硬限制：
- 统计信息过期或不准时，优化器会误判，比如
ANALYZE TABLE没跑过 - 复合索引未覆盖全部 WHERE 字段时，优化器可能放弃重排，老老实实按你写的顺序走
- 含函数或表达式的条件（如
YEAR(created_at) = 2024）会让索引失效，此时顺序就彻底由你控制 - 某些 DBMS（如旧版 SQL Server）对 OR / IN / 子查询的重排能力较弱，顺序更关键
所以，**写的时候就按高选择性前置，比赌优化器靠谱得多**。
容易踩的坑：NULL、LIKE、类型隐式转换让“前置”失效
就算你把最狠的条件放第一位，以下情况仍会让它形同虚设：
-
WHERE col = ?传入NULL—— 结果永远为空，因为NULL = NULL不成立，得用col IS NULL -
WHERE name LIKE '%abc'前导通配符导致索引失效，再前置也白搭，应改用全文索引或倒排 -
WHERE user_id = '123'（字符串） vsuser_id是整型 —— 隐式转换让索引失效，执行计划里会出现type: ALL - 多个
OR条件混用，如WHERE a=1 OR b=2 OR c=3，优化器很难有效剪枝，不如拆成UNION ALL
真正起效的前提是：条件本身能走索引 + 能被高效计算 + 无语义陷阱。顺序只是放大器，不是万能药。
