sql server 2005中的复合聚集索引和非聚集索引
我创建了一个带有复合主键的新表，假设 PrmID 和 Type，因此创建了一个新的复合聚集索引（PrmID 是第一个）。我为 Type 添加了另一个非聚集索引。
我的问题是 - 当我生成对类型执行任何语句（例如 GROUP BY）的查询时，SQL 引擎是否使用非聚集索引表或 PK 聚集索引（对于此类查询来说更昂贵）？
I created a new table with composite primary key, Lets say PrmID and Type, therefor a new composite clustered index has created (PrmID is first).I add another non clustered index for Type.
My question is - when I generate a queries that perform any statement on Type (such as GROUP BY), is the SQL engine using the non clustered index table or the PK clustered index (which more expensive for that kind of queries) ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
-- 编辑 --
谢谢马克，我错过了...
-- 编辑结束 --
其次，PrimID 在您的表中真的不是唯一的，并且仅与 Type 组合时才是唯一的吗？如果 PrimID 在表中不重复，则可能需要重新考虑将其设为复合 PK。
第三，回答这些类型问题的最佳方法是查看查询的执行计划。我们可以给你一个关于我们认为 SQL 应该如何处理计划的答案，但是 SQL Server 会根据你的数据库中的数据、你的硬件等来改变各种情况的执行计划......
这里是执行计划会是什么样子：
您可以看到它准确地告诉您使用了哪些索引以及如何使用它们... < a href="http://sqlserverpedia.com/wiki/Examining_Query_Execution_Plans" rel="nofollow noreferrer">这里有一篇文章很好地介绍了如何理解执行计划。
-- EDIT --
Thanks marc, I missed that...
-- END EDIT --
Second, is PrimID really not unique in your table, and is only unique in combination with Type? If PrimID is not duplicated in the table, maybe reconsider making it a composite PK.
Third, the best way to answer these types of questions is to look at the execution plan for your query. We can give you an answer on how we think SQL should handle the plan, but SQL Server will change the execution plan for various circumstances based on the data in your database, your hardware, etc...
Here's what the execution plan will look like:
You can see that it tells you excatly which idexes are used, and how they are used... here's an article that gives a good introduction into understanding the execution plans.
这取决于查询的外观、访问哪些列、是否覆盖等。
简单的 GROUP BY 类型很可能会使用 NC 索引。如果您使用其他列，您可能会得到图书图/键查找，或者索引将被忽略，并且您将进行低效的 PK 扫描
It depends on what the query look like, what columns are accessed, is it covering etc
A simple GROUP BY on type will most likely use the NC index. If you use other columns you may get a bookmap/key lookup or the index will be ignored and you'll have an inefficient PK scan
我的理解是，当你有一个多字段索引并且你的查询不使用索引中的第一个字段时，那么该索引将不会被使用（太难，效率不高等）。然后将使用另一个索引。
但是，要明确地知道这一点，请使用执行计划甚至只是估计的执行计划来运行查询。如果您使用 SSMS，这很简单，只需按工具栏按钮即可。它看起来像三个蓝色和绿色的小盒子，呈倒“L”图案。这将准确地告诉您正在使用什么索引。虽然执行计划可以在查询的生命周期中发生变化（随着数据的变化），但它不应该用于这个答案。
My understanding is that when you have a multi-field index and your query is not using the first field in the index, then that index will not be used (too difficult, not efficient, etc.) It will then use the other index.
But, to know this definitely, run your query with an execution plan, or even just an estimated execution plan. If you are using SSMS this is easy as pressing a tool bar button. It is the one that looks like three little blue and green boxes in an inverted "L" pattern. This will tell you exactly what index is being used. And while execution plans can change over the life of a query (as the data changes), it should not for this answer.