SQL 运行架构
1) 用户端的应用程序通过各种对象(ADO.NET/ ADO/RDO)等,建立与传递想要执行的SQL查询语句.或者直接调用下层的API来达到相同目的,SQL 查询语句通过下层的Database API程序接口 ( eg:ADO.NET的SQL Client ,ADO搭配的 OLEDB,RDB包装的 ODBC )
转换SQL Server 专属的协议封包“TDS” (表格数据流 Tabular Data Stream ),并将该封包再递交给更下层的 “用户端 Net - Library”
2) “用户端 Net-Library ”采用默认的协议，或是以” 客户端网络公用程序 (SQL Server Client)”设置的通信协议，经由调用Windows的IPC (interprocesscommunication) API,将TDS 封包转由操作系统支持的通信协议堆栈传出。一般来说，SQL Server 7.0 以前版本是用命名管道,SQL Server 2000 以后改为TCP/IP。
用户端采用的通信协议只有一种，但因服务器端要接受来自各种用户端的需求。而用户端可能在不同平台上采用不同的协议，所以需支持多种通信协议，这需要通过”服务器网络公用程序”来设置。”服务器端Net-Library”所支持的不同协议各是独立模块，通过IPC 与上层的”ODS (Open Data Services )” 沟通，所以，若有新的设备与新的沟通需求，SQLServer 只要新增一个Net-Library 内的模块即可因应。在”用户端 Net-Library”与”服务器端 Net-Library”的搭配下，将TDS 上层通信协议的封包转给服务器端的”ODS (Open Data Services )”。
在用户与服务器两端沟通时可以采用SSL( Secure Socket Layer)做加/解密的工作.
依据操作系统版本，可以支持40或128位的加解密运算。但除非你有安全方面的疑虑，否则尽量不要激活，因为这将会耗费两端的资源来完成加解密数据的动作，同时增加协议堆栈中的层级，如此将会降低系统的性能。
3) “ODS ( Open Data Services )” 负责将TDS封包内的SQL 语句还原，并转交给关系型引擎，关系型引擎完成优化的执行计划后，再赋予存储引擎执行，两大引擎间依然是通过OLE DB 接口在沟通.
4) 存储引擎执行完关系引擎交付的执行计划后，将结果返回给关系型引擎，关系型引擎再将其包装结果集(result set) ，并传递给ODS.
5) ODS 将结果转成TDS 封包，继续回传给” 服务器 Net-Libraries” , 在”用户端 Net-Library”与”服务器端 Net-Library”的合作下，将结果通过网络返回，”用户端 Net-Libra ry”将网络封包还原成TDS 封包，转给上层的数据库接口OLE DB 或ODBC 等。
6) OLE DB 或 ODBC 将TDS 所描述的结果还原成上层应用程序可以接受的”结果集”,也就是我们一般访问的结果。
在如此的客户/服务器下，如果某个用户端硬件的效率太差，也有可能拖累整个系统。
例如：当某个用户端要了一大堆数据，但它没有能力立刻处理完这些源源不断传来的网络封包。因此，SQL Server 对该用户端的网络输出缓存区也就塞满了数据（这时并不影响其他的用户）。因为用户端的网络输出缓存区塞满了，扫描数据的工作就必须暂停，这时扫描数据所握有的锁定(lock)不能释放，导致其他用户可能会被锁定(lock)而产生连锁效应。