关于复合索引上Clustered/Non-clustered Index的技术咨询及建表疑问

一、复合聚集索引 #

聚集索引决定表数据的物理存储顺序，一个表只能有一个聚集索引。基于多列创建的复合聚集索引，需重点关注以下内容：

• 列顺序直接影响索引效率：查询条件必须匹配索引的前缀列，才能触发索引扫描/查找。比如创建(someid, category)的复合聚集索引，WHERE someid = 123可以利用索引，但WHERE category = 'book'无法直接使用该索引。
• 优先选择小体积、稳定的列组合：聚集索引的键值会被所有非聚集索引存储，若复合索引包含大字段（如text、varchar(1000)），会导致所有非聚集索引体积膨胀，降低查询性能。
• 唯一性考量：如果复合聚集索引的列组合不是唯一的，数据库会自动添加唯一标识符保证唯一性，这会额外占用存储资源。

结合你提供的表结构（假设后续补充业务列），示例代码如下：

-- 补全表结构（原语句不完整）
CREATE TABLE some (
  someid bigint NOT NULL,
  category varchar(50) NOT NULL,
  create_time datetime NOT NULL,
  content text
);

-- 创建复合聚集索引
CREATE CLUSTERED INDEX IX_some_someid_category ON some(someid, category);

二、复合非聚集索引 #

非聚集索引不改变表数据的物理存储，一个表可以创建多个。复合非聚集索引的设计要点：

• 列顺序优先匹配高频查询的过滤列：把最常出现在WHERE、JOIN条件中的列放在索引前列。
• 利用INCLUDE列实现覆盖查询：如果查询需要返回的列不在索引键中，可通过INCLUDE添加这些列，避免“回表”查询聚集索引获取数据，提升性能。
• 非聚集索引的叶子节点存储聚集索引键（若表存在聚集索引），因此聚集索引的体积越小，非聚集索引的效率越高。

示例代码：

-- 创建复合非聚集索引，包含content列避免回表
CREATE NONCLUSTERED INDEX IX_some_someid_createtime ON some(someid, create_time)
INCLUDE (content);

三、关键注意事项 #

• 若someid本身是唯一且高频查询的列，单独将其设为聚集索引通常比复合聚集索引更高效，除非业务查询绝大多数是基于someid+其他列的组合过滤。
• 避免在频繁更新的列上创建复合索引（尤其是聚集索引），因为索引列的更新会导致索引结构重新调整，带来较大性能开销。

内容的提问来源于stack exchange，提问作者umarkaa