在数据库运维和慢查询优化中，经常需要确认某张表到底建了哪些索引，以及这些索引分别是什么类型。MySQL自身提供了多条命令来暴露表的索引元数据，其中最常用的是SHOW INDEX语句。掌握它的输出结构，是排查索引失效、设计联合索引的前提。
一、显示表所有索引的基础命令
最简单的方式是在MySQL客户端中执行SHOW INDEX FROM命令。它的语法形式为SHOW INDEX FROM 表名 [FROM 库名]，可以列出指定表上定义的全部索引，包括主键、唯一索引、普通索引以及全文索引。
例如，我们有一张用户表user，结构如下：
CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL, `email` VARCHAR(100) NOT NULL, `age` INT DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_email` (`email`), KEY `idx_name_age` (`name`,`age`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
要查看这张表的所有索引，执行：
SHOW INDEX FROM `user`;
该命令会返回一个结果集，每一行代表一个索引中的一个列（对于联合索引，会按列顺序出现多行）。结果集中包含表名、索引名、列名、排序方式等十几个字段，是分析索引结构的直接依据。
二、SHOW INDEX输出字段逐列解析
理解返回结果里的每个字段，才能准确判断索引类型与特征。下面用一张表归纳核心字段及其含义：
| 字段名 | 说明 |
|---|---|
| Key_name | 索引名称。PRIMARY表示主键，其他为自定义名称 |
| Non_unique | 0表示唯一索引（含主键），1表示允许重复的普通索引 |
| Seq_in_index | 列在索引中的位置，从1开始，联合索引据此判断前后顺序 |
| Column_name | 索引包含的列名 |
| Index_type | 索引底层实现类型，如BTREE、FULLTEXT、HASH |
| Cardinality | 基数估值，反映列中不同值的个数，影响优化器选索引 |
以刚才的user表为例，SHOW INDEX会输出九行左右数据：主键id一行，唯一索引uk_email一行，联合索引idx_name_age两行（name和age各一行）。通过Non_unique字段能立刻区分出主键和唯一索引都是0，而联合索引是1。
Cardinality是一个重要但常被忽略的字段。它是采样估算值，不代表精确去重计数。如果该值远低于实际行数，说明索引区分度差，优化器可能放弃使用。在InnoDB中，Cardinality会在表数据变动较大时重新统计，也可通过ANALYZE TABLE命令主动更新。
三、索引类型Index_type深度解析
SHOW INDEX结果中的Index_type列直接揭示了索引的物理实现。不同存储引擎支持的索引类型不同，这也是为什么同样的建表语句在不同引擎下看到的类型可能有差异。
对于InnoDB和MyISAM，绝大多数索引的Index_type都显示为BTREE。这里的BTREE实际上是B+树，MySQL统一以BTREE命名。B+树索引适合范围查询和排序，是MySQL默认且最常用的索引结构。Memory引擎则默认使用HASH索引，也支持BTREE，但HASH只支持等值比较，不支持范围。
-- Memory引擎表会使用HASH索引 CREATE TABLE `cache` ( `k` INT NOT NULL, `v` VARCHAR(20), KEY `idx_k` (`k`) ) ENGINE=MEMORY; SHOW INDEX FROM `cache`; -- 此时Index_type列可能显示HASH
另一种特殊类型是FULLTEXT，即全文索引，只能用在MyISAM或InnoDB（5.6+）上，Index_type固定为FULLTEXT。它底层并非B+树，而是倒排索引，专门用于MATCH AGAINST文本检索。如果看到某列Index_type是FULLTEXT，就不能用普通WHERE col=val的方式利用它。
四、通过信息_schema获取索引元数据
除了SHOW INDEX，还可以查询系统库information_schema中的STATISTICS表，它能以标准SQL方式筛选索引，便于写脚本批量检查。
SELECT INDEX_NAME, NON_UNIQUE, COLUMN_NAME, SEQ_IN_INDEX, INDEX_TYPE FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'test_db' AND TABLE_NAME = 'user' ORDER BY INDEX_NAME, SEQ_IN_INDEX;
这种方式和SHOW INDEX本质读取的是同一份元数据，但可以使用WHERE条件过滤，比如只查非唯一索引，或者找出所有联合索引。对于需要巡检几十张表索引规范的场景，写一条SQL比手动执行SHOW方便得多。
需要注意的是，information_schema里的数据在MySQL 8.0之后改为从数据字典实时读取，历史版本中可能是临时表，查询时会有一定开销，不要在业务高峰期频繁大范围扫描。
五、常见误区与排查建议
不少人在看SHOW INDEX结果时，会把Key_name相同、Seq_in_index不同的多行误认为多个索引。实际上它们属于同一个联合索引的不同列，必须按Seq_in_index顺序组合使用才有效。例如idx_name_age中，单独用age做查询条件通常无法命中该索引。
另一个误区是认为Index_type显示BTREE就一定是平衡二叉树。如前所述，MySQL的BTREE是B+树变体，叶子节点链表相连，非叶子节点只存键不存数据，这和教科书里的B树不同。弄清这个概念，有助于理解为什么InnoDB的二级索引叶子节点存的是主键值而不是行指针。
当发现查询没走预期索引时，先执行SHOW INDEX确认索引真实存在且列顺序匹配，再结合EXPLAIN观察访问类型。若Cardinality异常低，考虑是否是字段选择性太差，或者统计信息过期，必要时重建索引或分析表来修正优化器的判断依据。
MySQLshow_indexindex_type修改时间：2026-08-04 00:24:34