要查看mysql表的索引信息，最常用的方法是使用show index from 表名，它能详细列出索引名称、类型、列名、cardinality等关键字段，帮助评估索引选择性和性能；也可使用show create table 表名查看索引的创建语句，便于理解表结构设计；对于程序化查询或批量分析，可通过select * from information_schema.statistics where table_schema='数据库名' and table_name='表名'获取灵活的索引元数据。理解show index输出中的non_unique、key_name、seq_in_index、column_name、cardinality、index_type等字段含义，有助于识别索引类型、复合索引顺序及选择性高低；结合cardinality与表行数可判断索引效率，低选择性索引（如性别字段）可能不如全表扫描；冗余索引（如单独索引col_a与复合索引(col_a,col_b)并存）和索引过多会增加写操作开销，应通过分析删除无用或重复索引；进一步结合explain语句分析实际查询执行计划，观察key是否命中预期索引、type是否为all（全表扫描）、rows扫描行数是否过大、extra是否出现using filesort或using temporary等性能隐患，从而形成“查看索引→分析执行计划→优化索引设计”的闭环调优流程，持续提升查询性能。
想看看MySQL里一张表到底有哪些索引，或者某个索引的具体信息？这其实是数据库优化里很基础但又特别关键的一步。直接点说，你通常会用到
SHOW INDEX FROM 表名或者
SHOW CREATE TABLE 表名，再不然就是去
information_schema.STATISTICS查。这几种方法各有侧重，但都能帮你把索引的底细摸清楚。
解决方案
要获取MySQL表的索引信息，最直接、最常用的方法有几种，它们提供了不同粒度的信息，你可以根据自己的需要选择。
首先，
SHOW INDEX FROM your_table_name是我的首选。它会返回一个表格，详细列出了指定表的所有索引及其属性。这个命令的输出非常直观，包含了索引名称、是否唯一、在索引中的列顺序、列名、基数（Cardinality）、索引类型等等。比如，如果你想看
users表的索引，就输入
SHOW INDEX FROM users;。它给出的信息足够你日常分析和优化了。我个人觉得，这个命令的
Cardinality列特别有意思，它大致代表了索引列中不重复值的数量，对于评估索引选择性很有帮助。
其次，
SHOW CREATE TABLE your_table_name也是一个查看索引定义的好办法。这个命令会返回创建该表的完整SQL语句，其中就包含了所有的主键、唯一索引、普通索引等定义。虽然它不像
SHOW INDEX那样把索引信息拆分成单独的列，但它能让你看到索引是如何与表结构一同被定义的，对于理解表的整体设计非常有用。有时候，我发现
SHOW CREATE TABLE能更快地帮我定位到复合索引的完整结构，因为它们就写在
KEY或
INDEX关键字后面。
最后，如果你需要更灵活地查询索引信息，或者想在程序中批量获取，那么查询
information_schema.STATISTICS表是最佳选择。
information_schema是MySQL的系统数据库，存储了关于数据库服务器的所有元数据。
STATISTICS表就包含了所有表的索引信息。你可以通过SQL查询来筛选、排序，甚至与其他
information_schema表进行关联查询，以获取更复杂的报告。例如：
SELECT
TABLE_SCHEMA,
TABLE_NAME,
INDEX_NAME,
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';这种方式提供了最大的灵活性，但对于快速查看单个表的索引，我还是倾向于
SHOW INDEX。
如何理解MySQL索引信息中的各个字段含义？
当你执行
SHOW INDEX FROM 表名时，会看到一堆字段，每个都承载着特定的意义。理解这些字段是正确评估索引效能的关键。
Table：这个简单，就是索引所属的表名。
Non_unique：这个字段告诉我们索引是否允许重复值。如果为
0，表示这是一个唯一索引（或主键，主键本质上也是唯一索引），不允许重复值；如果为
1，则表示这是一个普通索引，允许有重复值。这个字段能帮你快速判断索引的类型。
Key_name：索引的名称。通常，主键索引的名称是
PRIMARY。其他索引的名称是你创建时指定的，或者MySQL自动生成的。这个名字在
EXPLAIN语句的输出中也会出现，用来指示实际使用了哪个索引。
Seq_in_index：在复合索引中，这个字段表示列在索引中的顺序，从
1开始。比如一个索引包含
(col_a, col_b)，那么
col_a的
Seq_in_index是
1，
col_b是
2。这个顺序非常重要，它直接影响到索引的“最左前缀匹配”原则。
Column_name：索引所覆盖的列名。
Collation：列在索引中的排序方式。
A表示升序，
D表示降序，
NULL表示未排序。
Cardinality：这是个非常重要的指标，表示索引列中不重复值的估计数量。这个值越高，索引的选择性就越好，意味着通过该索引能过滤掉更多的数据，查询效率就越高。反之，如果
Cardinality很低（比如在一个布尔列上建立索引），那么这个索引的效果可能就不太理想，因为能过滤的数据有限。MySQL会定期更新这个值，但它只是个估计值。
Sub_part：对于字符串列，如果只对列的一部分创建了索引，这个字段会显示索引前缀的长度。比如
VARCHAR(255)列只索引了前10个字符，这里就会显示
10。
Packed：表示关键字如何被压缩。
NULL表示没有被压缩。
NULL：如果索引列允许存储
NULL值，这个字段会显示
YES。需要注意的是，NULL值通常不参与B-Tree索引的查找（除了特定的处理方式，比如IS NULL）。
Index_type：索引的类型，常见的有
BTREE（B-Tree索引，MySQL默认且最常用）和
HASH（哈希索引，主要用于Memory存储引擎）。理解索引类型有助于你判断其适用场景和性能特点。
Comment：索引的注释，通常为空。
理解这些字段，你就能从原始的索引信息中读出更多有用的信号，比如哪些索引是唯一的，哪些是复合索引，以及它们的潜在效率如何。
如何根据索引信息发现潜在的性能问题？
查看索引信息不仅仅是为了“看”，更重要的是“分析”，从中找出可能导致性能瓶颈的线索。这就像医生看病历，数据都在那儿，但得会解读。
一个常见的问题是索引选择性不足。如果
Cardinality值相对于表的总行数来说非常低，比如一个有100万行的表，某个索引的
Cardinality只有几十，那么这个索引可能就没那么高效。这意味着索引列的值重复度很高，通过这个索引能过滤的数据有限，MySQL可能还是需要扫描大量行。举个例子，在一个“性别”字段上建立索引，其
Cardinality最多也就2或3，这种索引通常意义不大，因为查询优化器可能觉得全表扫描反而更快。
冗余索引也是个隐患。有时候，你会发现存在这样的情况：你有一个复合索引
(col_a, col_b)，同时还有一个单独的索引
(col_a)。在这种情况下，单独的
(col_a)索引就是冗余的，因为
(col_a, col_b)已经包含了
col_a的信息，并且可以满足所有只用到
col_a的查询（得益于最左前缀匹配）。冗余索引会增加写操作的开销，因为每次数据变更，所有相关的索引都需要更新。
再有就是索引过多。虽然索引能提升查询速度，但每多一个索引，就会增加数据的写入、更新和删除的成本。每次对表进行
INSERT、
UPDATE或
DELETE操作时，所有相关的索引都需要被维护。所以，如果一张表有几十个索引，这本身就可能是一个性能问题，特别是在写密集型的应用中。
通过
SHOW INDEX，你可以识别出这些问题。比如，看到
Non_unique为
1但
Cardinality极低的索引，你可能就要考虑它是否真的有必要。看到多个索引覆盖了相同的列前缀，你可能就要考虑合并或删除冗余索引。当然，这些判断还需要结合实际的业务查询模式和
EXPLAIN语句的分析来最终确定。
索引信息与执行计划（EXPLAIN）如何结合分析？
仅仅查看索引信息是“静态”的，它告诉你“有什么”。而
EXPLAIN语句则是“动态”的，它告诉你“怎么用”。将这两者结合起来，才能真正深入理解查询性能。
当你对一个SQL查询使用
EXPLAIN时，它会返回一个执行计划，其中有很多关键信息，比如
type、
KEY、
rows和
Extra。
KEY列：这是
EXPLAIN输出中与索引信息最直接关联的字段。它显示了MySQL在执行查询时实际决定使用的索引的
Key_name。你可以用这个
KEY值去对照
SHOW INDEX FROM 表名的输出，确认MySQL是不是使用了你期望的那个索引。如果
KEY显示为
NULL，那通常意味着没有使用索引，或者说MySQL认为全表扫描更划算。
type列：这个字段表示了MySQL查找行的方式，是评估查询效率的核心。理想的
type值包括
const、
eq_ref、
ref、
range。如果看到
type是
ALL，那通常意味着全表扫描，这往往是性能瓶颈的信号，这时候你就需要回过头去检查索引是否缺失、是否选择性不高，或者查询条件是否能利用上现有索引。
rows列：这个字段是MySQL估计的为了找到所需行而必须扫描的行数。这个值越小越好。如果
rows值很高，即使
KEY字段显示使用了索引，也可能说明索引的选择性不够好，或者查询条件没有充分利用索引。
Extra列：这个字段提供了额外的查询优化信息，比如：
Using index
：表示查询所需的所有列都包含在索引中（覆盖索引），MySQL无需回表查询数据行，效率极高。这是我们追求的理想状态。Using where
：表示MySQL需要对索引检索到的行进行额外的过滤。Using filesort
：表示MySQL需要对结果进行外部排序，通常意味着没有合适的索引来满足ORDER BY
子句，这会消耗额外的CPU和内存资源。Using temporary
：表示MySQL需要创建临时表来处理查询，这通常发生在GROUP BY
或DISTINCT
操作中，也可能是一个性能瓶颈。
所以，当你发现某个查询很慢时，第一步是
EXPLAIN它。如果
EXPLAIN结果显示
KEY为
NULL，或者
type是
ALL，或者
rows很高，或者
Extra中出现了
Using filesort、
Using temporary等字样，那么你就可以结合
SHOW INDEX FROM 表名的输出，去思考：是不是缺少了某个关键索引？现有索引的列顺序是否合理？是不是可以创建复合索引来覆盖查询？通过这种“诊断-分析-优化”的循环，才能真正提升数据库的查询性能。这是一个持续迭代的过程，没有一劳永逸的解决方案。
