问题标签 [non-clustered-index]

在我的 SQL Server 数据库中，我在它们上创建了视图以及聚集和非聚集索引。检索记录变得更快，但是当我尝试从表中编辑某些内容（例如名称）时，它花费了 20 秒的时间。我能做些什么来防止这种浪费时间。有任何想法吗。

聚集索引对磁盘上的数据进行物理排序。

假设我有表员工和列员工 ID。现在我将值存储9, 6, 10, 4在employee_id 下。在employee_id 上有聚集索引。磁盘上的值将以排序方式存储，即 4、6、9、10。现在，如果我在 id 为 9 的employee_id 上搜索，数据库可以使用二进制搜索或其他搜索算法来快速查找 id 为 9 的记录。所以它可能它不会像二进制搜索那样在一次操作中对记录进行精细处理。 那是对的吗？

非聚集索引 非聚集索引具有索引列中的数据的副本，这些数据与指向实际数据行的指针一起保持有序（如果有，则指向聚集索引）。因此，如果采取与上述相同的示例。在这种情况下，数据库将创建单独的对象来存储数据以及内存位置。类似这样的东西

9 -- 它的物理位置

6 -- 它的物理位置

10 -- 它的物理位置

4 -- 它的物理位置

所以我首先需要在新创建的对象中搜索 10 并获取它的内存位置。然后回到原来的内存位置。 那么它是如何使搜索更快的呢？

同样根据我的理解，应该在 where 子句而不是 select 子句下涉及的列上创建索引。正确的？

我有一个堆表 - 没有定义聚集索引 - （调用它table A），在不可为空的列上有一个唯一的非聚集索引（调用column ID和index IX）。

我想index IX在定义主键约束时使用column IDfor table A。

某处的文档是这样说的：

数据库引擎自动创建唯一索引以强制执行 PRIMARY KEY 约束的唯一性要求。如果表上不存在聚集索引或未显式指定非聚集索引，则会创建唯一的聚集索引以强制执行 PRIMARY KEY 约束。

我已经阅读了整个ALTER TABLE文档，但似乎没有“非聚集索引是……明确指定的”的语法。

已尝试定义非聚集index IX和指定主键，还尝试了更改表的各种组合...添加约束...主键语句无济于事。

有意义的是，我的索引 IX 等效于 SQL Server 在我简单地指定更改表中的 ID 列时创建的非聚集索引 .... 添加约束 .... 主键 (ID) 语句，但我不希望拥有 SQL Server 为我创建的这个冗余索引，而是让它使用index IX它还包含一个列的包含列表。

如果我删除 SQL Server 创建的索引，那么主键约束也会消失。

如果可以更改 SQL Server 创建的索引，我的问题将得到解决，但我想对其进行的更改需要删除并重新创建。

场景的简要概述：

我的数据库使用 GUID 作为主键，并且，对于我一直在阅读的内容，在 GUID 上使用聚集索引似乎有点糟糕（增加碎片，减慢插入速度等）。我的项目使用休眠，所以我们通常处理 jpql 并获取完整实体（很多查询最终变成了select p.* from person p [...]）

我想知道创建覆盖表的所有列的非聚集索引是否是一种好方法（以避免 RID 查找等）。

感谢您的帮助，已经！

用两列创建索引和在两列上创建单独的索引有什么区别？

之间的区别

和

#testing 和 #testing2 上没有索引

#testing 和 #testing2 上 id 列的索引

指数是

在这种情况下，最好的索引是什么？#testing(name) 上没有索引是否正确，因为写入/更新会更慢？

我们有一个庞大的（并且不断增长的）鸟类记录的 MySQL 数据库。目前我们主要有三个表，简化如下：

所有 id 都是 INT，日期是 DATE 类型。

为了获得性能，我决定通过将 date 和 locid 复制到 RECORDS 中来进行一些非规范化：

这样，许多查询将避免昂贵的 BIRDTRIPS 和 LOCATIONS 连接。

MySQL 每个表只有一个聚集索引，并且这始终是主键。我很想
尝试PRIMARY KEY (date, id)使用 RECORDS 来利用聚集索引来更快地对日期列进行范围扫描和对表进行分区。id 仅包含在键中，因为同一日期可能有许多记录。从理论上讲，主键通常在 id 上有点“浪费”，其中非聚集 UNIQUE 索引足以进行查找。

现在我的问题：

你们中有人对这种方法有实际经验吗？有什么我可能忽略的缺点吗？

我还不是很精通 SQL。我正在学习，但这是一个缓慢的过程。我正在从事一个项目，该项目将大量信息存储在 SQL Server 的数据库中。在其中一个表 ContactInformation 中，当尝试修改条目时遇到错误，因为由所有地址信息组成的非聚集索引超过 900 字节。我曾经sys.dm_db_index_usage_stats验证修改表中的条目会导致 3user_seeks和 1 user_update。

C# 代码似乎没有直接调用索引。它执行一个由具有 19 个参数DbCommand的各种存储过程命令组成的单个命令。Update我的想法是要么消除索引，要么尝试DbCommand使用较少的参数将其分解为多个更新，以期使用较小的索引。

由于缺乏经验，我有点不知所措。我欢迎任何关于下一步转向的建议。

该指数包括以下内容：

是的，大多数列都过大。我们显然是从另一个项目继承了这个数据库。我们的软件将大多数列限制为不超过 100 个字符，尽管存在一些异常值。

我的问题是例如我有以下列

现在假设我正在创建一个非聚集索引，Cl2但是当我查询时，Cl2我总是检索Cl3并且Cl4也。

包含在索引中是合乎逻辑的，Cl3因为它会使检索操作更快，但是Cl4它nvarchar(max)很大并且可能很大：此列包含已爬取的页面源

所以我的问题是：是否包含Cl4在非聚集索引中是合乎逻辑的

包括它会Cl4在硬盘上准确存储 2 次？

非常感谢您的回答

SQL Server 2014

我试图通过创建一个堆表来检查 RID（以前的书签）查找：

然后，我尝试了以下查询来调查执行计划：

但是，使用 MSSMS 我在执行计划中看不到 RID 查找：

我正在使用 SQL Server 2008R2（版本 10.50.4000.0）服务包 2。

PS：这个问题是基于 Aaron Bertrand 的文章。