MySQL InnoDB 引擎中的聚簇索引和非聚簇索引有什么区别？

1. 聚簇索引（Clustered Index）

聚簇索引 是指数据表中的数据存储按照索引的顺序排列，因此索引的叶子节点存储的不仅是索引列的值，还存储整行数据。

每张表只能有一个聚簇索引，因为数据物理上只能有一种排列顺序。

InnoDB 中的特点：

• 在 InnoDB 中，主键索引就是聚簇索引，即 InnoDB 表会自动将主键列作为聚簇索引。
• 如果没有定义主键，InnoDB 会尝试使用一个唯一的非空索引作为聚簇索引；如果表中没有主键或唯一非空索引，InnoDB 会自动生成一个隐式的 row_id 作为聚簇索引。

工作原理：

• 聚簇索引的叶子节点存储的不是指向数据的指针，而是整行数据。因此，通过聚簇索引进行查询时，可以直接从索引中找到所需的数据，而不需要额外的查找步骤。
• 由于数据和索引一起存储，按主键查询非常高效，因为查询的过程就是遍历聚簇索引找到数据的过程。

优点：

• 查询速度快：由于数据存储在索引的叶子节点中，按主键或按聚簇索引进行查询非常快，特别是范围查询（如 BETWEEN 或 ORDER BY）效率高，因为数据物理上按索引顺序存储。
• 索引覆盖**查询：因为聚簇索引中包含了整行数据，某些查询只需使用聚簇索引即可完成，避免了二次查找。

缺点：

• 插入和更新代价较高：由于数据按照索引顺序存储，插入新数据时可能需要调整数据存储的位置（维护顺序），因此插入效率比非聚簇索引低。
• 表的行存储顺序受限于聚簇索引：如果主键频繁变化，聚簇索引的维护成本较高。
• 大字段影响性能：如果表中包含大字段（如 BLOB、TEXT），它们也会存储在聚簇索引中，导致索引体积变大、性能下降。InnoDB 可以将这些大字段存储在页外，聚簇索引只存储其指针。

2. 非聚簇索引（Non-Clustered Index）

定义：

• 非聚簇索引 是指索引和数据是分开存储的。非聚簇索引的叶子节点存储的是索引列的值和指向实际数据的指针（即行号或主键）。
• 一张表可以有多个非聚簇索引，每个索引都有自己的存储顺序。

InnoDB 中的特点：

• 非主键索引 在 InnoDB 中就是非聚簇索引，这些索引的叶子节点存储的是索引列的值，以及对应行的主键值，而不是直接存储数据。
• 因此，通过非聚簇索引查询数据时，数据库首先需要使用非聚簇索引找到主键，然后再通过主键去聚簇索引中找到实际的数据。这种过程被称为回表（Secondary Lookup）。

工作原理：

• 非聚簇索引的叶子节点存储的是索引列的值和指向数据的指针。在 InnoDB 中，这个指针实际上是该行对应的主键值，因此在使用非聚簇索引时，MySQL 需要先通过非聚簇索引找到主键值，然后通过主键值回到聚簇索引中查找整行数据。

优点：

• 查找速度快（对于特定列的查询）：非聚簇索引可以加速对索引列的查找，尤其是对那些经常作为查询条件的列建立非聚簇索引，可以大大提高查询性能。
• 灵活性高：一张表可以有多个非聚簇索引，每个索引可以加速不同类型的查询。

缺点：

• 查询效率较低（需要回表）：非聚簇索引在查询时需要通过索引列找到主键，然后再去聚簇索引查找实际数据。这个过程比直接使用聚簇索引略慢。
• 额外存储：非聚簇索引需要额外存储主键信息，并且占用更多的磁盘空间。

3. 聚簇索引与非聚簇索引的对比

特性	聚簇索引（Clustered Index）	非聚簇索引（Non-Clustered Index）
数据存储方式	数据和索引一起存储，索引的叶子节点包含整行数据	索引和数据分开存储，叶子节点存储主键指针
数据存储顺序	数据按索引顺序存储，表只能有一个聚簇索引	数据与索引分离，表可以有多个非聚簇索引
访问速度	按聚簇索引访问数据速度快，尤其是范围查询	通过非聚簇索引访问时需要回表，速度稍慢
空间开销	索引较大，尤其是大字段时影响性能	存储索引列和主键的指针，额外占用空间
插入/更新效率	插入和更新效率较低，可能需要移动数据保持顺序	插入和更新效率较高，无需重新排序数据
典型应用	适合经常按主键查询、范围查询的场景	适合频繁使用非主键列查询的场景

