索引的存储引擎即其所在表的存储引擎，可通过SHOW CREATE TABLE或查询information_schema.TABLES获取表引擎类型，进而确定索引所依赖的存储机制，如InnoDB支持聚簇索引与事务，MyISAM使用非聚簇索引且仅支持表级锁，二者在数据存储、并发控制和性能表现上差异显著。

MySQL中，索引的“存储引擎”概念，其实是直接与它所属的表绑定在一起的。你无法为单个索引指定一个独立的存储引擎，因为索引是表结构的一部分，由表的存储引擎统一管理。所以，要查看索引的“存储引擎类型”，本质上就是查看该索引所在的表的存储引擎类型。最直接的办法，就是通过

SHOW CREATE TABLE

命令或者查询

information_schema

系统数据库。

解决方案

要弄清楚MySQL中索引的存储引擎，我们通常是去查它所依附的表的存储引擎。这事儿听起来有点绕，但逻辑很简单：索引是表的一部分，表的引擎决定了它内部所有结构（包括索引）的运作方式。

方法一：使用

SHOW CREATE TABLE

命令

这是最直观、最常用的方法。你只需要知道表的名称。

SHOW CREATE TABLE your_table_name;

执行这条命令后，你会得到一个包含创建表语句的结果集。在这个语句的末尾，通常会有一行类似

ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

的内容。

ENGINE=

后面跟着的就是这个表的存储引擎。比如，如果显示

ENGINE=InnoDB

，那么这个表上的所有索引，都是由InnoDB引擎管理的。

例子：

SHOW CREATE TABLE users;

结果可能类似：

CREATE TABLE `users` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `username` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

这里清楚地表明了

ENGINE=InnoDB

，所以

id

上的主键索引和

email

上的唯一索引都是InnoDB引擎的产物。

方法二：查询

information_schema.TABLES

视图

如果你想批量查询某个数据库下所有表的存储引擎，或者在程序中进行自动化查询，

information_schema.TABLES

是个更好的选择。

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    ENGINE
FROM
    information_schema.TABLES
WHERE
    TABLE_SCHEMA = 'your_database_name';

将

your_database_name

替换为你的数据库名。

ENGINE

列会直接告诉你每个表的存储引擎。

例子：

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    ENGINE
FROM
    information_schema.TABLES
WHERE
    TABLE_SCHEMA = 'mydb';

结果可能包含：

TABLE_SCHEMA | TABLE_NAME | ENGINE
-------------|------------|-------
mydb         | users      | InnoDB
mydb         | products   | InnoDB
mydb         | logs       | MyISAM

这样，你就能清晰地看到

users

和

products

表的索引是InnoDB管理的，而

logs

表的索引是MyISAM管理的。

为什么说索引的存储引擎就是表的存储引擎？

这问题问得挺好，也挺核心的。在我看来，这其实是MySQL设计哲学的一个体现：它将数据的存储和管理高度集成在存储引擎这个层面。一个表，从它被创建的那一刻起，它的所有数据文件、索引文件以及数据操作（增删改查、事务、锁等）都是由其指定的存储引擎来负责的。

想象一下，如果一个表是InnoDB引擎，而它的某个索引却是MyISAM引擎，这会带来巨大的复杂性。比如，InnoDB支持事务和行级锁，MyISAM不支持事务，是表级锁。当一个事务修改了InnoDB表的数据，同时涉及到这个“MyISAM索引”时，数据库该如何协调两者之间的锁机制和事务回滚？这简直是噩梦。数据一致性、完整性、并发控制都会变得异常复杂，甚至无法保证。

所以，MySQL的设计者们很明智地决定：索引就是表的一部分，它的生命周期、特性、行为都必须与宿主表保持一致，由表的存储引擎全权负责。这意味着，当你说一个索引是“InnoDB索引”时，你实际上是指这个索引位于一个InnoDB表上，并因此继承了InnoDB的所有索引特性，比如它可能是聚簇索引的一部分，或者是一个辅助索引，并且支持事务和MVCC。反之，如果在一个MyISAM表上，那么它的索引就是“MyISAM索引”，它将是独立的非聚簇索引，并且操作是表级锁。这种绑定关系，简化了数据库的内部管理，也保证了数据操作的逻辑统一性和高效性。

如何通过

information_schema

更细致地查看索引信息？

虽然我们已经知道索引的“引擎”就是表的引擎，但了解索引本身的详细属性同样重要，比如它是B-tree还是Hash，是否唯一，哪些列组成了索引等。

information_schema

系统数据库里，

STATISTICS

和

KEY_COLUMN_USAGE

这两个视图能提供非常丰富的索引细节。

1.

information_schema.STATISTICS

视图

这个视图包含了每个表的所有索引的详细统计信息。

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'
ORDER BY
    INDEX_NAME, SEQ_IN_INDEX;

• TABLE_SCHEMA

  和

  TABLE_NAME

  : 索引所属的数据库和表。

• INDEX_NAME

  : 索引的名称。

• SEQ_IN_INDEX

  : 索引中列的顺序。

• COLUMN_NAME

  : 组成索引的列名。

• INDEX_TYPE

  : 索引的类型，常见的有

  BTREE

  (B-tree),

  HASH

  ,

  FULLTEXT

  ,

  SPATIAL

  。这个字段很重要，它描述了索引的数据结构。

• CARDINALITY

  : 索引中唯一值的估计数量。这个值越高，索引的选择性越好。

• COMMENT

  : 索引的注释（如果有的话）。

