问题标签 [clustered-index]

在 SQL 中，很明显，每当我们想要对数百万条记录进行搜索时，比如 Transactios 表中的 CustomerID，那么我们想要为 CustomerID 添加一个索引。

当我们需要使用该字段作为标准进行内部联接或外部联接时，我们是否希望向该字段添加索引？如 Inner join on t1.custumerID = t2.customerID。然后，如果我们在两个表上都没有关于 customerID 的索引，我们正在查看 O(n^2)，因为我们需要按顺序遍历这两个表。如果我们在两个表上都有 customerID 索引，那么它变成 O( (log n) ^ 2 ) 并且速度要快得多。

我们想在表中的字段中添加索引的任何其他情况？

为表中组合的 2 个字段添加索引怎么样。也就是说，一个索引，2个字段在一起？

我正在努力理解 SQL Server 2005 中的聚集索引是什么。我阅读了 MSDN 文章Clustered Index Structures（以及其他内容），但我仍然不确定我是否理解正确。

（主要）问题是：如果我将一行（带有“低”键）插入带有聚集索引的表中会发生什么？

上面提到的 MSDN 文章指出：

数据链中的页面和其中的行按聚集索引键的值排序。

并以使用聚集索引为例说明：

例如，如果将一条记录添加到靠近顺序排序列表开头的表中，则表中该记录之后的任何记录都需要移动以允许插入该记录。

这是否意味着如果我将具有非常“低”键的行插入到已经包含大量行的表中，实际上所有行都在磁盘上进行了物理移动？我不能相信。这需要很长时间，不是吗？

还是（正如我怀疑的那样）有两种情况取决于第一个数据页的“完整”程度。

• A）如果页面有足够的可用空间来容纳记录，则将其放置到现有数据页面中，并且数据可能（物理上）在该页面中重新排序。
• B）如果页面没有足够的可用空间用于记录，将创建一个新的数据页面（磁盘上的任何位置！）并“链接”到 B 树的叶级别的前面？

这将意味着数据的“物理顺序”仅限于“页面级别”（即在数据页面内），而不是位于物理硬盘驱动器上连续块上的页面。然后数据页以正确的顺序链接在一起。

或者以另一种方式表述：如果 SQL Server 需要读取具有聚集索引的表的前 N ​​行，它可以顺序读取数据页（按照链接），但这些页在磁盘上不是（必然）按块顺序排列（所以磁盘头必须“随机”移动）。

我离我有多近？:)

如果您有一个在主键 (int) 上具有聚集索引的表，那么拥有一个（或多个）非聚集索引（包括该主键列作为非聚集索引中的列之一）是否是多余且不好的?

我们有一个针对 SQL Server 2005（集群）的 .NET 客户端应用程序，我是否需要在客户端应用程序中做一些特殊的事情以使其能够识别集群？

我正在研究一个数据库系统和它的索引，但是我很难看到覆盖索引和聚集索引之间的明显区别。

我已经用谷歌搜索了我的方式，但没有得到明确的答案：

1. 两种索引有什么区别
2. 什么时候使用覆盖索引，什么时候使用聚集索引。

我希望有人可以用几乎像孩子一样的回答向我解释:-)

真诚的梅斯蒂卡

顺便说一句，我使用的是 IBM DB2 9.7 版

我正在我的数据库中运行一些查询，并希望提高性能并创建了一些索引，但我仍然认为响应时间很棒，所以我想看看我是否可以创建一个更好或另一个索引来提高速度。

我认为具有最大瓶颈的表的架构如下所示：

有趣的是包含日期（例如 2010-05-20）的SDD属性，在我的查询中，我进行了这样的范围搜索： SDD >= '2010-05-03' 和 SDD < '2010-05-08'

我拥有的确实提高了性能的索引是

问题是，当我进行 2010-05-03 和 2010-06-04 等距离很远的范围搜索时，执行查询大约需要 6-10 秒，我真的很想调整它。

我在 SDD 上尝试了几个索引，甚至一个集群索引，但到目前为止我得到的最好结果是上面的索引。

任何建议将不胜感激。

真挚地

梅斯蒂卡

这个问题是关于在插入完成后重新组织聚集索引中的数据会发生什么。我认为在具有聚集索引的表上进行插入应该比没有聚集索引的表更昂贵，因为在聚集索引中重新组织数据涉及更改磁盘上数据的物理布局。除了通过我在工作中遇到的示例外，我不确定如何表达我的问题。

假设有一个表 (Junk)，并且在表上执行了两个查询，第一个查询按名称搜索，第二个查询按名称和某事搜索。当我在处理数据库时，我发现该表已经创建了两个索引，一个用于支持每个查询，如下所示：

