聚集索引 (Clustered Index) 是一种特殊的索引类型，它决定了表中数据的物理存储顺序。以下是主流关系型数据库对聚集索引的支持情况：

MySQL/InnoDB

• 支持聚集索引：InnoDB 存储引擎使用聚集索引
• 特点：
  • 主键自动成为聚集索引
  • 如果没有主键，则使用第一个非空的唯一索引 (UNIQUE NOT NULL) 作为聚集索引
  • 如果既无主键也无合适的唯一索引，InnoDB 会创建一个隐藏的 rowid 作为聚集索引
  • 表数据按照聚集索引的顺序物理存储

SQL Server

• 支持聚集索引：完全支持
• 特点：
  • 每个表只能有一个聚集索引
  • 主键默认创建为聚集索引，但可以指定为非聚集
  • 聚集索引的键列通常应选择窄的、静态的、持续增长的列
  • 当表没有聚集索引时称为 "堆"(heap) 表

Oracle

• 不支持传统聚集索引：但有类似概念
• 替代方案：
  • 索引组织表 (IOT, Index-Organized Table)：类似于聚集索引，表数据存储在索引结构中
  • 表聚簇 (Table Cluster)：多个表共享相同的数据块，基于聚簇键物理存储在一起

PostgreSQL

• 不支持传统聚集索引：但有类似功能
• 替代方案：
  • 使用 CLUSTER 命令可以基于某个索引重新组织表的物理顺序
  • 但这种排序不会自动维护，后续的 DML 操作会逐渐打乱顺序
  • 可以定期执行 CLUSTER 命令重新组织

DB2

• 支持聚集索引：称为 "集群索引"(Clustering Index)
• 特点：
  • 表数据尝试按照集群索引的顺序存储
  • 新插入的数据会尽量放在正确的位置以维持顺序
  • 但不像 SQL Server 那样严格保证物理顺序

SQLite

• 支持聚集索引：类似于 MySQL
• 特点：
  • 主键自动成为聚集索引 (除非声明为 INTEGER PRIMARY KEY，此时是 rowid 别名)
  • 表数据按照聚集索引顺序存储

聚集索引的优缺点

优点：

• 范围查询效率高
• 减少 I/O 操作 (相关数据物理上相邻)
• 避免额外的书签查找

缺点：

• 更新聚集索引键列代价高(可能导致行移动)
• 插入操作可能导致页分裂
• 每个表只能有一个聚集索引

在实际应用中，聚集索引的选择通常基于最频繁的查询模式，通常选择在范围查询或排序操作中使用的列。