SQLServer索引创建数量决策指南

最新推荐文章于 2026-07-20 12:50:14 发布

原创最新推荐文章于 2026-07-20 12:50:14 发布 · 918 阅读

11 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

这是一个非常经典且重要的问题，但也是一个没有固定答案的问题。简单来说，对于一个表创建多少个索引最合适，没有“神奇数字”。它完全取决于你的具体工作负载：是读多写少，还是写多读少。

不过，我可以给你一套完整的指导原则和思考框架，帮助你做出正确的决策。

核心原则：权衡利弊

索引的本质是 “空间换时间”，同时也会带来维护成本。

优点（为什么需要索引）：
- 极大加快 SELECT、WHERE、ORDER BY、GROUP BY、JOIN 的查询速度。
缺点（为什么不能无限制创建）：
- 降低写操作（INSERT、UPDATE、DELETE）速度： 每次数据修改，数据库都需要更新所有相关的索引，索引越多，维护成本越高。
- 占用额外磁盘空间。
- 可能导致索引碎片， 需要定期维护。

决策的关键因素

在决定为表创建多少个索引时，请考虑以下几点：

工作负载类型（最关键的因素）
- OLTP（在线事务处理）： 典型的业务系统，如电商、ERP。特点是大量的、短小的、并发的增删改查操作。对这种系统，索引要少而精。因为写操作非常频繁，过多的索引会严重拖慢系统。通常建议每个表 3-5个 精心设计的索引是比较常见的起点。
- OLAP（在线分析处理）： 数据仓库、报表系统。特点是批量加载数据，然后运行复杂的、需要全表扫描或大量数据聚合的查询。对这种系统，可以创建更多的索引（包括覆盖索引）来加速查询，因为写操作的频率很低（通常只是定时ETL）。一个表有 10个甚至更多 索引也很常见。
表的规模
- 小表（几千行）： 可能根本不需要索引，因为SQL Server直接进行表扫描可能更快。
- 大表（百万行以上）： 必须有索引，否则查询无法接受。索引的数量需要根据查询的复杂度和频率来仔细设计。
写/读比率
- 读远大于写（如 90%读，10%写）： 可以放心地创建更多索引。
- 写远大于读（如 10%读，90%写）： 必须非常谨慎地添加索引，每个索引都要有充分的理由。

具体建议和最佳实践

从分析查询开始
- 使用 SQL Server Profiler 或 Extended Events 来捕获生产环境中的真实查询。
- 使用 Database Engine Tuning Advisor 来分析工作负载，它会给出索引建议。这是一个非常好的起点。
- 查看执行计划，寻找那些开销巨大的 “表扫描” 或 “索引扫描” 操作，这些通常是需要创建索引的信号。
优先考虑高质量的索引
- 聚集索引： 每个表最好有一个聚集索引。它决定了数据的物理存储顺序。通常在主键上创建，或者在有顺序范围的列上创建（如 CreateDate）。
- 非聚集索引： 针对最常用、最关键的查询条件创建。
  - 高选择性列： 在选择性高的列上创建索引（即该列唯一值多，如 UserID, OrderID）。在性别（只有‘男’，‘女’）这种低选择性列上建索引通常没用。
  - 复合索引： 将多个列组合在一个索引中。注意列的顺序：将最常用于查询条件且选择性最高的列放在最前面。例如，对于 WHERE LastName = ‘Smith’ AND FirstName = ‘John’，创建 (LastName, FirstName) 的索引比 (FirstName, LastName) 更有效。
利用覆盖索引
- 如果一个索引包含了查询所需的所有列（即 SELECT 的列、WHERE 的列等），那么数据库就不需要再去查找数据页，可以极大地提升性能。这被称为“覆盖索引”。
- 例如，查询是 SELECT UserId, UserName FROM Users WHERE Email = ‘xxx@example.com‘，创建一个 (Email) INCLUDE (UserId, UserName) 的索引，它就是覆盖索引。

定期审查和维护索引

使用以下DMV来查找无用或重复的索引，并考虑删除它们：

sql

-- 查找从未被使用过的索引（自服务器重启后）
SELECT OBJECT_NAME(i.object_id) AS TableName, i.name AS IndexName
FROM sys.dm_db_index_usage_stats us
INNER JOIN sys.indexes i ON us.object_id = i.object_id AND us.index_id = i.index_id
WHERE OBJECT_NAME(i.object_id) = ‘YourTableName‘
AND us.user_seeks = 0
AND us.user_scans = 0
AND us.user_lookups = 0
AND us.last_user_seek IS NULL
AND us.last_user_scan IS NULL
AND us.last_user_lookup IS NULL;

-- 查找重复索引
-- (需要借助一些现成的脚本，原理是比较索引键和包含列)

定期进行索引重建或重组，以消除碎片。

总结

场景	建议索引数量	理由
高并发OLTP（写密集型）	少（如 2-5个）	最小化写操作期间的索引维护开销。
OLTP（读多写少）	中等（如 5-10个）	在查询性能和写开销之间取得平衡。
OLAP/数据仓库	多（10个以上）	查询性能是首要任务，写操作不频繁。