问题标签 [clustered-index]

我在 H2 中创建下表：

然后我查看 INFORMATION_SCHEMA.TABLES 表：

结果：

然后我查看 INFORMATION_SCHEMA.CONSTRAINTS 表：

结果：

这些语句不是我所说的，因此，问题是：TABLES 和 CONSTRAINS 中的信息是否反映了在数据库中执行的真实 SQL？

1. 在原始 CREATE TABLE 语句中没有CACHED字。（不是问题）
2. 我从未执行过ALTER TABLE .. ADD CONSTRAINT语句。

我问这个问题的实际原因是我不确定应该执行哪个语句来保证在聚集索引中使用主键。如果您查看我之前的问题H2 数据库：聚集索引支持，那么您可能会在 Thomas Mueller 的回答中找到以下语句：

如果在创建表之后创建主键，则主键存储在新的索引 b-tree 中。

因此，如果语句按照它们显示在 INFORMATION_SCHEMA 中的方式执行，则在创建表后创建主键，因此在聚集索引中不使用 ID（基本上作为数据 b 树中的键）。

有没有一种方法可以保证在 H2 的聚集索引中使用主键？

我想创建一个类似的带注释的类：

在这个类中，我想创建一个 Id 列作为聚集索引。注释或休眠是否有可能？

IMO, please correct me...
the leaf of clustered index contains the real table row, so full clustered index, with intermediate leaves, contain much more data than the full table(?)
Why/when/how is ever whole clustered index scan chosen over the full table scan?

How is clustered index on CUSTOMER_ID column used in SELECT query which does not contain it in either SELECT list or in WHERE condition [1]?

Update:
Should I understand that full clustered scan is faster than full table scan because "Each data page contains pointers to the next and previous leaf node page so the scan does not need to use the higher level pages in the index"?
Are there any other reasons like (non-participating in query) clustered index is used in sorting?

Update2:
As afterthought, consecutive access cannot give performance boost while loading table through IAM pointers can be parallelized.
Does clustered index scan imply consecutive page reading?
Does clustered table imply absence of IAM pointers (impossibility of full table scan)?
Why cannot clustered table be full table scanned?
I still do not understand how/why clustered index full scan can be "better" over full table scan.
Does it mean that having clustered index can result in performance worsening?

The question is about clustered table not heap (non-indexed) table.

Update3:
Is "full clustered index scan" really synonym to "full table scan"?
What are differences?

[1] Index Covering Boosts SQL Server Query Performance
http://www.devx.com/dbzone/Article/29530

我继承了一些用于 SQL SERVER 2005 数据库的数据库创建脚本。

我注意到的一件事是所有主键都是作为NON CLUSTERED索引而不是集群创建的。

我知道每个表只能有一个聚集索引，并且您可能希望将它放在非主键列上以提高搜索的查询性能等。但是，有CLUSTERED问题的表上没有其他索引。

所以我的问题是除了上述之外，是否有任何技术原因不在主键列上使用聚集索引。

我对 SQL 还很陌生，我正在尝试研究如何在 postgres 中加速复杂的 SQL 查询，也许是通过改进我对索引的使用。这是查询：

这基本上是数据库模式（在 Pylons 中定义）：

它的索引如下：

我是否缺少任何可以加快查询速度的明显索引？尤其是：

• 我应该使用“聚集”索引吗？
• 我也应该amount对进行索引entry，还是对 没有影响SUM(t.amount) as amount？

谢谢你的帮助。我知道这是一个非常复杂的问题，所以请告诉我是否可以做些什么来改进它。

- - - 更新 - - - - - - -

EXPLAIN ANALYZE对上述查询的输出。

对问题“如何减少简单选择查询的响应时间？”的评论 告诉：

• “LaunchDate 上的数据类型是什么？如果是 DATETIME 或 DATETIME2，索引不太可能做太多事情，因为它们包含时间部分 – OMG Ponies”

• “@OMG - 为什么 DateTime 列上的聚集索引不能提高性能？查询是一个范围扫描，它允许快速范围索引查找，因为所有数据都在顺序块中？半相关...msdn。 microsoft.com/en-us/library/ms177416.aspx – 卡尔加里编码器”

