最准确的方法是使用EXPLAIN查看执行计划，重点关注type（避免ALL）、key（非NULL）、rows（越小越好）和Extra（避免Using filesort）；注意隐式类型转换、函数、模糊查询、计算及联合索引最左前缀等索引失效场景。
直接看执行计划（EXPLAIN）是最准确的方法，它能清楚显示MySQL是否用到了索引、用了哪个索引、扫描了多少行。
用 EXPLAIN 分析查询语句
在 SELECT 语句前加上 EXPLAIN，例如：
EXPLAIN SELECT * FROM users WHERE email = 'a@b.com';重点关注以下几列：
- type：表示连接类型，常见值从好到差为 const > eq_ref > ref > range > index > ALL。出现 ALL 说明全表扫描，基本没走索引；range 或更优说明用了索引。
- key：实际使用的索引名。为 NULL 表示未使用索引。
- rows：MySQL 预估需要扫描的行数。数值越小越好，远小于表总行数通常说明索引有效。
- Extra：出现 Using where; Using index 是理想情况（覆盖索引）；出现 Using filesort 或 Using temporary 可能意味着排序或分组没走索引，需优化。
注意隐式类型转换导致索引失效
当查询条件字段类型与传入值类型不一致时，MySQL 可能自动转换，使索引失效。例如：
-- 假设 phone 是 VARCHAR 类型
SELECT * FROM users WHERE phone = 13800138000; -- 错误：数字字面量触发隐式转换
SELECT * FROM users WHERE phone = '13800138000'; -- 正确：字符串匹配，可走索引
其他常见陷阱包括：
- 对索引列使用函数，如 WHERE YEAR(create_time) = 2023
- 使用 LIKE '%abc' 开头的模糊查询
- 索引列参与计算，如 WHERE score + 10 > 90
- 联合索引未按最左前缀使用，如索引是 (a,b,c)，但只查 WHERE b = 1
检查索引是否存在且合理
即使写了 WHERE 条件，若没有对应索引，自然无法使用。确认方式：
- 用 SHOW INDEX FROM table_name; 查看已有索引
- 确保查询条件中涉及的字段有单列索引，或组合条件匹配联合索引的最左前缀
- 注意索引选择性：区分度高的字段（如 email）更适合建索引，而性别、状态等低区分度字段单独建索引效果差
- 避免冗余索引，例如已有 (a,b) 索引，再建 (a) 就意义不大
借助慢查询日志和 performance_schema 辅助判断
开启慢查询日志（slow_query_log=ON），设置 long_query_time，可捕获未走索引的慢 SQL。进一步可通过：
- performance_schema.table_io_waits_summary_by_index_usage 查看各索引的实际使用频次（MySQL 5.6+）
- 配合 sys.schema_unused_indexes 视图识别长期未被使用的索引（MySQL 5.7+ sys schema）
