我继承了一个使用SQL Server 2005的项目，最近出现了一些性能问题，我开始查看索引，发现
_dta_index_survey_25_135059617__K1_K10_K19:
id ASC, sent_date ASC, group_id ASC
和
_dta_index_survey_21_364632442__K18_K1_K2_K9:
group_id ASC, id ASC, campaign_id ASC, sent_date ASC
这似乎是由某种自动性能调整工具生成的。我认为 SQL Server 带有类似的东西，但我不熟悉它。
无论如何，id是主键，我在这里试图理解的是将主键包含在二级索引中可能有什么好处......因为您必须拥有最左边的信息才能使用索引和如果你知道，id那么无论如何你已经得到了这一行。
有人可以解释为什么工具会生成这些索引，以及保留它们是否有任何意义？
仅仅因为索引被使用并不意味着它们是一个好的设计。SQL Server最近使用了错误的索引，我正在尝试确定原因。更具体地说，对一个月前以毫秒为单位运行的此表的查询现在需要数秒。这张桌子很大（400 万行），而且还在稳步增长，但多年来一直以同样的速度发展。
几乎每个查询都通过group_idor连接campaign_id。往往两者兼而有之。该应用程序几乎从不专门按 PK 进行选择或排序，但我可以看到ID在比较或合并ID数据库引擎中的s列表时如何有用。...但id也是一个标识列，并且一个索引包含行 id 的列表，因此ID当它也在索引“存储桶”中时，在键中使用它似乎仍然是多余的。并且额外的字段仍然可以被索引覆盖而不是键的一部分。
我发现(id, sent_date, group_id)几乎没有人读过。同时(group_id, id, campaign_id, sent_date)是最热门的指数之一。接下来我发现一个我认为非常合理的索引在表中的每一个其他列中(campaign_id, sent_date, group_id, id)也有一个index_columns_include，并且比主聚集索引占用更多的空间id！（但它也很热......）我当然可以用一个简单的(campaign_id, sent_date, group_id)?