示意图：

-- 聚簇索引（数据按主键排序存储）
索引树：根节点 → 分支节点 → 叶子节点（包含完整数据行）
-- 非聚簇索引（数据独立存储）
索引树：根节点 → 分支节点 → 叶子节点（存储主键或行指针） → 数据文件（按堆或聚簇索引组织）

查询性能对比

场景	聚簇索引	非聚簇索引
主键查询	⚡️ 直接定位数据（无需额外I/O）	需要回表查询（先查索引，再查数据）
范围查询	⚡️ 高效（数据物理连续）	🐢 需多次回表（随机I/O）
覆盖索引	天然覆盖（数据在索引中）	需索引包含所有查询字段才能避免回表
排序/分组	⚡️ 天然有序（无需额外排序）	🐢 需按索引顺序访问数据

示例：

-- 聚簇索引：主键范围查询（高效）
SELECT * FROM users WHERE id BETWEEN 100 AND 200;

-- 非聚簇索引：需回表（性能依赖索引覆盖）
SELECT * FROM users WHERE email = 'alice@example.com';
-- 若索引是 `INDEX(email)`，需先查索引找到主键，再通过主键查数据。

维护成本与适用场景

维度	聚簇索引	非聚簇索引
插入/更新	可能触发页分裂（数据需保持有序）	维护成本低（只需更新索引指针）
空间占用	索引即数据，无额外空间	需要额外存储索引结构和指针
适用场景	主键、频繁范围查询的字段	查询条件中的非主键字段、高选择性字段

4. 设计建议

1. 聚簇索引选择：
   • 使用自增主键（如 AUTO_INCREMENT），避免随机插入导致的页分裂。
   • 避免选择频繁更新的字段作为聚簇索引键。
   • 优先用于范围查询或排序的字段（如时间字段）。
2. 非聚簇索引优化：
   • 使用覆盖索引（包含查询所需的所有字段），避免回表。
   • 对高选择性字段（如唯一值多的列）建索引。
   • 避免过度索引（写操作需维护所有索引）。

5. 性能对比示例

场景：查询用户邮箱

• 表结构：

  CREATE TABLE users (
      id INT PRIMARY KEY,          -- 聚簇索引
      email VARCHAR(100) UNIQUE,   -- 非聚簇索引
      name VARCHAR(100)
  );
  

• 查询：

  -- 通过主键查询（聚簇索引）
  SELECT * FROM users WHERE id = 101;  -- ⚡️ 直接定位数据页
  
  -- 通过邮箱查询（非聚簇索引）
  SELECT * FROM users WHERE email = 'alice@example.com'; 
  -- 1. 查邮箱索引找到主键 id=101
  -- 2. 通过主键查聚簇索引获取完整数据 🐢 多一次I/O
  

6. 实际应用场景中的选择

聚簇索引的应用场景：

• 按主键查询频繁：如果你经常按主键查询数据，例如电商订单系统，按订单号（主键）查询订单信息，使用聚簇索引可以大大提高查询性能。
• 范围查询：当你需要在一个范围内查询数据时（例如日期范围查询），聚簇索引可以加速查询，因为数据物理上按顺序存储，范围查询时只需扫描连续的物理页。

非聚簇索引的应用场景：

• 按非主键列查询：当你的查询条件经常使用非主键列时（例如按用户邮箱查询用户信息），你可以为这些列创建非聚簇索引。
• 多列查询优化：如果你的应用场景中涉及到多个列的查询，可以为这些列创建多个非聚簇索引，来优化查询性能。

总结：

• 聚簇索引：数据存储按照索引顺序进行存储，每张表只能有一个聚簇索引，适合主键查询和范围查询的场景。
• 非聚簇索引：索引和数据分开存储，索引指向的是数据的主键，适合对非主键列进行快速查找的场景，表中可以创建多个非聚簇索引。

在 MySQL 的 InnoDB 存储引擎中，聚簇索引通常是主键，数据直接存储在聚簇索引中。而非聚簇索引存储的是指向数据的主键值，需要通过主键值再去聚簇索引查找实际数据。这种设计使得 MySQL 能够在保持高查询效率的同时，支持多种灵活的查询模式。