扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:ghj1976 来源:CSDN 2008年2月11日
关键字: NewID() 索引 SQL Server
在SQL Server 2005 中新增了一个函数:newsequentialid(),MSDN 中对这个函数的描述如下:
在指定计算机上创建大于先前通过该函数生成的任何 GUID 的 GUID。
NEWSEQUENTIALID() 不能在查询中引用。
NEWSEQUENTIALID() 只能与 uniqueidentifier 类型表列上的 DEFAULT 约束一起使用。
这个函数的具体用法在下面这篇博客中已经有详细的描述了。
使用NEWSEQUENTIALID解决GUID聚集索引问题
http://www.cnblogs.com/Mirricle/archive/2007/08/15/856726.html
简单来说,newsequentialid 函数比起 newid 函数最大的好处是:
如果你在一个 UNIQUEIDENTIFIER 字段上建立索引,使用 newid 产生的新的值是不固定的,所以新的值导致索引B+树的变化是随机的。
而 newsequentialid 产生的新的值是有规律的,则索引B+树的变化是有规律的。有规律和无规律就会带来性能的改进。
上面是一个粗略的描述,下面是比较详细点的解释:
(我们这里解释的更详细一些,是为了让大家对索引的基础知识了解得更深入些。)
B+ 树不考虑层级变化,增加数据的情况分以下几种情况:
The insert algorithm for B+ Trees
Leaf Page Full |
Index Page FULL |
Action |
NO | NO | Place the record in sorted position in the appropriate leaf page |
YES | NO |
1. Split the leaf page |
YES | YES |
1. Split the leaf page. IF the next level index page is full, continue splitting the index pages. |
更多 B+ 树的算法请参看后面链接: http://www.sci.unich.it/~acciaro/bpiutrees.pdf
对于数据库的索引来说,上面情况中,第三种情况发生的概率很低,更多的是 1,2 这两种情况。
数据库中增加记录时,对索引的B+树的操作,其实就是对 左右叶子节点,上级节点的操作。
而找到这几个节点后的操作,在实际上,都不是性能消耗最大的地方。性能消耗最大的地方在于搜索找到需要操作的叶子节点。
对于 B+ 树来说, 几层的B+ 树,找到叶子节点就需要找几个数据页。那为何说 Guid 有规律时速度要比无规律时候快呢?
原因很简单:
1、缓存的命中率问题
( 你可以参看我之前写的这篇博客:理解缓存 http://blog.joycode.com/ghj/archive/2007/09/01/107863.aspx )
当每次产生的Guid是有规律时,找到需要操作的叶子节点的几个中间节点,可能已经在之前的访问中被缓存了。
这样,系统不需要大量的读入缓存命中率很低的索引数据页,这样可以节省内存,同时提高搜索速度。
2、连续和不连续的磁盘 I/O 操作对性能的影响
我们都知道,现在很多业务逻辑的瓶颈是硬盘的速度。而硬盘速度提升的空间仍然不大。下面对硬盘读写操作的一些法则对我们优化跟硬盘I/O有关的方面很有帮助。
请记住下面的经验法则:标准的 Wide Ultra SCSI-3 硬盘每秒钟可为 Windows 和 SQL Server 提供 75 个不连续(随机)的 I/O 操作和 150 个连续的 I/O 操作。这种硬盘的标称传输率在 40 MB/秒左右。请记住更有可能限制数据库服务器的传输率是每秒钟 75/150 I/O,而不是 40 MB/秒。
读/写磁头和相关的磁盘取数臂需要移动才能在 SQL Server 和 Windows 所要求的硬盘盘片的位置上进行查找和操作。如果数据所在的硬盘盘片的位置不连续,硬盘驱动器要花多得多的时间才能将磁盘取数臂和读/写磁头移动到所有需要的硬盘盘片位置。如果所需要的数据全部位于硬盘盘片上的连续物理扇区,情况则相反,磁盘取数臂和读/写磁头只需进行很小的移动就能完成所需磁盘 I/O 操作。连续和不连续的情况下所花的时间有很大的差异,每个不连续的数据查找大约要花 50 毫秒,而连续的数据查找则只需大约 2-3 毫秒。请注意这些值是粗略估计出来的,具体值将取决于不连续的数据在磁盘上分布的疏密、硬盘盘片的旋转速度 (RPM) 以及硬盘的其它物理属性。主要要记住的一点是连续 I/O 有益于 SQL Server 性能。
之前已提到标准的硬盘支持每秒 75 个不连续的 I/O 和每秒 150 个连续的 I/O。还要记住的重要一点是读或写 8KB 的时间与读或写 64 KB的时间几乎相同。在 8 KB 到 64 KB 范围之内,单个磁盘 I/O 传输操作所花的时间主要是磁盘取数臂和读/写磁头运动的时间。因此,从数学上来讲,当需要传输 64 KB 以上的 SQL 数据时,尽可能地执行 64 KB 磁盘传输是有益的,因为 64 KB 传输基本上与 8 KB 传输一样快,而每次传输的 SQL Server 数据是 8 KB 传输的 8 倍。请记住 Read-Ahead Manager 以 64 KB 字节片(也称为 SQL Server 扩展盘区)执行磁盘操作。Log Manager 也以较大的 I/O 传输量来执行连续写操作。要记住的主要事项是充分利用 Read-Ahead Manager,并将 SQL Server 日志文件与其它非连续存取的文件分开,以有效提高 SQL Server 的性能。
查看本文来源
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者