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