擦亮自己的眼睛去看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执行情况、监控负载调整内存等等。设计的都是那么巧妙，大家可以想想如果我们在设计自己的软件时是否可以参考和借鉴呢？
今天分析就到此结束，文中如有描述不当的地方，欢迎指出。共同进步才是硬道理。
