标签: clustered-index

关于包含列的非聚集索引的问题 (DB - MS SQL Server)。我阅读了博客优化的非聚集索引维护，其中提供了有关执行更新语句以及为表定义聚集索引和非聚集索引时的查询计划的信息。
我对包含列的非聚集索引有疑问。我指的是博主提供的相同示例

CREATE TABLE T (PK INT, A INT, B INT, C INT, D INT, E INT)
CREATE UNIQUE CLUSTERED INDEX TPK ON T(PK)

CREATE INDEX TB ON T(B)
CREATE INDEX TCD ON T(C,D)
CREATE INDEX TE ON T(E)

-- 这是包含列的新非聚集索引

CREATE INDEX TF ON T(E) INCLUDE(A)


INSERT T VALUES(0, 10, 20, 30, 40, 50)

UPDATE T SET A = 19

如果未定义索引 TF，则只会执行对聚集索引的更新，不会执行非聚集索引插入和删除操作。但是当定义了 TF 时会发生什么？

这是主键中指定的排序顺序的衍生问题，但排序是在 SELECT 上执行的。

@Catcall关于存储顺序（聚集索引）和输出顺序的主题

很多人认为聚集索引可以保证输出的排序顺序。但这不是它的作用。它保证了磁盘上的存储顺序。 例如，请参阅此博客文章。

我已经阅读了 Hugo Kornelis 的博客文章，并了解到索引并不能保证 sql server 以特定顺序读取记录。然而，我很难接受我不能为我的场景假设这一点？

CREATE TABLE [dbo].[SensorValues](
  [DeviceId] [int] NOT NULL,
  [SensorId] [int] NOT NULL,
  [SensorValue] [int] NOT NULL,
  [Date] [int] NOT NULL,
CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED 
(
  [DeviceId] ASC,
  [SensorId] ASC,
  [Date] DESC
) WITH (
    FILLFACTOR=75,
    DATA_COMPRESSION = PAGE,
    PAD_INDEX = OFF,
    STATISTICS_NORECOMPUTE = OFF,
    SORT_IN_TEMPDB = OFF,
    IGNORE_DUP_KEY = OFF,
    ONLINE = OFF,
    ALLOW_ROW_LOCKS = ON,
    ALLOW_PAGE_LOCKS = ON)
  ON …

我有一张大表，表的行数超过30亿，这张表的数据空间大约是120GB。

和 Intel Xeon CPU E5645 @2.4GHz（2 个处理器），24 个 CPU，64G 内存，64 位 Windows Server 2008 R2 企业版。

我跑

create unique clustered index MyTable_IXC on tblFactFoo(barKey) on [PRIMARY]

但是用了6个多小时（实际上是6小时后报了duplicate key的错误）。

运行的时候cpu不到10%，磁盘IO不到20M/s，一般在15M/s左右，不知道这么强大的硬件如何提高创建聚簇索引的性能。

我在这里得到了聚集索引和唯一索引之间的区别。但是clustered index和之间的确切区别是unique-clustered index什么？

AFAIK 可以为具有唯一值的列创建聚集索引，如果值重复，则无法设置聚集索引。唯一聚集索引的情况也是如此。

所以我想知道它们之间的区别。

我有一个包含一些日志信息的大数据库（200GB+）。我想加快SELECT查询和存储过程。我有一个带有GeneratedOnUtc 日期时间列的表，并且上面有一个非聚集索引。

我正在考虑将其更改为聚集索引。

的原因：

• 大量数据（约 4000 万行）

• Column 用于多个Where子句 ( between, >, <)

• 列用于ROW_NUMBER() OVER (ORDER BY d.GeneratedOnUtc asc) AS Row查询

反对理由：

• 大量插入（每天约 60k）可能会导致频繁的 B 树重建。

假设我有一个 1 对 N 的关系(person_id, pet_id)。我有一张表，pet_id主键在哪里。

我知道 InnoDB 二级索引本质上是一个 B 树，其中值是行的相应主键值。

现在，假设一个人可以拥有数千只宠物，而我通常希望一个人的宠物按pet_id. 那么，如果在第二个索引记录的排序会的问题(person_id, pet_id)或只是person_id用pet_id的该person_id是无序。猜到后来。

那么，如果person_id是非唯一的，记录是按物理排序(person_id, pet_id)还是仅排序pet_id？

谢谢

我有一个大约有 1.500.000 行的日志记录表，主键是一个升序标识，聚集索引在主键上。标识值是自动生成的 => 记录总是添加在最后。平均行大小为 1570 字节。

由于频繁添加新行，因此有很多页面拆分。没有行被更新/删除，并且表上有一个非聚集索引，因此可以选择行。由于页面拆分，聚集索引总是碎片化 > 65%。

我想知道我的表是否会因删除聚集索引并使其成为堆表而受益？

这是我的表 + 非聚集索引的样子：

CREATE TABLE [dbo].[LogEntry](
[Id] [bigint] IDENTITY(1,1) NOT NULL,
[Application] [varchar](20) NOT NULL,
[EntityFullName] [varchar](80) NOT NULL,
[Action] [int] NOT NULL,
[UserName] [varchar](25) NOT NULL,
[TimeStamp] [datetime] NOT NULL,
[EntityId] [varchar](50) NOT NULL,
[WhatChanged] [nvarchar](max) NULL,
CONSTRAINT [PK_LogEntry] PRIMARY KEY CLUSTERED(     
   [Id] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100) ON [PRIMARY] ) 
ON [PRIMARY] …

BOL 似乎将堆定义为没有聚集索引的表。

但是许多在线帖子似乎将堆等同于没有任何索引的表。

有什么我不知道的微妙之处吗？

谢谢

问题与this one类似，但答案似乎没有回答这个问题。

我对聚集列存储表的理解（如果我错了，请纠正我）是每列都以某种物理排序的方式存储，这意味着每列已经有相当于聚集索引的内容。如果是这种情况，那么在表上添加更多索引就没有多大意义了……或者是吗？也许是一个综合指数？

我的想法是否正确？

我有一个相对较大的表（对我来说）有 4000 万行，预计在两周内（在活动期间）会增长到 80 到 1.2 亿行。

Tip
--------------
Id          int (clustered index)
UserId      int
TipIndex    smallint
Value       binary(8)
LastChanged datetime2(3)

• 每个用户都有 1 到 400 个提示，这些提示将在此期间随机插入
• UserId + TipIndex 是唯一的
• 我从不直接在身份密钥 (Id) 上查询 Tips
• 我查询 UserId 的次数有 99%
• 我需要所有列
• 我经常查询 1 个 UserId（每个页面视图），有时查询 10.000 个批次的统计信息
• 这是在此期间的高流量站点，它应该能够每分钟处理 30.000 次 UserId 查询
• Id 目前是我的聚集索引，因为我读到它导致最少的碎片化。

所以我托管在 SQL Azure 上，Azure 已经建议添加一个包含列的索引。我总是犹豫是否使用 UserId,TipIndex 作为聚集索引，因为 Tips 会随机添加。这意味着我害怕巨大的碎片问题等。

我的问题：

• 包含列的索引没有完全相同的问题吗？
• 包含列的表是否与具有相同碎片问题的“影子表”相同？
• 我应该迁移以使用 UserId、TipIndex 作为 ClusteredIndex 而不是 Id？
• 如何防止碎片化？

我知道最终答案总是“取决于”或者我应该衡量它。但由于我是一名单独的开发人员并且没有很多资源，我希望有更多经验的人对此有直觉，所以我的第一次尝试有更高的机会朝着正确的方向前进。