现在，当我查看这两个索引时，似乎 IX_Name 是多余的，因为任何希望按名称搜索的查询都可以使用 IX_Name_Something。所以我会消除 IX_Name 并使 IX_Name_Something 成为聚集索引：

有人建议应该保留第一个索引方案，因为它会导致更有效的插入/删除（假设无需担心 Name 和 Something 的更新）。这有意义吗？我认为第二种索引方法会更好，因为这意味着需要维护的索引更少。

我将不胜感激对这个特定示例的任何见解或指导我了解有关维护聚集索引的更多信息。

Pawnshop Application (any RDBMS):

one-to-many relationship where each customer (master) can have many transactions (detail).

Several people have told me this is not the correct way to join master to detail. They said I should always join customer.id[serial] to transactions.id[integer].

When a customer pawns merchandise, clerk queries the master using wildcards on name. The query usually returns several customers, clerk scrolls until locating the right name, enters a 'D' to change to detail transactions table, all transactions are automatically queried, then clerk enters an 'A' to add a new transaction.

The problem with using customer.id joining transaction.id is that although the customer table is maintained in sorted name order, clustering the transaction table by fk_id groups the transactions by fk_id, but they are not in the same order as the customer name, so when clerk is scrolling through customer names in the master, the system has to jump allover the place to locate the clustered transactions belonging to each customer. As each new customer is added, the next id is assigned to that customer, but new customers dont show up in alphabetical order. I experimented using id joins and confirmed the decrease in performance.

The drawbacks of using name joins vs. id joins is if you change customer name, the join with their transactions is severed, so I dont allow updating the name. Anyway, how often does one need to change a customers name? The other draw back is name requires 30 chars where id is INT, so .dat and .idx are larger. Every morning an sql proc is executed which unloads customer and transactions in sorted name order, drops/re-creates the tables, loads the unloaded data and all indexes are re-created which keeps performance optimized.

How can I use id joins instead of name joins and still preserve the clustered transaction order by name if transactions has no name column?

The following is an example of how the data sits in customer.dat and transactions.dat when using pk/fk name, as described in the above schema:

So, when clerk wilcard queries by customer master name, customers transactions are automatically queried and quickly displayed when clerk scrolls thru names returned into the current list since they are in the same sorted order as the master.

Now, the following example is the same data using pk/fk id:

OK, so now keep in mind that my perform 1-page screen includes all customer columns and all transactions columns, and there's a master/detail instruction which when the clerk queries by customer name, the first transaction row belonging to that customer is automatically displayed. Then the clerk will press 'D' to make transactions the active table and press 'A' to add a new transaction, or clerk may scroll through all the customers transactions to update one in particular or just provide customer with info.

When using the pk/fk name method, as the clerk scrolls through customer names to locate the desired customer, response is immediate. Whereas when using the pk/fk id method, response time lags, even with supported indexing, because the engine has to jump to different locations in the transactions table to locate the corresponding group of transactions belonging to each customer as clerk scrolls through each customer name in the master!

So, it seems like having the customer's transaction rows grouped together and in the same sorted order as the customer rows allows the indexing to locate the transactions quicker as opposed to having to jump all over scattered groups of each customers transactions. If each customer could remember their customer i.d. number, then my issue would be academic, but in the realworld, we even gave each customer an i.d. card with their customer number on it, but most of them lost their cards!

Here's an example of the daily reorg executed every morning before pawnshop opens for business:

If you have time, I CHALLENGE ANYONE TO TEST THIS!.. It's more noticeable when you have a large table.

我正在尝试将不是 id 的属性定义为 nhibernate 中的聚集索引，但我没有找到这样做的方法。

谁能给我一个关于这是如何完成的指针，或者它是目前在 nhibernate 中不可用的东西？

提前致谢

如果我要通过 Guids 查询表（不管 Guids 的碎片问题），将 Guid 作为聚集索引而不是非聚集索引或根本没有索引会更快吗？

这个问题来自只读的角度。我只是好奇特定 Guid 的搜索行之间的速度是否会有所提高，并且在有/没有索引或有/没有聚集索引的情况下会更快地完成搜索吗？

或者，我对下一个问题的答案相当肯定，但现在将 int 标识符应用于上一个问题。如果该表由该 int 聚集，搜索会更快吗？（这是不是被表中的其他项目聚集在一起？）

我知道在这个主题上发布了许多其他问题，但我还没有在其中找到我正在寻找的具体答案：
Sequential Guid 主键列是否应该是聚集索引？
提高集群索引 GUID 主键的性能SQL Server uniqueidentifier
中唯一标识符 ID 列上的集群主键和索引我应该摆脱 Guid 列上的集群索引吗

谢谢你的帮助！