我正在从包含以下类型的列的组合键中更改SQL Server 2014数据库的主键：
SELECT * FROM (`todolist`) WHERE `type` = '2' AND user_id = '1' AND alerttime >= date_add(now(), interval 5 minute)
包含以下内容的组合键
VARCHAR(10), INT, DATETIME
其中第二个键中的INT, DATETIME
是新列，是INT，VARCHAR(10)先前组合的哈希。我还无法更改主键，因此在添加新列之后，我创建了一个索引，将来将成为新的主键（INT）：
INT, DATETIME这时，我切换了读者以使用此索引而不是主键来获取数据。一切正常，但性能严重下降（时间翻倍）。
在这一点上，我尝试将（CREATE UNIQUE NONCLUSTERED INDEX MyIndex
ON MyTable(MyIdCol, MyDateCol)
）设置为新的主键。查询速度提高了30％到40％，但是老实说，我认为在这个新主键上的查询要比其中有INT, DATETIME的旧主键要快得多（当然，我可能会在其中弄乱一些内容）我的基准测试-数据库架构非常复杂，需要24小时来设置测试用例。
不幸的是，我仍将生产中的主键删除了-我需要一个同时拥有旧的主键和新的唯一索引的阶段，因此我将需要在该索引上获得类似的性能。我需要指示要看的内容。老实说，我不完全理解为什么在VARCHAR上进行查询（即使只是索引而不是主键）比INT,DATETIME主键要慢得多。
答案 0 :(得分：1)
这个评论太长了。
“慢”慢多少？在搜索非聚集索引时，数据库引擎需要在索引中找到行引用（非常快速），然后加载数据页以获取行。
使用聚簇索引进行搜索时，无需加载数据页。
在获取多行时，差异可能会更加明显，因为聚集索引将把数据存储在同一数据页上。对于要检索的每个项目（直到某个点），非聚集索引很可能是从不同的页面中获取的。
您可以通过仅获取索引中的列来比较性能差异。这可能不是您想要的，但这是可行的性能比较。这两个索引之间应该相似。
此可能解释了性能差异。如果是这样，则无需担心，因为这是不使用聚簇索引时的预期开销。通常，对于快速的查询来说这相对较大，而对于较慢的查询来说则不太重要。