了解MySQL表的索引信息，最直接的命令是
SHOW INDEX FROM table_name;或
SHOW KEYS FROM table_name;。这个命令会列出指定表的所有索引，并提供详细的元数据，帮助我们理解每个索引的特性，比如它是唯一索引还是非唯一索引，涵盖了哪些列，以及最重要的——它使用了哪种索引类型（如B-tree、Hash等）。通过解析这些信息，我们就能深入洞察数据库如何优化数据检索，以及潜在的性能瓶颈。
解决方案
要查看MySQL表的所有索引及其详细信息，你只需要在MySQL客户端中执行以下命令：
SHOW INDEX FROM your_table_name;
将
your_table_name替换为你想要查询的实际表名。
执行后，你会得到一个结果集，通常包含以下关键列（这只是部分，实际输出可能更多）：
Table: 索引所属的表名。 Non_unique: 如果索引允许重复值，则为1；如果索引是唯一索引（如PRIMARY KEY或UNIQUE），则为0。这是判断索引性质的关键。 Key_name: 索引的名称。PRIMARY KEY通常显示为PRIMARY。 Seq_in_index: 列在复合索引中的顺序。从1开始。 Column_name: 索引所包含的列名。 Collation: 列在索引中的排序方式。A表示升序，D表示降序，NULL表示未排序。 Cardinality: 索引中唯一值的估计数量。这个值越高，索引的选择性越好，查询效率可能越高。 Sub_part: 如果是前缀索引，则显示索引前缀的长度。 Packed: 指示关键字如何被打包。 Null: 如果列可以包含NULL值，则为
YES；否则为
NO。 Index_type: 索引使用的存储结构类型，如
BTREE、
HASH、
FULLTEXT、
SPATIAL。这是我们解析索引类型的核心。 Comment: 索引的注释。 Index_comment: 特定于索引的注释。
一个典型的输出示例可能看起来像这样：
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | products | 0 | PRIMARY | 1 | id | A | 10000 | NULL | NULL | | BTREE | | | | products | 1 | idx_name | 1 | name | A | 5000 | NULL | NULL | YES | BTREE | | | | products | 1 | idx_desc | 1 | description | A | 2000 | NULL | NULL | YES | FULLTEXT | | | +------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
MySQL索引类型：B-tree、Hash、全文索引与空间索引，它们各有什么用？
Index_type列告诉我们MySQL内部是如何组织和管理这个索引的。不同的索引类型适用于不同的查询场景，理解它们对于优化数据库性能至关重要。
B-tree (BTREE): 这是MySQL最常用、也是默认的索引类型。B-tree索引适用于各种查询，包括精确查找、范围查找（如
BETWEEN,
>,
<）、排序（
ORDER BY）以及前缀匹配（
LIKE 'prefix%'）。它的结构像一棵平衡树，能保证查询效率在对数时间内完成。无论是InnoDB还是MyISAM存储引擎，B-tree都是其核心索引结构。在我看来，如果你不确定该用什么索引，B-tree通常是稳妥的选择，它覆盖了绝大多数常见的查询需求。
Hash (HASH): Hash索引基于哈希表实现，对于等值查询（
=或
IN）非常快，因为它直接计算哈希值定位数据，省去了B-tree的层级遍历。但它的缺点也很明显：不支持范围查询、不支持排序，也不支持部分匹配。此外，哈希冲突可能会影响性能。在MySQL中，只有
MEMORY存储引擎支持显式的Hash索引。InnoDB虽然有“自适应哈希索引”，但那是内部优化，用户定义的索引通常还是B-tree。所以，当你看到
Index_type是
HASH时，通常意味着你正在使用
MEMORY表，或者它是一个内部的、你无法直接控制的优化。
Fulltext (FULLTEXT): 全文索引专门用于文本内容的模糊查询，比如在文章标题或内容中搜索关键词。它允许你使用
MATCH AGAINST语法进行自然语言搜索或布尔模式搜索。与
LIKE '%keyword%'相比，全文索引在处理大量文本数据时效率更高，并且能提供更智能的搜索结果（例如，考虑词频、相关性等）。不过，它也有一些限制，比如默认有最小词长要求，并且通常不支持中文分词（需要插件或特定配置）。
Spatial (SPATIAL): 空间索引用于地理空间数据类型（如
POINT,
LINESTRING,
POLYGON）。如果你在处理地图、位置服务等应用，需要查询某个区域内的点、线或多边形数据，那么空间索引就是你的选择。它通过R-tree等数据结构来优化空间查询函数（如
ST_Contains,
ST_Intersects）。在MySQL 5.7及更高版本中，InnoDB也支持空间索引，但通常需要特定的GIS数据类型和函数来配合使用。
如何通过SHOW INDEX输出判断索引的有效性和优化潜力？
SHOW INDEX的输出不仅仅是列出索引，它更是我们评估索引质量和优化潜力的宝贵工具。
Non_unique
与Key_name
的组合洞察:
Non_unique为0且
Key_name为
PRIMARY，那肯定是主键索引，它强制唯一性，并且通常是聚簇索引（InnoDB），对查询性能至关重要。如果
Non_unique为0但
Key_name不是
PRIMARY，则这是一个普通唯一索引，它也强制唯一性，但通常不是聚簇索引。了解这些有助于我们判断数据完整性约束是否得到了恰当的利用。
Cardinality
的重要性:
Cardinality是索引中唯一值的估计数量。我通常会特别留意这个值。一个理想的索引，其
Cardinality应该接近于表中的总行数（尤其是唯一索引）。如果
Cardinality很低，比如一个有100万行的表，某个索引的
Cardinality只有10，这意味着该列的值重复度非常高，这个索引对于过滤数据可能帮助不大，甚至可能因为额外的索引查找开销而降低查询效率。优化器在决定是否使用索引时，会严重依赖
Cardinality来估算索引的过滤效果。
Seq_in_index
与复合索引的“最左前缀”原则: 对于复合索引（包含多个列的索引），
Seq_in_index显示了列在索引中的顺序。这非常重要，因为MySQL的复合索引遵循“最左前缀”原则。这意味着如果你有一个
INDEX(col_A, col_B, col_C)的索引，它可以用于
WHERE col_A = ?，
WHERE col_A = ? AND col_B = ?，甚至
WHERE col_A = ? AND col_C = ?（但
col_C部分不会利用索引），但不能单独用于
WHERE col_B = ?或
WHERE col_C = ?。检查
Seq_in_index能帮助你确认索引是否能被你的查询有效利用。
Index_type
与查询模式的匹配: 确保你的索引类型与你的查询模式相匹配。如果你经常进行范围查询和排序，
BTREE是首选。如果你主要进行精确查找，并且对内存表有需求，
HASH可能更快。对于文本搜索，
FULLTEXT是专门的解决方案。不匹配的索引类型可能会导致索引根本不被使用，或者查询效率低下。
Null
列的考量: 如果一个索引列允许NULL值，并且你的查询条件中包含了
IS NULL或
IS NOT NULL，那么索引可能不会被完全利用，或者行为不如预期。这提醒我们在设计表结构和查询时需要注意。
在实际开发中，查看索引信息时常遇到的“坑”与误解有哪些？
在日常开发和数据库维护中，
SHOW INDEX虽然强大，但也存在一些常见的“坑”和误解，稍不注意就可能导致错误的判断。
Cardinality
并非总是精确的:
Cardinality是一个估计值，由数据库采样计算而来。对于数据量较小或者数据分布极不均匀的表，这个估计值可能与实际的唯一值数量相去甚远。我见过一些情况，
Cardinality显示很低，但实际查询却能利用索引获得不错的效果，反之亦然。所以，不要完全依赖
Cardinality来做决策，它更多是一个初步的参考，最终还是要结合
EXPLAIN来验证索引的实际使用情况。
Index_type
的表象与内在优化:
SHOW INDEX显示的
Index_type是用户定义或系统创建的索引类型。然而，对于InnoDB存储引擎，它有一个非常重要的内部优化叫做“自适应哈希索引”（Adaptive Hash Index, AHI）。当InnoDB检测到某个B-tree索引的热点数据经常被访问时，它会在内存中自动为这些数据创建哈希索引，以加速查找。这个AHI是InnoDB内部管理的，不会在
SHOW INDEX的输出中显式列出为
HASH类型。这意味着即使你看到
BTREE，底层也可能在享受哈希索引的加速。所以，不要因为看不到
HASH类型就认为没有哈希加速。
索引不是越多越好，也不是越长越好: 很多人觉得索引能提升查询速度，就给所有可能用到的列都加上索引，或者创建很长的复合索引。这其实是个常见的误区。过多的索引会增加写操作（
INSERT,
UPDATE,
DELETE）的开销，因为每次数据变动都需要同步更新所有相关的索引。同时，过多的索引也会占用更多的磁盘空间和内存。对于复合索引，如果包含的列过多或长度过长，不仅会增加索引本身的存储开销，也可能导致索引效率下降，因为B-tree节点需要存储更多信息。通常，选择性高（
Cardinality高）的列放在复合索引的前面，并且只包含查询中最常用的列。
索引失效的常见场景:
SHOW INDEX只是告诉你有哪些索引，但它不会告诉你这些索引在你的特定查询中是否真的被使用了。很多时候，即使有索引，由于查询写法不当，索引也可能失效。比如：在索引列上使用了函数（
WHERE LENGTH(name) = 5），数据类型不匹配隐式转换，使用了
OR连接的非索引列，或者
LIKE '%keyword'（以通配符开头）等。要判断索引是否被利用，你必须使用
EXPLAIN命令来分析查询计划。
SHOW INDEX和
EXPLAIN是互补的工具，缺一不可。
