查索引需综合结构、状态与使用情况：用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：索引列去重值估算，越大通常选择性越好；明显偏低（如远小于表总行数）可能提示索引失效或数据倾斜
• 注意点：返回空结果 = 该表确实没有索引（不含主键），可放心下结论

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：优化器认为可用的索引列表，但不一定真用
• 配合 ANALYZE TABLE 更新统计：如果 Cardinality 长期不准，或查询突然变慢，执行 ANALYZE TABLE users; 让优化器重新采样