SQL Server百万级Recording表索引设计：多列索引还是按报表建索引？

场景说明 #

有一张包含数百万行数据的Recording表，结构为(Id, CampaignId, CallDateTime, Phone等)，核心有两类报表查询：

按日期查询

declare @CampaignId int = 1, @Date date = '2023-06-27'
select * from Recording
where CampaignId = @CampaignId and cast(CallDateTime as date) = @Date

按手机号查询

declare @CampaignId int = 1, @Phone varchar(9) = '987654321'
select * from Recording
where CampaignId = @CampaignId and Phone = @Phone

索引设计结论 #

应该分别创建**(CampaignId, CallDateTime)和(CampaignId, Phone)**两个独立索引，而非包含三个字段的多列索引。

原因分析 #

1. 多列索引的局限性
   如果创建(CampaignId, CallDateTime, Phone)这类多列索引，对于按手机号查询的场景，由于查询条件仅包含CampaignId和Phone，而Phone在索引的第三列，无法利用索引的前缀匹配规则——数据库无法跳过中间的CallDateTime字段直接定位Phone，大概率会走全表扫描或低效的索引扫描，完全发挥不出索引的优势。

2. 独立索引的适配性

• 针对按日期查询：(CampaignId, CallDateTime)索引会先按CampaignId分组，再按CallDateTime排序。这里可以优化原查询的日期条件，把cast(CallDateTime as date) = @Date改成CallDateTime >= @Date and CallDateTime < DATEADD(day, 1, @Date)，避免函数转换导致索引失效，让数据库能直接利用索引快速定位到指定日期范围的行。
• 针对按手机号查询：(CampaignId, Phone)索引同样先过滤CampaignId，再精准匹配Phone，因为Phone是索引的第二列，前缀匹配有效，能快速定位到目标数据，查询效率拉满。

3. 补充优化点
   如果查询并非真的需要返回所有字段（select *），可以考虑创建覆盖索引，把查询需要的字段通过INCLUDE子句添加到索引中，避免回表查询进一步提升性能。比如针对按日期查询的索引可以写成：

CREATE INDEX IX_Recording_CampaignId_CallDateTime ON Recording(CampaignId, CallDateTime)
INCLUDE (Id, Phone, [其他需要的字段]);

但如果确实需要返回所有字段，覆盖索引的体积会过大，反而可能影响写入性能，这时候优先保证过滤条件的索引效率即可。

内容的提问来源于stack exchange，提问作者Alberto Zambrano Green