最直接可靠的方法是查看SQL执行计划，它明确显示数据库优化器选择的访问路径，如全表扫描或索引扫描；不同数据库通过EXPLAIN（MySQL/PG/Oracle）或执行计划按钮（SQL Server）获取，重点关注type、key、rows、Extra等字段判断索引使用情况。
看SQL查询是否走索引，最直接可靠的方法是查看它的执行计划（Execution Plan）。执行计划会明确显示数据库优化器实际选择的访问路径，比如是全表扫描（Seq Scan 或 TABLE SCAN），还是用了某个索引（Index Scan、Index Range Scan、Index Seek等）。
怎么看执行计划（不同数据库）
不同数据库查看方式略有差异，但核心思路一致：让数据库返回它“打算怎么执行”这条SQL。
-
MySQL：在SQL前加 EXPLAIN 或 EXPLAIN FORMAT=TRADITIONAL（5.7+），例如：
EXPLAIN SELECT * FROM users WHERE user_id = 123; -
PostgreSQL：用 EXPLAIN 或更直观的 EXPLAIN ANALYZE（会真实执行并返回耗时）：
EXPLAIN ANALYZE SELECT name FROM products WHERE price > 99; - SQL Server：在SSMS中点击“包含实际执行计划”按钮（Ctrl+M），或用 SET STATISTICS XML ON；也可用 EXPLAIN（Azure SQL / 新版本支持）
- Oracle：用 EXPLAIN PLAN FOR + SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
关键字段怎么看（以MySQL EXPLAIN为例）
重点关注以下几列：
-
type：表示连接类型，越靠前性能通常越好。常见值从优到劣：
system ≈ const > eq_ref > ref > range > index > ALL
其中 ALL 表示全表扫描（没走索引），range 和 ref 一般说明走了索引 - key：实际使用的索引名。为 NULL 表示没走索引（但不绝对，需结合其他字段判断）
- key_len：索引使用长度（字节数）。值越大，通常说明索引利用越充分（比如联合索引用了前两列 vs 只用第一列）
- rows：预估扫描行数。数字越小越好；若远大于结果集行数，可能索引失效或统计信息不准
-
Extra：重要补充信息。
出现 Using filesort 或 Using temporary 往往意味着排序/分组没走索引，性能风险高；
Using index 表示覆盖索引（只查索引就完成，不回表），是理想状态
常见“看似有索引却没走”的原因
即使字段上有索引，也不代表一定被用上。典型情况包括：
- WHERE条件对字段做了函数操作或运算：
WHERE YEAR(create_time) = 2023 → 应改写为 WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' -
隐式类型转换：
索引字段是 VARCHAR，但传入的是数字 WHERE mobile = 13800138000 → MySQL会转成字符串比较，可能失效 - LIKE 以通配符开头：
WHERE name LIKE '%abc' 无法使用索引；WHERE name LIKE 'abc%' 可以 - OR 条件中部分字段无索引：
WHERE a = 1 OR b = 2，如果只有 a 有索引，b 没索引，整个条件可能放弃索引走全表 - 数据分布倾斜严重（如某值占比超 20%）：优化器可能认为全表扫描比索引回表更快
辅助验证的小技巧
除了看执行计划，还可以快速交叉验证：
- 强制走索引测试（慎用）：
MySQL 加 FORCE INDEX(idx_name)，观察执行计划和执行时间变化 - 对比 EXPLAIN 和 EXPLAIN ANALYZE（PG）或 SHOW PROFILE（MySQL）：看预估 vs 实际是否偏差大，判断统计信息是否过期
- 检查索引有效性：
SHOW INDEX FROM table_name; 确认索引存在且状态正常；
用 ANALYZE TABLE table_name; 更新统计信息（尤其数据大量变更后）
