标签: clustered-index

我将从一个非常简单的例子开始：两个表，都具有相同的架构，聚集在 PK 上，但其中一个有一个INSTEAD OF UPDATE触发器：

CREATE TABLE Standard
(
    PK  UNIQUEIDENTIFIER PRIMARY KEY CLUSTERED,
    V   INT NOT NULL
)
GO

CREATE TABLE InsteadOf
(
    PK  UNIQUEIDENTIFIER PRIMARY KEY CLUSTERED,
    V   INT NOT NULL
)
GO

INSERT Standard (PK, V) VALUES ('1E58B555-B073-471E-B576-4B09C8E18976', 0)
INSERT InsteadOf (PK, V) VALUES ('1E58B555-B073-471E-B576-4B09C8E18976', 0)
GO

CREATE TRIGGER TR_InsteadOf_Update ON InsteadOf INSTEAD OF UPDATE
AS
BEGIN
    DECLARE @PK UNIQUEIDENTIFIER
    DECLARE @V INT
    DECLARE @cursor CURSOR
    SET @cursor = CURSOR FOR SELECT PK, V FROM …

当我们对一个表的聚集索引进行重建时，该表中有大约 15GB 的数据并且数据大小缩小到 5GB，这怎么可能？删除了什么样的“数据”？

数据大小我指的是 DBCC sp_spaceused 的“数据”列

在聚集索引上重建之前：

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    39169656 KB 15857960 KB 22916496 KB 395200 KB

Run Code Online (Sandbox Code Playgroud)

---

在聚集索引上重建后：

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    29076736 KB 5867048 KB  22880144 KB 329544 KB

Run Code Online (Sandbox Code Playgroud)

用于重建的 TSQL：

USE [DAX5TEST]
GO
ALTER INDEX [I_212RECID] ON [dbo].[LEDGERJOURNALTRANS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = OFF, DATA_COMPRESSION = PAGE, FILLFACTOR …

运行以下脚本时出现错误；

IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES 
  WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME='Table_Name')
BEGIN
CREATE TABLE Table_Name
(
    Field_Name_1 binary(32) NOT NULL CONSTRAINT PK_Name_Goes_Here PRIMARY KEY NONCLUSTERED
    , Field_Name_2 int NOT NULL 
    , Field_Name_3 datetime NOT NULL INDEX IX_Name_Goes_Here CLUSTERED
)
END 

特别是它的聚集索引创建抛出以下错误：

消息 1018，级别 15，状态 1，第 15 行
“INDEX”附近的语法不正确。如果这是作为表提示的一部分，现在需要 WITH 关键字和括号。有关正确的语法，请参阅 SQL Server 联机丛书。

这很奇怪，因为它适用于我们所有的服务器，除了特定的 QA 服务器。我们采取的修复措施是在表创建语句之外创建聚集索引，但如果有人以前遇到过这个问题，我会感兴趣吗？

需要知道 PostgreSQL 如何在磁盘上订购记录。在这种情况下，我想利用文档中所述的索引组合，据我所知，它使用位图来获取匹配的行并根据它们的物理位置返回它们。有问题的表已按其主键聚集在一起。

据我了解，在集群完成后，PostgreSQL 不会自动继续进行集群（尽管它确实记得它是根据某个索引进行集群的）。现在，由于这是主键，我想知道物理存储顺序是否会根据它（如果是真的，我想利用我们的优势来进行特定查询）。

综上所述，PostgreSQL 如何对其新记录进行排序，尤其是在聚类之后？

非常感谢！

我将以下交叉引用表添加到我的 SQL Server 托管的数据库中：

company_id bigint not null (FK)
org_path nvarchar (2048) not null

该company_id字段是指id另一个表中的字段（它是主键）。

鉴于也可以有多条记录具有相同的company_id，任何主键都必须使用这两个字段。但是，我无法使用这两个字段创建密钥，因为org_path对于 SQL Server 来说太长了。

至于org_path，这是它存在的唯一表。对该表的查询很可能会要求所有条目或所有org_path条目company_id。或者换句话说，这个表是否会被 查询，这看起来令人怀疑org_path。此外，不太可能org_path会更新，更有可能插入和 - 可能很少 - 删除。

我预计总行数将在数千个以内。

此外，这nvarchar (2048)是因为该值必须模仿第三方数据库中的值。一个典型的例子是这样的

\Translation Providers\[customer name]\[order name]\

并且可以包含变音符号。

所以我的问题是：添加一个自动增量id字段并将其与company_id主键结合使用会更有效，还是会增加不必要的开销 -company_id另一个表中的主键这一事实是否有任何影响？效果在这里？

我有一个开发人员希望在执行没有 order by 的 select 语句时，表中的行按照它们插入的顺序排列。开发人员建议从聚集索引更改为非聚集索引。

通过将索引从聚簇更改为非聚簇，这是否可以保证行在表中出现的顺序？

这个问题主要是为了我的好奇心；我将建议改用身份列，但这个请求让我开始思考。可以使用时间戳，但有可能同时插入行。

在此先感谢您的帮助。

我想在我拥有的 SQL Server 2017 测试数据库上故意创建坏索引条件，只是为了更好地理解这些维护脚本？SQL Server 索引和统计维护

是否有一种快速/自动的方法来破坏索引完整性或增加索引碎片？您知道我可以查看哪些有用的资源来实现这一目标吗？

我有一个包含一些日志信息的大数据库（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？

谢谢

我有一个堆表，它占用大约 104 GB 的磁盘空间，几乎有 30 亿行。我正在尝试在 [ WeekEndingDate] 列上的该表上创建聚集索引。我在数据文件中有大约 200 gb 的空闲空间，在 tempdb 中有大约 280 gb 的空闲空间。

我尝试了两种不同的方法。首先是使用以下命令直接在表上创建索引：

CREATE CLUSTERED INDEX CX_WT_FOLD_HISTORY
ON WT_FOLD_HISTORY (WeekEndingDate ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = ON, 
IGNORE_DUP_KEY = OFF
, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, 
DATA_COMPRESSION = PAGE)

我用SORT_IN_TEMPDB = ON和都试过了OFF。使用时ON它填满了 tempdb 并用OFF它填满了数据驱动器。

另一种方法是创建一个具有所需索引的新空白表，然后将堆中的记录插入到新表中。这在填充数据驱动器后也失败了。

关于做什么的任何其他建议。我读过的大多数内容都表明，在创建索引时，我需要大约 1.2 倍的表大小才能用作工作区。我有更多的方法，但它仍然失败。任何建议，将不胜感激。

这是我原来的堆表结构：

CREATE TABLE [dbo].[WT_FOLD_HISTORY](
[WeekEndingDate] [varchar](50) NULL,
[Division] [varchar](50) NULL, …