要查看mysql表的索引列表及其类型信息，最直接的方法是使用show index from table_name命令，该命令会列出表中所有索引的详细信息，包括索引名称、列名、索引类型等，其中index_type列明确显示索引的底层实现算法如btree或hash，同时可通过information_schema.statistics表进行更灵活的查询分析，从而全面掌握索引结构并用于性能优化与问题排查，完整掌握索引信息有助于合理设计数据库、提升查询效率并避免冗余索引带来的维护开销，最终确保数据库的高效稳定运行。
在MySQL里想看一张表的索引列表，最直接的办法就是用
SHOW INDEX FROM table_name;这条命令。它会把这张表上所有索引的详细信息都列出来，包括索引的名字、涉及的列、索引类型等等。至于索引的分类，我们通常从逻辑和物理（算法）两个维度来看，比如主键索引、唯一索引、普通索引，以及它们底层用的B-Tree、Hash等算法。
解决方案
要查看MySQL表的索引列表，以及了解其背后的类型信息，核心命令是
SHOW INDEX。
SHOW INDEX FROM your_table_name; -- 或者 SHOW KEYS FROM your_table_name;
执行这条命令后，你会得到一个结果集，里面包含了关于表上每个索引的详细元数据。这里面有几个关键的列值得我们关注：
-
Table
: 索引所属的表名。 -
Non_unique
: 如果是0，表示这是一个唯一索引（包括主键索引）；如果是1，表示是非唯一索引。 -
Key_name
: 索引的名称。这是我们通常用来识别索引的标识。 -
Seq_in_index
: 索引中的列序号，表示该列在复合索引中的位置。 -
Column_name
: 索引包含的列名。 -
Collation
: 列在索引中的排序方式（A表示升序，D表示降序，NULL表示未排序）。 -
Cardinality
: 索引中不重复值的估计数量。这个值越高，索引的选择性越好，查询效率可能越高。 -
Sub_part
: 如果是部分索引（前缀索引），这里显示索引前缀的长度。 -
Packed
: 指示关键字如何被压缩。 -
Null
: 如果列可以包含NULL值，这里是YES。 -
Index_type
: 这就是我们关心的索引底层实现算法，常见的有BTREE
、HASH
、FULLTEXT
、SPATIAL
。 -
Comment
: 索引的注释。 -
Index_comment
: 索引的额外注释。 -
Visible
: 索引是否可见（MySQL 8.0+）。 -
Expression
: 如果是表达式索引，这里会显示表达式。
通过
Index_type这一列，我们就能清晰地看到每个索引是基于哪种算法实现的。
MySQL中常见的索引类型分类有哪些？
当我们谈论MySQL的索引类型，其实是在说两层含义：逻辑上的分类和物理（算法）上的实现。
从逻辑功能上讲，常见的索引类型包括：
- 主键索引（PRIMARY KEY）: 一张表最多只能有一个主键索引，它强制唯一性，并且不允许NULL值。通常，主键索引会自动创建在声明为主键的列上。它的作用是唯一标识表中的每一行数据，并且通常是聚簇索引（InnoDB引擎下），这意味着数据行会按照主键的顺序物理存储。
- 唯一索引（UNIQUE KEY）: 保证索引列的值是唯一的，但允许有NULL值（可以有多个NULL，因为NULL不等于NULL）。它用于确保数据的完整性，比如用户ID、邮箱等需要唯一性的字段。
- 普通索引（INDEX/KEY）: 最基本的索引类型，没有任何限制，允许重复值和NULL值。主要目的是提高查询效率。
- 全文索引（FULLTEXT INDEX）: 用于在文本列（如VARCHAR、TEXT）上进行全文搜索，比如文章内容的关键词搜索。它支持自然语言搜索和布尔模式搜索。
- 空间索引（SPATIAL INDEX）: 用于存储地理空间数据类型（如GEOMETRY）的索引，适用于地理位置查询。
从物理实现（算法）上讲，
Index_type列会告诉我们：
- BTREE: 这是MySQL中最常用、也是默认的索引类型。B-Tree索引适用于全值匹配、范围查询、前缀匹配、排序等多种查询场景。InnoDB和MyISAM存储引擎都大量使用B-Tree索引。它的特点是能保持数据有序，因此对于范围查询非常高效。
- HASH: 这种索引类型基于哈希表实现，只适用于精确匹配（等值查询），不支持范围查询或排序。它的查询速度理论上非常快，因为它直接通过哈希值定位数据。但由于哈希冲突和无序性，它的适用场景相对有限。在InnoDB中，哈希索引通常是自适应哈希索引（Adaptive Hash Index），由数据库系统根据访问模式自动创建和管理，我们无法手动创建。
- FULLTEXT: 全文索引的底层实现，专门为文本搜索优化。
- SPATIAL: 空间索引的底层实现，为空间数据类型优化。
理解这些分类，特别是
Index_type，能帮助我们更好地判断索引是否适合当前的查询模式。比如，如果你需要进行大量的范围查询，一个BTREE索引无疑是最佳选择；而如果只是精确查找，且数据量非常大，理论上HASH索引会更快，但需要考虑其局限性。
为什么我们需要关注索引的这些信息？
查看并理解表的索引信息，绝不仅仅是为了满足好奇心，它直接关系到数据库的性能优化和问题排查。
首先，性能调优。一个设计良好的索引是查询性能的基石。通过
SHOW INDEX，我们可以看到
Cardinality（基数）。这个值越高，说明索引列的不重复值越多，索引的选择性越好。如果一个索引的
Cardinality很低（比如在一个只有“男/女”两个值的列上），那么这个索引对查询性能的提升可能非常有限，甚至可能因为额外的维护成本而拖慢写入。我们还可以检查
Index_type。如果你的查询模式是范围查询，但索引却是哈希类型（虽然手动创建哈希索引的情况不多，但了解其特性很重要），那效率肯定不高。反过来，如果一个等值查询的性能不佳，而对应的列上只有一个B-Tree索引，我们可能会考虑是否可以优化查询语句，或者在特定场景下，如果InnoDB能自适应地创建哈希索引，那查询性能自然会提升。
其次，排查慢查询。当遇到一个慢查询时，我们往往会用
EXPLAIN来分析查询计划。
EXPLAIN会告诉我们查询是否使用了索引，使用了哪个索引。而
SHOW INDEX就能提供这个索引的详细背景信息。比如，
EXPLAIN显示使用了某个索引，但查询依然很慢，这时我们就可以回过头来用
SHOW INDEX看看这个索引是不是复合索引，
Seq_in_index告诉我们查询条件是否命中了索引的最左前缀原则。又或者，发现
Column_name对应的列上根本没有索引，那自然是慢查询的直接原因。
再者，数据库设计和维护。在设计表结构时，我们就要考虑哪些列需要加索引，加什么类型的索引。
SHOW INDEX帮助我们验证设计是否正确。比如，我们期望某个列是唯一的，但
Non_unique却是1，那可能就是创建索引时忘记加
UNIQUE关键字了。另外，索引是需要占用存储空间的，并且在数据插入、更新、删除时会带来额外的维护开销。通过
SHOW INDEX我们可以定期审视现有索引是否冗余、是否还有优化的空间，避免不必要的索引占用资源。我个人就遇到过因为过度索引导致写入性能急剧下降的情况，这时候
SHOW INDEX配合
EXPLAIN就能很快定位问题。
除了SHOW INDEX
，还有其他方式查看索引吗？
当然有，
SHOW INDEX虽然直观，但在某些场景下，直接查询
information_schema数据库中的元数据表会更加灵活和强大。
最常用的就是查询
information_schema.STATISTICS表：
SELECT
TABLE_SCHEMA,
TABLE_NAME,
INDEX_NAME,
NON_UNIQUE,
SEQ_IN_INDEX,
COLUMN_NAME,
COLLATION,
CARDINALITY,
SUB_PART,
PACKED,
NULLABLE,
INDEX_TYPE,
COMMENT
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';这条SQL查询返回的结果和
SHOW INDEX基本一致，但它提供了更大的灵活性。你可以方便地过滤特定数据库、特定模式的索引，或者进行更复杂的聚合查询，比如统计某个数据库中所有表的索引数量、查找所有哈希索引等等。这对于DBA进行全局的数据库健康检查和索引策略分析非常有用。
另外，如果你想查看哪些列被用作外键（FOREIGN KEY），可以查询
information_schema.KEY_COLUMN_USAGE表：
SELECT
CONSTRAINT_SCHEMA,
CONSTRAINT_NAME,
TABLE_SCHEMA,
TABLE_NAME,
COLUMN_NAME,
REFERENCED_TABLE_SCHEMA,
REFERENCED_TABLE_NAME,
REFERENCED_COLUMN_NAME
FROM
information_schema.KEY_COLUMN_USAGE
WHERE
TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name'
AND REFERENCED_TABLE_NAME IS NOT NULL; -- 过滤出外键关系虽然
DESCRIBE table_name;命令也能显示表的列信息，并在
Key列中标记出
PRI（主键）、
UNI（唯一键）、
MUL（多值键，即非唯一索引），但这只能提供一个非常简略的索引存在信息，无法看到索引的名称、类型等详细内容。所以，它通常不作为查看索引列表的主要方式。
在日常工作中，我个人更倾向于先用
SHOW INDEX快速查看某个表的索引概况，如果需要进行更细致的分析或者跨库、跨表的索引审计，那
information_schema.STATISTICS就是我的首选工具。结合这些方法，我们就能全面掌握MySQL中表的索引情况。
