SQL条件书写顺序通常不影响性能，因优化器会重写谓词、评估选择率并选择最优路径；真正关键的是索引设计、避免非SARGable写法、查看执行计划及更新统计信息。
SQL条件的书写顺序通常不会直接影响执行性能，因为现代数据库优化器（如MySQL、PostgreSQL、SQL Server）在生成执行计划前，会先对WHERE子句进行逻辑等价重写和代价估算，自动调整谓词顺序以提升效率。
优化器如何处理WHERE条件
数据库不会按你写的顺序逐个判断条件，而是：
- 解析所有条件，识别索引可用性（比如
WHERE a = 1 AND b > 10中，若只有a有索引，优化器会优先用它过滤） - 估算每个条件的选择率（selectivity），优先使用“过滤性最强”的条件（即能快速减少数据量的条件）
- 结合统计信息（如直方图、行数、索引分布）选择最优访问路径（索引扫描、全表扫描、索引合并等）
哪些情况会让“手写顺序”看似有影响
个别场景下，人为调整顺序可能间接起作用，但本质不是语法顺序决定性能，而是暴露了底层问题：
-
短路求值在特定引擎中存在：例如SQL Server对
AND表达式可能按书写顺序做部分短路（但不保证，且优化器常会重排）；MySQL 8.0+基本忽略书写顺序 -
函数或表达式阻断索引使用：写成
WHERE YEAR(create_time) = 2023 AND status = 1，即使status选择率高，YEAR()也会让整个条件无法走create_time索引；应改写为create_time BETWEEN '2023-01-01' AND '2023-12-31' -
隐式类型转换导致索引失效：如
WHERE mobile = 13800138000（mobile是VARCHAR），数据库可能转成WHERE CAST(mobile AS SIGNED) = 13800138000，破坏索引；应统一类型：WHERE mobile = '13800138000'
真正影响性能的关键点
比起纠结条件顺序，更应关注这些可落地的优化方向：
- 为高频查询字段建立合适索引，尤其组合索引注意最左匹配原则（如查询
WHERE category = ? AND state = ? AND create_time > ?，推荐索引(category, state, create_time)） - 避免在索引列上使用函数、计算、NOT、!=、LIKE '%xxx'等非SARGable写法
- 用
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）看实际执行计划，确认是否走了预期索引、是否回表、是否有临时表/文件排序 - 定期更新表统计信息（如
ANALYZE TABLE），让优化器估算更准确
不复杂但容易忽略。
