多表使用相同聚集索引时，可否省略附属表的call_id主键索引？

你提到的设计思路确实能降低索引维护和存储成本，但存在以下明确弊端：

• 聚集索引查找的实际开销远高于预期
  你假设第二步是直接定位到行，但由于你的聚集索引仅以start_time作为键，相同start_time值的所有行是连续存储的，SQL Server拿到子查询返回的start_time后，需要扫描该时间点下的所有行来匹配call_id值。如果业务高峰时段同一秒有数百上千条通话，这部分扫描开销会比直接在calls_other_data.call_id上走非聚集索引查找高1~2个数量级，和你的预期性能差距极大。
• 子查询存在报错风险
  如果calls表中同一个call_id因写入异常出现重复行，子查询会返回多个start_time值，直接导致整条查询报错。即使你给calls.call_id加上唯一约束避免该问题，额外的唯一校验也会增加calls表的写入开销，和你降本的目标相悖。
• 固定多一次跨表查询的累积开销不可忽视
  每查询一次附属表你都需要多执行一次calls表的索引查找，单次开销虽小，但如果这类查询的QPS较高，累积的CPU、IO开销完全可能超过你节省的索引维护成本，整体投入产出比反而更低。
• 批量查询、范围查询场景完全不适用
  如果后续出现批量查询多个call_id附属表数据、查询某个通话的全量时间段附属数据等需求，该设计的性能会出现暴跌，需要多次查询calls表拿时间戳、多次扫描聚集索引，效率远低于直接走附属表的call_id索引。
• 数据一致性问题排查难度极高
  如果因写入逻辑异常、时区处理错误、写入延迟等问题，导致calls表和附属表中同一个call_id对应的start_time不一致，你使用的如下查询会直接返回空结果，排查时很难定位到是两边时间戳不匹配的问题，会大幅提升运维成本：

SELECT cod.some_column
FROM calls_other_data cod
WHERE cod.start_time = (SELECT start_time 
                        FROM calls 
                        WHERE call_id = '36-chars-unique-value')
  AND cod.call_id = '36-chars-unique-value'

适配需求的优化方案 #

如果确实要尽可能压缩存储和索引维护成本，可以直接将所有表的聚集索引调整为(start_time, call_id)的联合聚集索引，不需要额外给附属表建非聚集索引：

-- 聚集索引创建示例，实际执行需结合表结构调整语法
CREATE CLUSTERED INDEX IX_clustered ON calls_other_data (start_time, call_id)

调整后你的原查询语句可以直接走聚集索引的二元查找精准定位到行，性能和单独建call_id非聚集索引完全一致，也不会额外增加存储开销，完美适配你的降本需求。

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