• “Calgary Coder：DATETIME/2 包括时间——一个索引，无论是集群还是非集群，都适用于具有重复时间但不包括范围的日期。- OMG Ponies”

DATETIME我在类型列上创建了一个带有聚集索引的测试表，LaunchDate并观察索引搜索类似于上述问题中引用的查询：

而不是表或索引扫描。

为什么DateTime列上的聚集索引不能提高性能？如果索引或因为它们包含时间部分，
为什么索引可能不会做很多事情？DATETIMEDATETIME2

我很欣赏说明DATETIME列索引不会提高性能的脚本。

更新：另外，OMG 是否暗示DATEtype 列上的索引会有所帮助，但不是DATETIME吗DATETIME2？

我是 SQL Server 2005 的初学者，我正在从在线教程中学习它，这是我的一些问题：

1：Select * from XYZ 和 Select ALL * from XYZ 有什么区别。

2：聚集索引的目的是通过对表进行物理排序来使搜索更容易[据我所知:-)]。假设表上有主列而不是在表上创建聚集索引好吗？因为我们已经有一个已排序的列。

3：为什么我们可以在一张表上创建1个聚集索引+249个非聚集索引=250个索引？我了解 1 个聚集索引的要求。但是为什么是249？？为什么不超过 249？

如果聚集索引不是唯一的会发生什么？它会因为插入的行流向某种“溢出”页面而导致性能下降吗？

它是“制造”独特的吗？如果是，如何？让它独一无二的最佳方法是什么？

我之所以问是因为我目前正在使用聚集索引将表划分为逻辑部分，但性能一般，最近我得到了使聚集索引唯一的建议。我想对此发表第二意见。

我在 SQL Server 数据库中有一个相当独特的表，它不遵循“典型”使用约定，并且正在寻找有关聚簇索引的一些建议。

这是一个虚构的例子，但非常接近真实数据。

该表有一个 3 列的主键，它们实际上是其他表的外键，以及包含相关数据的第四个字段。对于此示例，假设表如下所示：

所以，我们有一个有点分层的主键，唯一的数据是第四个字段。

在实际应用中，总共有 28 亿条可能的记录，但仅此而已。这些记录是随着时间的推移计算数据而动态创建的，实际上可能只有 1/4 的记录会被实际计算。它们存储在数据库中，因为计算是一项昂贵的操作，我们只想为每个唯一组合执行一次。

今天，数据每分钟被读取数千次，但是（至少目前）随着表自身的填充，每分钟也有数百次插入（这将持续相当长的一段时间）。我会说每个插入（今天）有 10 次读取。

我想知道我们是否因为聚集索引而对所有这些插入进行了性能打击。

聚集索引“长期”是有意义的，因为该表最终将变为只读，但需要一些时间才能到达那里。

我想我可以在繁重的插入期间使索引不聚集，并在表填充时将其更改为聚集，但是您如何确定交叉点何时会出现（以及将来如何通知自己'时间到了'）？

我真正需要的是一个可转换的索引，它可以在未来某个神奇的时刻从非聚集变为聚集。

关于如何处理这个问题的任何建议？

我最近得到了建议，我应该将所有表从使用堆索引转换为每个表都有一个聚集索引。采用这种策略的后果是什么？例如，定期重组数据库更重要吗？数据增长？插入速度很慢的危险？如果 PK 是 GUID，页面碎片整理的危险？我的应用程序的显着速度增加？ 你有什么经验？

为了作为获得好的答案的灵感，以下是我从 stackoverflow 上的其他线程中收集到的一些“事实”

1. 几乎可以肯定要在数据库中的每个表上建立聚集索引。如果一张桌子没有。大多数常见查询的性能更好。
2. 聚集索引在 GUID 上并不总是坏事……这完全取决于您的应用程序的需求。INSERT 速度会受到影响，但 SELECT 速度会有所提高。
3. GUID 字段中的聚集索引的问题在于 GUID 是随机的，因此当插入新记录时，必须移动磁盘上的大部分数据才能将记录插入到表的中间。
4. 在 GUID 有意义并通过将相关数据彼此靠近来提高性能的情况下，GUID 上的聚集索引是可以的http://randommadness.blogspot.com/2008/07/guids-and-clustered-indexes.html
5. 集群不会影响查找速度 - 一个唯一的非聚集索引应该可以完成这项工作。