MySQL 查询条件书写顺序不影响索引使用，关键是最左前缀原则和优化器选择；需用 EXPLAIN 验证 key、possible_keys 等字段确认索引是否生效。
MySQL 查询条件的书写顺序本身不会直接影响索引是否被使用，真正起决定作用的是WHERE 子句中字段是否符合索引的最左前缀原则，以及优化器对执行计划的选择。
索引匹配看的是字段位置，不是 SQL 写法顺序
MySQL 的 B + 树索引按定义时的列顺序组织数据。只要 WHERE 条件中包含了索引最左侧连续的列（即满足最左前缀），优化器就可能用上该索引——无论这些列在 SQL 里怎么 排列。
- 例如有联合索引 INDEX idx_name_age (name, age, city)
- 下面两条语句都可能走这个索引：
SELECT * FROM user WHERE age = 25 AND name = ‘ 张三 ’;
SELECT * FROM user WHERE city = ‘ 北京 ’ AND name = ‘ 张三 ’ AND age = 25; - 因为优化器会自动重排条件顺序，判断是否覆盖最左前缀（name → name+age → name+age+city）
但“顺序”间接影响索引效率和选择
虽然语法顺序不决定能否用索引，但它可能影响优化器的判断逻辑和实际执行效果：
- 条件中包含函数或表达式（如 WHERE YEAR(create_time) = 2023）会导致对应字段无法走索引，不管它写在哪
- 类型 隐式转换（如字符串字段与数字比较：WHERE mobile = 13812345678）可能使索引失效
- 如果多个索引都可选，优化器会基于统计信息估算成本；条件书写方式（比如是否带范围、等值还是模糊）会影响它的选择倾向
- 部分老版本 MySQL 对条件顺序更敏感，但现代版本（5.6+，尤其 8.0）已大幅优化了条件重排能力
怎么确认索引到底有没有用？
别猜，直接用 EXPLAIN 看执行计划：
- 重点关注 key 列：显示实际使用的索引名
- 看 possible_keys 是否为空，判断是否有候选索引
- 检查 rows 和 filtered 估算扫描行数，数值越小通常越好
- 若 type 是 ALL 或 index，大概率没走有效索引
实用建议：让索引稳稳生效
- 建索引时按查询高频组合设计，把等值条件列放前面，范围条件（
>,BETWEEN,LIKE 'abc%'）放后面 - 避免在索引列上做计算、函数调用、类型转换
- LIKE 查询以通配符开头（
LIKE '%abc'）无法使用索引，尽量改写或考虑全文索引 - 用 EXPLAIN FORMAT=JSON 查看更详细的访问路径和成本评估
