sql多条件查询性能关键在索引匹配而非where顺序；复合索引需按高频等值、中等区分度、范围查询排序；in/or/exists语义不同，应据场景选用；隐式类型转换和字符集不匹配会导致索引失效。
SQL WHERE 条件组合查询的性能，关键不在“写得对不对”，而在于“数据库能不能高效用上索引”。很多慢查询不是逻辑错，是条件顺序、数据分布或索引设计没匹配执行路径。
WHERE 中多个条件，顺序真的不重要？
对大多数主流数据库（如 MySQL 8.0+、PostgreSQL、SQL Server），WHERE 子句中 AND 条件的书写顺序 不影响优化器选择执行计划——优化器会基于统计信息重排条件评估顺序。但有两个现实例外：
- 当使用 函数或表达式包裹字段（如
WHERE UPPER(name) = 'TOM'），该条件无法走索引，无论写在第几位；应改用函数索引或规范存储（如统一小写） - 在 MySQL 5.7 及更早版本 + B-tree 索引下，如果复合索引是
(a, b, c)，那么WHERE b = ? AND a = ?仍可能走索引（因优化器可调整顺序），但WHERE b = ? AND c = ?就完全失效——缺少最左前缀a
如何让多条件真正“命中”复合索引？
核心原则：索引列顺序要匹配 高频过滤 + 高区分度 + 范围查询位置 的综合权重。例如查询常为：
WHERE status = 'active' AND city = 'shanghai' AND create_time > '2024-01-01'
- status 区分度低（只有 active/inactive），但常用于精准等值，适合放索引前面
- city 区分度中等，也是等值，可居中
- create_time 是范围查询，必须放在复合索引 最后一位（B-tree 中范围之后的列无法用于索引查找）
推荐索引：INDEX idx_status_city_time (status, city, create_time)。若把 create_time 放第一位，整个索引对这个 WHERE 几乎无效。
IN、OR 和 EXISTS 怎么选才不拖慢？
三者语义不同，性能差异明显，不能简单互换：
-
IN (少量确定值)：如
WHERE user_id IN (101, 205, 318)，等价于多个 OR，现代优化器通常能高效展开并走索引 -
IN (子查询)：如
WHERE user_id IN (SELECT id FROM vip_users)，MySQL 早期版本易转成 NESTED LOOP，建议改用JOIN或EXISTS；MySQL 8.0+ 已支持半连接优化，但仍需检查执行计划 -
OR 多条件：如
WHERE a = 1 OR b = 2，除非a和b共享同一索引（如(a,b)），否则通常无法走索引——考虑拆成 UNION ALL（注意去重成本） - EXISTS：适合“是否存在关联记录”场景，通常比 IN(子查询) 更稳定，尤其子查询结果集大时；但若子查询无相关列（即非关联子查询），IN 可能反而更快
别忽略隐式类型转换和字符集陷阱
这类问题不会报错，但直接导致索引失效：
-
WHERE mobile = 13812345678：字段是VARCHAR，传入数字 → 触发隐式转换 → 全表扫描。应写成'13812345678' -
WHERE name = ?，参数是 utf8mb4，但字段是 latin1 → 字符集不匹配 → 索引失效。建表/字段统一用 utf8mb4，并确保连接层编码一致 - 日期字段用字符串比较：
WHERE dt >= '2024-05'（缺日）→ 无法走索引；应补全或改用范围：dt >= '2024-05-01' AND dt
