通常对SQL Server的数据操作主要集中在查询和修改，其中，修改操作包含增删改等，而查询操作的出现频率，即使在修改操作相对频繁的系统中，也还是远高于修改操作。实际上，带有WHERE、FROM子句的增删改操作都是先进行查询再进行修改的。下面是一个简单的SELECT查询的运行过程。可以简单认为它只是：SELECT * FROM 一个表。
1．SNI
一个SELECT查询从客户端传入SQL Server，首先到达的地方是SQL Server 的网络接口，这个接口是一个建立在客户端和服务器之间的网络连接的协议层（SNI），包含了一系列用于连接数据库引擎和SQL Server Native Client（SNAC）的APIs。SNI替代了原有的SQL Server 2000中的网络库和MDAC（Microsoft Data Access Components），这部分需要在客户端和服务器上进行配置。在3.1节中曾提到，SQL Server总共有4种协议，这里对其中最常用的两种进行说明。
1）TCP/IP：最为广泛使用的协议，通过这种协议，可以使用特定的IP地址和端口连接SQL Server。默认情况下SQL Server的端口号是1433，而SQL Browser服务会使用UDP端口1434来查找命名实例。
2）Named Pipes：命名管道，为了局域网访问而开发的一个协议，在广域网中的速度不如TCP/IP。配置命名管道服务需要启动SQL Server 配置管理器，然后创建一个SQL Server别名，用于命名管道协议。命名管道使用TCP端口445来访问，所以使用这种协议需要确保这个端口的可连接性，特别是在防火墙配置中。
在整个SQL Server与外界交互的过程中，不管使用哪种网络连接协议，一旦连接建立，SNI就会创建一个安全的TDS端点到服务器上，用于接收和发送数据。
2．表格数据流端点
TDS现在是微软的专利，用于与数据库服务器交互。一旦建立连接，就会在服务器上创建一个TDS。SELECT语句会以TDS消息形式传输到SQL Server上。另外任何协议创建的端点都会有一个专用管理员连接（DAC）。
3．协议层
SQL Server的协议层在接收到TDS包后，就对其进行解压并分析包里面包含了什么请求。另外协议层也负责把SQL Server返回给客户端的数据打包成TDS包，通过SNI传输到客户端。当TDS包解压并分析成一个SQL命令后，就传入下一个组件——命令分析器中，如图3-3所示。
4．命令分析器
这个组件的任务是处理与T-SQL语言相关的事件。首先检查语法，如果发现有语法错误，就返回给客户端。如果没发现错误，下一步会产生执行计划或检查是否存在一个计划缓存。执行计划包含了执行一个查询所需的内部代码。前面提到过，计划缓存存在于Buffer Pool（缓冲池）中，如果在这一步找到已缓存的计划，就从计划缓存中读取，并传输给查询执行器执行。
在第8章中会提到，产生一个执行计划会消耗很多时间和资源，所以SQL Server会对一些特定查询的优化结果（也就是执行计划）进行缓存，以便重用（每个语句都有一个对应的sql_handle的hash值，用于标识这个查询，通过这个值可以得知这个查询和缓存中的查询是否是同一个或者是否可参数化），从而减少优化开销。而用于存放执行计划的地方就叫做计划缓存（Plan cache），这部分是缓冲池的一部分。如果存在对应的执行计划，就会重用，如果不存在，查询会被传送到查询优化器进行优化，如图3-4所示。
5．查询优化器
这个组件是SQL Server乃至所有关系数据库管理系统的核心。但是这部分的源码未公开，所以无法深入了解（在第5章有简要介绍）。SQL Server是基于开销的优化，通过一定的算法，分析特定的查询，产生多个（也有可能只有一个）候选执行计划，然后对比每个计划的开销，选出开销最小的计划作为最终执行计划。通常来说，开销最小的就是最佳的执行计划，但是也有可能由于某些因素的影响，使得优化器无法合理、准确地产生高效的执行计划，这部分在第5章“查询优化器”中详细介绍。
优化过程总共分3个阶段（在第5章还会介绍）。
1）阶段0——这个阶段不考虑并行操作，并且把关联全部当成Nested Loop来优化。如果计划的开销小于0.2，优化过程就会停止，并产生叫作TP（transaction processing）的执行计划。
2）阶段1——使用一定的规则，产生一定量的候选计划，当开销小于0.1，就会停止这个阶段的优化，然后产生叫作quick plans的执行计划。
3）阶段2——这是优化的最后一个阶段，会使用所有可能的方式去产生候选执行计划。
注意 SQL Server中的开销并不能简单地转换成以秒为单位的时间或者其他衡量标准，它仅是一个用于执行计划的衡量值，每个操作符都有一个基线开销，如果这个操作符需要运行多次，会使用这个基线开销乘以总共影响行数，最终得到预估操作符的开销。由于开销并不十分依赖于硬件，所以执行计划的开销情况相对稳定，但是开销和SQL Server的版本差异有关系。
以聚集索引扫描为例，在这个操作中，假设聚集索引的第一行的开销是0.0001234（这个值只是举例，并不是真正的值），聚集索引其他行的开销是0.0000011。再假设表中有100行，那么这个操作的预估开销就是：0.0001234+(100-1)×0.0000011 。当然，我们无法得知真正的数据，所以不用过于在意这个值是多少。
6．查询执行器
这个组件的工作很明显，就是执行查询，它通过与存储引擎进行交互来操作数据。查询执行器把执行计划通过OLE DB接口传给数据访问方法（Access Method），如图3-5所示。
7．数据访问方法
数据访问方法是一个关于数据和索引，以及如何操作这些对象的代码集合。它包含了所有操作数据的代码，但是它不实际执行这些代码，而是传送给缓冲区管理（Buffer Manager）。
8．缓冲区管理
缓冲区管理用于管理缓冲池，如果查询需要从一个页中读取数据，缓冲区管理会在缓冲池（Buffer Pool）的数据缓存（data cache）中检查是否存在这些数据。如果存在，就把结果返回给数据访问方法；如果不存在，缓冲区管理就需要把数据页从磁盘读入数据缓存中，然后把结果返回给访问方法。
除了重启或清空内存之后，数据必须经过这个步骤把数据加载到数据缓存之外，大部分数据库运行时间内应该保证最常用的数据能尽可能久地保存在数据缓存中，避免频繁地从磁盘加载数据到内存中。这个过程可能产生PAGEIOLATCH等待，对应的时间代表数据页从磁盘读入内存所需的时间。
9．数据缓存
数据缓存通常是占用缓冲池中最大的部分，所以也是内存中消耗最大的部分。可以使用sys.dm_os_buffer_descriptors这个DMV来检查当前每个数据库占用了多少数据缓存，代码如下：
SELECT COUNT(*) * 8 / 1024 AS 'Cached Size (MB)' ,
CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE DB_NAME(database_id)
END AS 'Database'
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id) , database_id
ORDER BY 'Cached Size (MB)' DESC
数据驻留在内存的时间由最近使用策略（least recently used，LRU）决定。每个数据页都会存放最近两次被使用的时间，每次对数据缓存进行检查时，都会检查这两个时间，如果发现这两个时间已经超过SQL Server该部分的阈值（具体数据未公开），而此时SQL Server需要释放内存，那么就会选择这些数据作为优先释放的对象。
下面来简单总结一下一个T-SQL查询语句在SQL Server的生命周期。
1）通过特定的SNI（比如TCP/IP），建立一个TDS，用于连接服务器和客户端，并接受SELECT命令和返回该命令的对应结果。
2）SQL Server上的SNI解压TDS包，读取SELECT语句，然后传入命令解析器进行命令解析。
3）命令解析器从计划缓存中检查是否有可用的执行计划供传入的SELECT语句重用。如果没有，就通过查询优化器分析并产生经过优化的执行计划。
4）如果查询足够简单，优化器会产生一个简单的执行计划（Trivial plan）。如果查询比较复杂，优化器会经过3个阶段对查询进行优化。
5）在执行计划产生之后，会传入查询执行器，然后传入存储引擎中的数据访问方法。
6）数据访问方法通过缓冲管理器操作数据缓存中的数据，用于完成查询。
7）最后将结果按原路一级一级地返回，直到返回给客户端。
具体过程如图3-6所示。
