请注意与文件组相关的一个重要行为。
使用OP的SQL脚本,您永远不能提到两个不同的文件组,即一个用于存储数据行,另一个用于索引数据结构。这是不允许的。
原因是在此情况下创建的索引是基于表的主键的聚集索引。聚集索引的元数据和表的数据行永远不能存储在两个不同的文件组中。
我的数据库有两个文件组:
- PRIMARY
- SECONDARY
现在,看一下下面的脚本,并通过SQL Server Management Studio(SSMS)执行它。接下来将会发生我们意料之外的事情。
即使我已经指定了一个不同的文件组([SECONDARY])来存储表的行数据,它仍将表的行数据以及与聚集索引相关的元数据都存储在PRIMARY文件组上。我故意编写了这样的脚本来测试这种行为:
CREATE TABLE [dbo].[be_Categories](
[CategoryID] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_be_Categories_CategoryID] DEFAULT (newid()),
[CategoryName] [nvarchar](50) NULL,
[Description] [nvarchar](200) NULL,
[ParentID] [uniqueidentifier] NULL,
CONSTRAINT [PK_be_Categories] PRIMARY KEY CLUSTERED
(
[CategoryID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [SECONDARY]
GO
有趣的是,上述脚本在没有任何错误的情况下运行结束。坦白地说,我原本期望出现运行时错误,因为我给出了两个不同的文件组。SQL Server在幕后默默地完成了这个技巧,而不会抛出任何错误。
注意:对于非聚集索引,索引可以存储在不同的文件组中。
下面显示的SQL脚本创建了一个非聚集索引。非聚集索引将在[SECONDARY]文件组上创建,而表的数据行将驻留在[PRIMARY]文件组中:
CREATE NONCLUSTERED INDEX [IX_Categories] ON [dbo].[be_Categories]
(
[CategoryName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [Secondary]
GO
您可以在这里了解更多信息,了解如何将非聚集索引存储在不同的文件组上,从而提高查询性能。
0
或false
是为了确保代码处于已知状态,这是逻辑和正确性方面的考虑,而不是优化方面的考虑。 - jpmc26