要查看mysql表的索引信息，最直接的方法是使用show index from table_name命令，它能列出表中所有索引的详细属性，如索引名、类型、涉及的列及cardinality等关键统计信息，帮助快速评估索引结构和查询优化空间，该方法直观高效，适用于日常开发与维护场景，使用完毕后无需额外清理操作即可直接获取结果。
要查看MySQL表的索引信息，最直接且常用的方法是使用
SHOW INDEX FROM table_name;命令。这个命令会列出指定表的所有索引及其详细属性，让你能迅速了解索引的名称、类型、涉及的列以及其他关键统计数据。
解决方案
在MySQL中，查看表的索引信息主要有两种方法，各有侧重：
1. 使用 SHOW INDEX FROM
命令
这是最直观和常用的方式。你只需要替换
your_table_name为你实际的表名即可：
SHOW INDEX FROM your_table_name;
执行后，你会得到一个结果集，其中包含以下重要的列：
- Table: 索引所属的表名。
- Non_unique: 如果索引是非唯一索引，则为1；如果是唯一索引（包括主键），则为0。
-
Key_name: 索引的名称。对于主键，通常是
PRIMARY
。 - Seq_in_index: 索引中列的序号，从1开始。对于复合索引，这显示了列在索引中的顺序。
- Column_name: 索引中包含的列名。
- Collation: 列在索引中的排序方式，A表示升序，D表示降序，NULL表示未排序。
- Cardinality: 索引中唯一值的估计数量。这个值越高，索引的选择性越好，查询效率可能越高。
- Sub_part: 如果是前缀索引（只索引列的一部分），这里会显示前缀的长度。
- Packed: 指示关键字如何被压缩。如果未压缩，则为NULL。
- Null: 如果列可以包含NULL值，则为YES。
-
Index_type: 索引的类型，如
BTREE
、HASH
、FULLTEXT
、SPATIAL
。 - Comment: 索引的注释。
- Index_comment: 索引的特定注释。
示例：
SHOW INDEX FROM users;
2. 查询 information_schema.STATISTICS
表
如果你需要更灵活地查询或过滤索引信息，或者想通过编程方式获取，可以直接查询
information_schema数据库下的
STATISTICS表。这个表包含了所有数据库中所有表的索引元数据。
SELECT
TABLE_SCHEMA,
TABLE_NAME,
INDEX_NAME,
NON_UNIQUE,
SEQ_IN_INDEX,
COLUMN_NAME,
COLLATION,
CARDINALITY,
SUB_PART,
PACKED,
`NULLABLE`, -- 注意这里是反引号，因为NULL是SQL保留字
INDEX_TYPE,
COMMENT
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';这种方式的优点在于，你可以使用
WHERE子句进行复杂的过滤，比如只看某个数据库下的所有索引，或者查找特定类型的索引。我个人觉得，当你需要对大量表进行索引审计，或者想用脚本自动化处理时，查询
information_schema会更加方便。
如何区分MySQL中的不同索引类型？
在
SHOW INDEX FROM或
information_schema.STATISTICS的结果中，
Index_type这一列就是用来标识索引类型的。我们最常遇到的就是
BTREE和
HASH。
BTREE (B-Tree索引): 这是MySQL（以及大多数关系型数据库）最常用、默认的索引类型。它适用于各种查询，包括等值查询、范围查询、排序和模糊匹配（左模糊除外）。B-Tree索引的结构使得数据是有序的，查找效率高，尤其在数据量大时表现出色。InnoDB存储引擎主要支持BTREE索引。我个人在设计表结构时，几乎所有的索引都默认是BTREE，因为它适用性最广。
HASH (哈希索引): 哈希索引基于哈希表实现，只支持等值查询（
=
或IN
操作），不支持范围查询、排序。它的查找速度理论上非常快，接近O(1)复杂度。但缺点也很明显，比如不支持模糊匹配，也不支持排序。在MySQL中，只有Memory存储引擎明确支持HASH索引。InnoDB虽然没有显式的HASH索引类型，但它内部有自适应哈希索引（Adaptive Hash Index），是根据B-Tree索引的访问模式自动创建和管理的，我们无法直接控制或查看。FULLTEXT (全文索引): 专门用于文本字段的全文搜索，例如文章内容。它支持自然语言搜索和布尔搜索模式，可以快速定位包含特定关键词的文档。如果你需要在
VARCHAR
或TEXT
列上进行复杂的文本搜索，这是一个非常有效的选择。SPATIAL (空间索引): 用于地理空间数据类型（如
GEOMETRY
）的索引，例如在地图应用中查询某个区域内的点。它依赖于R-Tree结构。
理解这些类型非常关键。比如，如果你发现一个查询在
VARCHAR列上使用了
LIKE '%keyword%'（左模糊），即使有
BTREE索引，这个索引也可能无法被有效利用，因为
BTREE索引的有序性在这里被破坏了。这时候，你可能需要考虑全文索引或其他文本搜索方案。
如何通过索引信息判断索引的有效性或优化空间？
查看索引信息不仅仅是知道它存在，更重要的是要学会解读这些信息，判断索引是否真的有效，或者是否存在优化空间。这里有几个我经常关注的关键点：
-
Cardinality
(基数): 这是我个人觉得最重要的指标之一。它表示索引中唯一值的估计数量。- 高基数: 意味着索引列的值重复度低，选择性好。比如用户ID、邮箱地址，它们的基数就很高。高基数的索引能大幅减少需要扫描的数据行，从而提高查询效率。
- 低基数: 意味着索引列的值重复度高，选择性差。比如性别（男/女）、状态（启用/禁用）。对这类列建立索引，效果往往不佳，因为即使使用了索引，也可能需要扫描大量行。
-
重要提示:
Cardinality
是一个估计值，MySQL在更新统计信息时会计算它。如果你的表数据变化很大，这个值可能不准确。你可以通过运行ANALYZE TABLE your_table_name;
来强制MySQL重新计算表的统计信息，这通常会使Cardinality
更接近真实情况。
-
Non_unique
(是否唯一):0
表示唯一索引（包括主键），1
表示非唯一索引。唯一索引除了加速查询，还能确保数据完整性，防止重复值插入。- 如果一个列的值天然唯一，建立唯一索引是个好习惯，它能给数据库一个明确的约束。
-
Seq_in_index
(列在索引中的顺序):- 对于复合索引（包含多个列的索引），这个字段至关重要。它显示了列在索引定义中的顺序。
- 最左前缀原则: 这是复合索引优化的核心。只有查询条件从索引的第一个列开始，并按顺序匹配时，索引才能被有效利用。
-
举例: 如果你有一个复合索引
(col1, col2, col3)
，查询WHERE col1 = ? AND col3 = ?
可能无法完全利用到col3
部分的索引，因为它跳过了col2
。而WHERE col1 = ? AND col2 = ?
则能很好地利用索引。我见过太多因为不理解这个原则，导致复合索引形同虚设的案例。
-
Sub_part
(前缀索引长度):- 当你在
TEXT
或VARCHAR
列上创建索引时，如果只索引了列值的前N个字符，这里就会显示N。 - 前缀索引可以减小索引大小，提高索引效率，但可能会牺牲一部分选择性。你需要权衡索引大小和查询性能。
- 当你在
很多时候，我们盯着
Cardinality看半天，就是为了判断这个索引到底有没有发挥作用，或者是不是需要调整。如果一个索引的
Cardinality很低，或者与
Table的行数相差甚远，那么这个索引可能效率不高。
查看索引信息时常见的误区有哪些？或者如何查看更底层的索引统计信息？
光看
SHOW INDEX是远远不够的，真正的挑战在于，你得知道这些信息背后的含义，以及它们如何影响查询性能。这里有一些常见的误区和更深层次的探究方法：
误区一：认为
SHOW INDEX
显示了索引的所有秘密SHOW INDEX
确实提供了索引的基本信息，但它并不能告诉你MySQL优化器在实际查询中是否选择了这个索引，以及是如何使用的。一个索引可能存在，但优化器可能因为各种原因（比如数据量太小，或者查询条件不匹配最左前缀）而选择不使用它。误区二：
Cardinality
总是准确的 正如前面提到的，Cardinality
是一个估计值，它不是实时更新的。如果数据频繁插入、删除或更新，这个值可能会变得不准确，从而误导你对索引选择性的判断。定期运行ANALYZE TABLE your_table_name;
来更新统计信息是非常有必要的。误区三：索引越多越好 这绝对是个大误区。索引虽然能加速查询，但它们会占用磁盘空间，并且在数据插入、更新、删除时会增加额外的维护开销。过多的索引反而可能拖慢写入操作，甚至导致优化器在选择索引时“迷茫”，反而选了次优的执行计划。
如何查看更底层的索引统计信息或实际使用情况：
-
EXPLAIN
语句: 这是分析查询性能和索引使用情况的利器。在你想要优化的SELECT
语句前加上EXPLAIN
，MySQL会告诉你它将如何执行这个查询，包括使用了哪个索引（key
列）、索引的长度（key_len
）、扫描的行数（rows
）以及是否使用了文件排序或临时表等。EXPLAIN
的结果比SHOW INDEX
更具指导意义，因为它揭示了索引的“实战表现”。EXPLAIN SELECT * FROM users WHERE username = 'john_doe';
SHOW STATUS LIKE 'Handler_%';
: 这组状态变量可以显示MySQL服务器处理数据操作的底层统计信息，包括索引的使用情况。例如，Handler_read_key
表示通过键查找的次数，Handler_read_rnd_next
表示在数据文件中顺序读取下一行的次数。这些指标可以间接反映索引是否被有效利用，但需要结合其他上下文来解读。information_schema.INNODB_BUFFER_POOL_PAGES
或information_schema.INNODB_CACHED_INDEXES
(取决于MySQL版本和配置): 对于InnoDB存储引擎，这些表可以提供关于索引页在缓冲池中的缓存情况，这对于理解索引的内存命中率和热点索引非常有帮助。不过，这些通常是DBA级别才会深入探究的。
总的来说，查看索引信息只是第一步，更重要的是学会结合
EXPLAIN以及对业务查询模式的理解，来判断索引的真正价值和优化潜力。
