SQL Server误区30日谈 第25天 有关填充因子的误区_MsSql

误区 #25:多个有关填充因子的误区
    都是错误的

25a) 填充因子是一直存在的
    不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话):
重要:
填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致。如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义。因为这时页即使不满也需要进行分页。

25 b)填充因子0和100是不同的
    错误,由BOL的一句话可以看到
    填充因子0和100在各个方面都是一个意思。

25 c)填充因子设置为0会在非叶子节点保留 空间
    这是错误的,这一点BOL上没有说,我也不知道这个误区从何而来,但这绝对是错误的。你可以通过如下代码证实这一点:

复制代码 代码如下:

CREATE DATABASE foo;
GO
USE foo;
GO
CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (1000) DEFAULT 'a');
CREATE CLUSTERED INDEX t1c1 ON t1 (c1);
GO
SET NOCOUNT ON;
GO
INSERT INTO t1 DEFAULT VALUES;
GO 10000

接下来设置填充因子为0并重建索引

复制代码 代码如下:

SELECT [fill_factor] FROM sys.indexes
WHERE NAME = 't1c1' AND [object_id] = OBJECT_ID ('t1');
GO
ALTER INDEX t1c1 ON t1 REBUILD WITH (FILLFACTOR = 100);
GO

上面的代码执行后,通过查看既定页中的m_freeCnt列的值,也就是页中可用空间的值:

复制代码 代码如下:

EXEC sp_allocationMetadata 't1';
GO
DBCC TRACEON (3604);
DBCC PAGE (foo, 1, 164, 3); -- the root page, from the SP output
GO
DBCC PAGE (foo, 1, 162, 1); -- the page ID in the DBCC PAGE output above
GO

通过上面代码可以看到值为10,也就是说业内不存在保留空间。这时一个误区,有关上面sp_allocationMetadata的实现细节请看这篇博文:this blog post。

时间: 2024-08-07 14:30:43

SQL Server误区30日谈 第25天 有关填充因子的误区_MsSql的相关文章

SQL Server误区30日谈 第25天 有关填充因子的误区

误区 #25:多个有关填充因子的误区     都是错误的 25a) 填充因子是一直存在的     不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话): 重要: 填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致.如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义.因为这时页即使不满也需要进行分页. 25 b)填充因子0和100是不同的     错误,由BOL的一句话可以看到     

SQL Server误区30日谈 第17天 有关页校验和的误区_MsSql

其实我之前已经有文章详细解释了页校验和:How to tell if the IO subsystem is causing corruptions? 误区 #17:几个有关页校验和的误区 坊间流传的基本是错误的   17 a)页校验和(Page CheckSum)在从SQL Server 2000或7.0升级上来之后自动开启     其实不是,从旧的实例升级上来的数据库不会自动开启页校验和,除非你显式使用ALTER DATABASE databasename SET PAGE_VERIFY C

SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞_MsSql

误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的!     在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-..     在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重

SQL Server误区30日谈 第16天 数据的损坏和修复_MsSql

误区 #16:多个关于数据的损坏和修复误区 坊间流传的很多版本都不正确 我已经听过很多关于数据修复可以做什么.不可以做什么.什么会导致数据损坏以及损坏是否可以自行消失.其实我已经针对这类问题写过多篇博文,因此本篇博文可以作为"流言终结者"来做一个总结,希望你能有收获.   首先,对于数据修复可以做什么,不可以做什么,我已经写过一篇博文Misconceptions around database repair涵盖了13个误区-从不用DBCC CHECKDB是否能修复错误(当然不能)到RE

SQL Server误区30日谈 第23天 有关锁升级的误区_MsSql

误区 #23: 锁升级的过程是由行锁升级到页锁,再由页锁升级到表锁错误    实际不是,在SQL Server 2005和之前的版本,页锁会直接升级到表锁.    在SQL Server 2005或SQL Server 2008,你可以通过如下跟踪标志改变锁升级的行为: 标志1211-完全禁止锁升级,但锁使用的内存会被限制在动态分配内存的60%,当超过这个值时,更多的锁将会伴随着内存溢出错误而失败. 标志1224-禁止锁升级,但内存使用超过40%时,会自动开启锁升级     如果标志1211和1

SQL Server误区30日谈 第29天 有关堆碎片的误区

误区 #29:可以通过对堆建聚集索引再DROP后进行堆上的碎片整理 Nooooooooooooo!!! 对堆建聚集索引再DROP在我看来是除了收缩数据库之外最2的事了.      如果你通过sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片,绝对不要通过建立聚集索引再删除聚集索引来整理堆碎片.好的做法应该是建立聚集索引之后不再删除,已经有非常多的资料阐述如何选择一个理想的聚集索引键--窄,很少变动,唯一,自增.Kimberly

SQL Server误区30日谈 第23天 有关锁升级的误区

误区 #23: 锁升级的过程是由行锁升级到页锁,再由页锁升级到表锁 错误     实际不是,在SQL Server 2005和之前的版本,页锁会直接升级到表锁.     在SQL Server 2005或SQL Server 2008,你可以通过如下跟踪标志改变锁升级的行为: 标志1211-完全禁止锁升级,但锁使用的内存会被限制在动态分配内存的60%,当超过这个值时,更多的锁将会伴随着内存溢出错误而失败. 标志1224-禁止锁升级,但内存使用超过40%时,会自动开启锁升级     如果标志121

SQL Server误区30日谈 第17天 有关页校验和的误区

其实我之前已经有文章详细解释了页校验和:How to tell if the IO subsystem is causing corruptions? 误区 #17:几个有关页校验和的误区 坊间流传的基本是错误的 17 a)页校验和(Page CheckSum)在从SQL Server 2000或7.0升级上来之后自动开启 其实不是,从旧的实例升级上来的数据库不会自动开启页校验和,除非你显式使用ALTER DATABASE databasename SET PAGE_VERIFY CHECKSU

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