假设我有一个名为'demo'的表，有4列; 'a'，'b'，'c'和'd'。 'demo'表的primary key clustered index按顺序包含'a'和'b'列。
来自查询引用表'demo'的'实际执行计划'建议列'b'需要新的non-unique non-clustered index，include列'a'
如果我在列'b'上创建non-unique non-clustered index，我需要include列'a'还是已经成为non-clustered index的一部分，因为它在primary key？
如果主键列'a'已经是非聚集索引的一部分，列'a'是作为include列存储还是非聚集键的一部分？
答案 0 :(得分：1)
“实际执行计划”＆＃39;来自查询引用表＆＃39; demo＆＃39;具有 建议需要一个新的非唯一非聚集索引 专栏＆＃39; b＆＃39;并且应该包含列＆＃39; a＆＃39;。
...
如果主键列＆＃39; a＆＃39;已经是非聚集索引的一部分， 是专栏＆＃39; a＆＃39;存储为包含列或是它的一部分 非群集密钥？
在您的情况下，列a将在所有级别的非聚集索引上显示为聚簇索引键的部分。建议您的索引为non-unique，因此需要 uniquefier ，并且聚集索引键将用于此目的。
如果提供的索引唯一，则列a将作为行定位器的一部分存储在此索引的叶级别上，如果是聚簇表是聚簇索引键。
如果您明确将a列为索引的included column，则a列将不会存储两次，因此我建议您将其包含在内。当有人决定将您的聚簇表转换为堆时（通过删除聚簇索引），它会有所不同。在这种情况下，如果您未在非聚集索引中明确包含列import selenium
from selenium import webdriver
browser = webdriver.Firefox()
browser.get("https://accounts.spotify.com/en/login?
continue=https:%2F%2Fwww.spotify.com%2Fdk%2Faccount%2Foverview%2F")
username = browser.find_element_by_id("login-username")
password = browser.find_element_by_id("login-password")
username.send_keys("myUser")
password.send_keys("myPass")
login = browser.find_element_by_class_name('ng-pristine ng-valid-sp-
disallow-chars ng-invalid ng-invalid-required').click()
，则它将丢失并且不再包含在非聚集索引中
答案 1 :(得分：0)
试试这个并观看执行计划。您可以看到DB仅使用INDEX。所以，据我所知，你不应该在索引中包含A列（如你所说，Clust。索引键已包含在内）。
pptSlide答案 2 :(得分：0)
非聚集索引会自动隐式包含聚簇索引键。 在documentation中，您可以获得有关此内容的大量信息，但特别是这部分解释了这一点：
非聚集索引架构
非聚集索引的叶层由索引页组成 而不是数据页面。非聚簇索引行中的行定位器是 指向行的指针或行的聚簇索引键。
如果您的表是一个堆，那么行定位器将直接指向包含键值的数据行，但如果您的表不是堆（在这种情况下，因为您已经在该表上有一个聚簇键然后行定位器指向聚集索引键。
同时查看clustered and nonclustered indexes described。
该主题讨论了相同的内容：Necessary to include clustered index columns in non-clustered indexes?
答案 3 :(得分：0)
在非聚集索引中包含列a是无用的，因为它是聚簇索引键的一部分。因此，它是非聚集索引的叶页中的数据的一部分。有这样的查询
SELECT a FROM tab WHERE b = <value>
那么a值自然会成为非聚集索引中叶子数据的一部分。
答案 4 :(得分：0)
PK字段始终是索引键的一部分，而不是包含列的一部分。
我在想这里或许是想通过B栏寻找;只有当列B是索引中的第一个键时才能执行此操作。如果首先定义一个带有列B的索引，然后是列A，那么它可能就是这样做的。似乎只要两个键都在索引中就会很高兴，因为你有一个复合PK，虽然它们目前可能处于错误的顺序（先是A，然后是B），从而阻止了搜索。
PK字段的引用自动显示在索引中：https://www.brentozar.com/archive/2013/07/how-to-find-secret-columns-in-nonclustered-indexes/