查索引需综合结构、状态与使用情况:用show index看基本结构,information_schema.statistics支持跨库筛选,show create table还原建表意图,explain验证实际生效。

查索引不是只看“有没有”,关键在看清结构、判断状态、确认是否真被用。下面这几种方法,按使用场景分清楚,效率高还不容易漏掉细节。
SHOW INDEX:快速看清索引基本结构
这是最常用也最直观的方式,适合日常巡检或快速确认索引组成:
-
基础用法:直接执行
SHOW INDEX FROM users;,若当前已选库;或指定库SHOW INDEX FROM users FROM mydb; -
重点字段含义:
-
Key_name:索引名,
PRIMARY表示主键,idx_email这类是自定义名 -
Column_name + Seq_in_index:联合索引中各列的顺序和位置,比如
email在第1位、status在第2位,说明是(email, status)联合索引 - Non_unique:0 是唯一索引(含主键、UNIQUE),1 是普通索引
- Cardinality:索引列去重值估算,越大通常选择性越好;明显偏低(如远小于表总行数)可能提示索引失效或数据倾斜
-
Key_name:索引名,
- 注意点:返回空结果 = 该表确实没有索引(不含主键),可放心下结论
INFORMATION_SCHEMA.STATISTICS:灵活筛选与跨库分析
适合写脚本、做批量检查,或需要加条件过滤(比如查某列上有哪些索引):
-
查指定表所有索引:
SELECT INDEX_NAME, COLUMN_NAME, SEQ_IN_INDEX, NON_UNIQUE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'mydb' AND TABLE_NAME = 'users'; -
排除主键,只看辅助索引:
AND INDEX_NAME != 'PRIMARY' -
查某字段是否被多个索引覆盖(冗余线索):
AND COLUMN_NAME = 'email' - 优势:字段命名规范、支持 WHERE 条件、可 JOIN 其他系统表,自动化运维友好
SHOW CREATE TABLE:还原建表意图与索引定义逻辑
当你怀疑索引命名混乱、或想确认索引是否带前缀、是否是全文索引时,这个命令最可靠:
-
执行命令:
SHOW CREATE TABLE users; -
重点关注输出末尾的 KEY 部分:
-
KEY `idx_email` (`email`(50))→ 前缀索引,只索引 email 前 50 字符 -
FULLTEXT KEY `ft_content` (`content`)→ 明确是全文索引 -
UNIQUE KEY `uk_phone` (`phone`)→ 唯一约束索引
-
- 好处:看到原始 DDL,避免因 SHOW INDEX 字段抽象而误判(比如分不清是普通索引还是唯一约束)
EXPLAIN + 索引统计:验证索引是否真正生效
光有索引不等于被用——这步才是性能分析的核心:
-
用 EXPLAIN 看执行计划:
EXPLAIN SELECT * FROM users WHERE email = 'a@b.com'; -
关键字段解读:
-
key:实际命中的索引名,为
NULL表示未走索引 -
key_len:实际使用的索引字节数,结合字段类型可反推是否用了全部列(例如
email VARCHAR(255),若 key_len = 768,说明用了前缀索引) - possible_keys:优化器认为可用的索引列表,但不一定真用
-
key:实际命中的索引名,为
-
配合 ANALYZE TABLE 更新统计:如果 Cardinality 长期不准,或查询突然变慢,执行
ANALYZE TABLE users;让优化器重新采样