例子：

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    INDEX_NAME,
    SEQ_IN_INDEX,
    COLUMN_NAME,
    INDEX_TYPE
FROM
    information_schema.STATISTICS
WHERE
    TABLE_SCHEMA = 'mydb' AND TABLE_NAME = 'users'
ORDER BY
    INDEX_NAME, SEQ_IN_INDEX;

结果可能类似：

TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | SEQ_IN_INDEX | COLUMN_NAME | INDEX_TYPE
-------------|------------|------------|--------------|-------------|-----------
mydb         | users      | PRIMARY    | 1            | id          | BTREE
mydb         | users      | idx_email  | 1            | email       | BTREE

从这里你可以看到

PRIMARY

和

idx_email

这两个索引都是

BTREE

类型。无论是InnoDB还是MyISAM，它们的主键和普通索引大多都是B-tree结构。

2.

information_schema.KEY_COLUMN_USAGE

视图

这个视图主要关注索引中列的使用情况，以及外键关系。虽然它不直接提供索引类型，但对于理解索引的组成和作用很有帮助。

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    CONSTRAINT_NAME,
    COLUMN_NAME,
    ORDINAL_POSITION
FROM
    information_schema.KEY_COLUMN_USAGE
WHERE
    TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

这个视图可以帮助你确认哪些列被哪些约束（包括PRIMARY KEY, UNIQUE KEY, FOREIGN KEY）所索引。

结合

STATISTICS

视图，你可以对表的索引结构有一个非常全面的认识。

不同存储引擎对索引行为有何影响？

这才是真正有意思的地方，也是我们理解“索引存储引擎”这个概念的深层原因。虽然索引的引擎就是表的引擎，但不同的引擎对索引的实现和行为模式有着天壤之别，这些差异直接影响着数据库的性能、并发和数据完整性。

1. InnoDB 存储引擎及其索引行为

InnoDB是MySQL默认且推荐的存储引擎，它是一个事务安全的存储引擎，支持ACID特性。

• 聚簇索引 (Clustered Index)：这是InnoDB最核心的特性之一。每个InnoDB表都必须有一个聚簇索引。
  • 如果表定义了主键（PRIMARY KEY），那么主键就是聚簇索引。
  • 如果没有主键，InnoDB会尝试选择一个非空的唯一索引作为聚簇索引。
  • 如果连唯一索引都没有，InnoDB会自动生成一个隐藏的6字节ROWID作为聚簇索引。
  • 数据存储方式：聚簇索引的B-tree叶子节点直接存储了行的所有数据。这意味着数据行是按照主键的物理顺序存储的，查询主键非常快。
• 辅助索引 (Secondary Indexes)：
  • 辅助索引的叶子节点存储的不是数据行本身，而是主键值。
  • 这意味着，通过辅助索引查找数据时，MySQL首先会通过辅助索引找到对应的主键值，然后再用这个主键值去聚簇索引中查找完整的行数据。这个过程称为“回表”（lookup back to the clustered index）。
  • 覆盖索引：如果一个查询只需要辅助索引中的列（或者辅助索引本身就包含了所有需要的列），而不需要回表去查找聚簇索引，那么这个辅助索引就称为“覆盖索引”。覆盖索引可以显著提高查询性能，因为避免了二次查找。
• 事务和锁：InnoDB索引支持行级锁，这意味着在并发环境下，不同事务可以操作同一张表的不同行，而不会互相阻塞，大大提高了并发性能。

2. MyISAM 存储引擎及其索引行为

MyISAM是MySQL早期的默认引擎，它不具备事务能力，但对于读操作频繁且不需要事务支持的场景，曾经表现出色。

• 非聚簇索引 (Non-Clustered Index)：MyISAM的所有索引都是非聚簇的。
  • 它的数据文件（.MYD）和索引文件（.MYI）是分离的。
  • 索引的叶子节点存储的是数据行的物理地址（指针）。
  • 无论是主键索引还是其他辅助索引，其结构都是一样的：都是B-tree，叶子节点存储的是指向数据文件中对应行的物理地址。
• 查询过程：通过索引查找数据时，MySQL会先在索引中找到对应的物理地址，然后根据这个地址去数据文件中读取完整的行。
• 锁机制：MyISAM只支持表级锁。这意味着在任何时候，对表的写操作都会锁定整个表，读操作也会阻塞写操作，并发性能相对较低。
• 适用场景：过去常用于只读或读多写少、对事务不敏感的场景，如日志表、历史数据归档表等。

总结影响：

• 性能：InnoDB的聚簇索引在主键查询和范围查询上通常更快，但辅助索引可能需要“回表”。MyISAM的索引查找效率在某些简单场景下可能较高，但并发写入性能受表级锁影响大。
• 并发：InnoDB的行级锁提供了更高的并发性，而MyISAM的表级锁在写操作频繁时会导致严重的性能瓶颈。
• 数据完整性：InnoDB支持事务，可以保证数据的ACID特性，而MyISAM不具备事务能力，在数据崩溃或操作失败时可能导致数据不一致。
• 存储空间：InnoDB辅助索引存储主键值，可能比MyISAM存储物理地址占用更多空间（特别是主键很长时），但聚簇索引将数据和索引存储在一起，减少了I/O。

理解这些差异，对于你在设计表结构、选择存储引擎、优化查询性能时，至关重要。你不能简单地把索引看作一个独立的结构，它始终是其所属存储引擎设计理念的延伸。