擦亮自己的眼睛去看SQLServer之简单Insert(转)
摘要:本来是打算先写SQLServer历史的,不过感觉写那部分内容比较难还需要多查些资料。于是调整了下顺序写下简单的Insert语句。
不过感觉写那部分内容比较难还需要多查些资料。于是调整了下顺序写下简单的Insert语句。数据库结构还是采用上一篇的结构。具体查看上一篇文章《擦亮自己的眼睛去看SQL Server之简单Select》。今天讨论的语句也比较简单,Insert语句。
一、Insert脚本
没什么好说的,因为想写这样的语句太简单。
二、 语句分析
这条语句到底发生了什么呢?假设读者已经知道了SQL Server整体架构或者已经阅读过这个系列第一篇文章。当这条语句被可靠的传递到关系引擎中后已经生成执行计划,并且开始被调度执行。接下来就发生了:
写事务日志: 数据修改事务中唯一一个总是需要写入磁盘的操作。并不是修改查询语句的清单,而是修改操作发生之后数据页面的具体变化。是由日志管理器完成。看到写入磁 盘,我们应该立刻联想到性能问题,因为这个操作是总是写入磁盘。如果一条语句的操作的数据很大的话,这个耗时是十分可怕的。
举个例子:如果想知道这个差距,你可以在百万或者千万的表中执行以下两条语句体会以下:truncate table Test以及delete from Test。当然严谨的同学会说truncate是针对区操作,delete是针对页操作,truncate的锁消耗也比delete的锁消耗少。这些是会 导致truncate比delete快的原因。但是这些原因不是主要原因,主要原因就是这里说的写事务日志,delete是每次删除一行,并在事务日志中 为所删除的每行记录一项,而truncate是通过释放存储表数据所用的数据页来删除数据,并且只在事务日志中记录页的释放。既然事务日志会影响性能,为 什么还记录呢?主要解决保护数据以及数据一致性的问题。
接收写请求: 一旦访问方法接收到写事务日志成功的确认信息,就会接收写请求,将写请求发送缓存区管理器。注意了,这里是把请求交给缓存区管理器,缓存区管理器只是操作 缓存跟物理文件没有任何关系。这里强调的目的是,如果没有理解这里说的原理的话。你可能会为自己做了大量的插入操作,而数据文件的大小没有任何变化而感到 匪夷所思。访问方法表面上起了请求传递的作用,其实它很智能,有一些比较复杂的算法来预测执行情况。
插入缓冲池:缓冲区管理器在内存中插入数据,插入成功后将确认结果发送给访问方法,最终确认结果到达客户端。
写入数据文件: 这个步骤可以由两个组件任何一个完成。惰性写入器线程定期检查SQL Server空闲缓冲列表的大小,当这个值过低的时候,惰性写入器会扫描整个数据缓存,将所有一段时间没被使用的页面老化。如果找到一段时间没有被使用的 脏页,惰性写入器则将其写入磁盘并且删除,然后将这个页面的内存空间标记为空闲空间。惰性写入器还会监测服务器上的空闲物理内存,如果内存很少它会将 SQL Server的空闲缓冲列表释放给Windows,在SQL Server负载很重时,它还会在服务器有空闲物理内存且已给SQL Server分配的内存还没有达到我们配置的最大服务器内存(max server memory)时增加SQL Server的空闲缓冲列表以适应负载。
检查点是检查点线程创建的一个时间点,将保证脏页都写入磁盘,并且在页面头将缓存中的这个页面标记为干净的页面,注意检查点是不删除脏页的。至于检查点 的执行时间是要分几种情况的:如果你配置了recovery interval(min),就以这个为准。如果没有配置,并且这上一次检查点结束后写入的事务日志数据超过10MB,则大约每分钟启动一次。还比如,我 们人为执行checkpoint执行,或者执行备份重启命令都会触发检查点。抛开我们人为操作,这个具体时间确实无法确定,SQL Server有内部启发算法控制这个值。不过我们可以开启一个跟踪标志3502能查看。这个跟踪标志在错误日志中记录了检查点的开始与结束为止。sql语句为:dbcc traceon(3502) 。
三、结尾
今天主要就是介绍了插入语句的执行过程,内容不多。你从这个过程中你会发现SQL Server真的很智能。比如这里的预写日志来保护数据,延迟将数据写入磁盘、预测SQL执行情况、监控负载调整内存等等。设计的都是那么巧妙,大家可以 想想如果我们在设计自己的软件时是否可以参考和借鉴呢?
今天分析就到此结束,文中如有描述不当的地方,欢迎指出。共同进步才是硬道理。