SQL Server 原理
  在讲SQLSERVER内部原理的之前，我觉得非常有必要向大家介绍一下SQLSERVER的历史。
  让我们站在1999年，看看计算机数据库业界到底处于什么状态。
  1999年，Oracle已经于1998年9月发布了Oracle 8i（可能中文版在1999年才来到中国）。Oracle 8i支持用JAVA编写存储过程，支持XML，支持Linux。
  1999年1月，SQLSERVER7正式发布。SQLSERVER7重构了整个数据库引擎（相当于重写了SQLSERVER）。SQLSERVER第一次完整性的支持了行锁（有没有搞错，过去人是怎么使用数据库产品的。1988年，Oracle6就支持行锁。另外1988年，Oracle就开始研发ERP产品。谁说Oracle是ERP门外汉，可以参考这个）。
  看看他们俩的前一个版本。如果你入行比较晚（2000年以后），可能对以下文字更感到惊讶。
  1992年，Oracle7发布。有了存储过程、触发器、引用完整性校验、分布式事务处理。（天哪，Oracle7才有了这些东西）。
  1995年，SQLSERVER6发布。SQLSERVER6是微软真正意义上的第一个数据库产品（真是爆料，大家没想到SQLSERVER6才是微软第一个数据库产品，那版本6之前的5、4、3、2、1是怎么度过的）。因为1994年，微软和Sybase掰了（Sybase是第一个运行于PC上的C/S数据库产品）。微软为了进入数据库产品领域，自己又没有经验，于是和Sybase一起合作（当时微软是全世界第一大软件公司，微软1986年上市。Sybase有产品，缺钱。微软缺产品，有钱。于是一拍即合）。直到1994年，微软也不需要Sybase了（已经学会了数据库技术），Sybase也感觉微软太狼子野心，于是合作分裂。微软开始自己做自己的数据库。
oracle客户端卸载步骤  历史说完。我们言归正传。
  很多入门级做管理软件的，SQL语句玩的熟练，从子查询到Having到交叉表统计SQL都能做出来，甚至存储过程能写2000多行，游标、自定义函数、触发器、约束用的眼花缭乱。再入点门，在SQL查询器中可以使用SQL分析优化索引，用SQL Profile可以跟踪SQL，甚至在性能查看器中监测SQLSERVER内存、CPU、线程、I/O的运行状态，甚至为自己会使用DB
CC而沾沾自喜。
  你是如此熟悉SQLSERVER，又是对SQLSERVER如此陌生。
  我今天就用架构的角度来给大家分析一下SQLSERVER架构和原理。短短一篇博文肯定只能面上的多一些，深一层的可能需要连载数篇文章甚至一块大砖头书才能讲完整。不过，我希望我的博文能够抛砖引玉，使大家能从一个过去没有想过的角度去看SQLSERVER。
  SQLSERVER，作为一个数据库产品，我个人认为，最重要的就是两大块：存储引擎和查询引擎。
  其他的日志、事务、锁、索引等等都是围绕他们来工作的。
  SQLSERVER是C/S产品，所以一条SQL语句要让SQLSERVER执行，必须要传输到SQLSERVER服务器端。传输，我们当然知道需要NetBEUI、TCP/IP等等网络传输协议。但是光有这些还不行。客户端如何发，服务器端如何收，如何确认发的和收的正确完整，如何确实发的和收的已经结束，如何发和收能跨越各种网络协议（如UNIX和WINDOWS和NOVELL通讯），如何保证数据安全校验，如何保证数据收发是同步还是异步，就需要在网
络传输协议之上再构造一层协议。SQLSERVER既支持IPC机制，也支持RPC机制。你想想你的管理软件开发平台是否有这一层。当然，现在的消息服务器已经专业的提供了这一机理，可靠的、安全的、高效的、异步的、消息压缩、消息拆分、智能路由、集，跨越不同的操作系统、不同的编程语言、不同的通讯协议、不同的硬件平台的消息数据传输。可能你过去不了解消息中间件，通过这一案例可以知道消息中间件的用途。
  SQL语句被可靠无误的发送到了服务器端，SQLSERVER引擎中第一个模块就来接待这个SQL数据。这个模块的名字叫：Open Data Services。它监听新的连接；清除失败连接；将结果集、消息和状态返回给客户端。
  SQLSERVER客户端和服务器端之间传输数据，数据包是有格式的。在SQLSERVER中被称为tabular data stream。这个数据流是令牌控制客户端和服务器端对话（否则，客户端说了N句话，服务器端返回N句话，没有令牌就混在一起了，不知道哪个回答是对应哪个请求的）。我们往往不能直接和Open Data Services打交道，把数据放进来。而是我们必须通过ODBC、ADO或DB-Library来发送tabular data stream。而SQLSERVER返回的数据结果，也是通过这些ODBC之类发回tabular data stream。你看看SQLSERVER设计的多巧妙，一
个通用数据访问接口屏蔽了你和SQLSERVER之间，就如同WINDOWS API屏蔽了内核让你无法访问，就如同DirectX屏蔽了UI和外设的操控。
  SQL语句-ODBC-编码成tabular data stream-IPC或RPC-网络协议-IPC或RPC-解码tabular data stream-ODBC-Open Data Services。
  Open Data Services监测客户端连接。如果并发太多，它会创建连接，如果服务完，它会自己维护连接归入池中。在池中保留一段生命期，它会自己释放连接。如果有的客户端连接中途突然断掉（如客户端重启了），它在侦听后无回应，它也会自己整理自己的连接的。我们在SQLSERVER线程中看到的连接，就是Open Data Services创建的。
  Open Data Services有了连接（可能是创建的可能是从池里拿出来的，池化、创建、销毁都是非常讲究技能的。池化多少，上下文资源如何保留，池化多长时间，什么时候该销毁，调度不当就会严重消耗资源），就把SQL接住。这时，是接到了Open Data Services的读缓冲区里面。这个缓冲区为高性能处理数据的SQLSERVER带来一丝喘息机会，而就这一丝喘息机会，让SQLSERVER可以游刃有余（你的设计有吗？）。而Open Data Services有一个写缓冲区。SQLSERVER把检索到的数据，检索出来就立即放进写缓冲区，写缓冲区一满就
立即被Open Data Service发走。当我过去研究SQLSERVER原理的时候，我常常赞叹，一个小小的SQLSERVER外围模块都设计如此精妙，实在让人佩服。我们经常在追求海量数据存储和Cache架构，我们却无视我们手边的SQLSERVER。
  SQL语句放到读缓冲区，SQLSERVER的关系引擎就开始工作了。它总是在侦听这个读缓冲区。
  SQL语句遇到的关系引擎的第一个模块就是命令分析器。我们在SQL查询分析器中看到的查询分析结果就是它的输出杰作。它来构造查询树。首先是将你的SQL语句规范化（你想想你写的软件代码，输入数据来了什么都不管就直接处理，连输入数据校验都没有，怎能稳定），否则以后的步骤将不好操作，如果你的SQL语句有语法错误，这个查询树的构造就无法完成，于是中断。而要规范一个SQL语句，首先要从SQL语法库中抽取SQLSERVER现有支持的各种语法和函数。
  一旦构造成功，关系引擎的第二个模块就是命令优化器，来裁剪这棵树。一个SQL语句可以生成多种执行和优化的方案（如果你使用过那种SQL优化工具的话，你就能理解），SQLSERVER会选择最节省内存、CPU利用率、I/O次数（I/O是性能优化最要命的地方，往
往性能就瓶颈在I/O上）的那一种方案。优化器会根据每张表的数据统计（有时候你为了性能优化，必须定时期同步更新一下统计，否则优化就会有误差）。而且优化器也会根据查询树去选择合适的索引（如果使用索引代价大，它会自动选择全表扫描），优化器也会根据查询树知道先取哪些表的数据，然后再内存中如何合并数据，以得到你想要的结果（有时候想想优化器真伟大，你一个SQL过去，它需要在极短的时间内做多少事啊，为了能在极短时间内确定一个相对优化的方案，它也不可能穷举所有可能的方案，所以我们做海量数据优化的时候，往往评估多种方案，然后修改自己的SQL语句以符合产生最优的方案）。
  规范化、优化完SQL语句，就要产生执行计划了。SQL管理器负责执行计划的产生。因为你发过来的SQL语句可能是一个SELECT，也可能是一个INSERT或UPDATE。即使SELECT，也面临着用户权限的限制（你如果设置过某一个SQLSERVER用户的对象权限和列权限，你就会明白）。而INSERT之类更新语句，又会涉及到权限、默认值、约束、表达式、主外键、触发器。一个优化完的SQL，具体要真正让SQLSERVER从内存或硬盘上把数据出来或者更新回去，需要很多细节的步骤。
  查询执行器来负责SQL的执行。因为SQL的执行要涉及到事务、锁、等待、CPU调度，内
存页失效影响、I/O存取影响，所以查询执行器会协调很多其他模块，但各个模块来负责处理，而查询执行器并不真正全部包办，否则让事务管理器、锁管理器、索引管理器、页面文件管理器、缓冲管理器、行管理器、日志管理器干吗去。
  查询执行器是查询引擎的最后一个模块，接下来的模块都属于存储引擎的范畴。所以，从上看，查询引擎最主要是构造SQL查询树、优化裁剪SQL查询树，根据查询树产生执行计划，然后协调执行查询树，把结果返回去。
  而真正要把数据取出来或存进去，就需要存储引擎来工作了。
  首先根据执行计划，要存取哪些数据页和索引页。这就是访问方法管理器（access methods manager）要做的事情。但其实真要打开这些页，还不是访问方法管理器自己要亲手干的。
  亲手干这个活的是一个叫“缓冲区管理器”的模块。因为在硬盘上的数据是不可能计算处理的，必须要在内存中才能让CPU来计算。所以要存取那些数据页和索引页，就通知让缓冲区管理器来做。如果数据没有在内存中，就让缓冲区管理器来读入，如果数据已经在内存中了，
缓冲区管理器只有返回即可。这个过程是被缓冲区管理器来屏蔽的，对于访问方法管理器是透明的。大家可不要以为访问方法管理器啥事不做，只是一个发布调度命令的。这可错怪了它。因为SQLSERVER要保证高速处理，必须预先预测好哪些数据页和索引页要处理。不能人家缓冲管理器已经处理完，你访问方法管理器才计算下一步将要处理的页面。要知道，这些管理器可是不分哪个用户来处理的。如果接受来自100多个并发的用户，发来各种各样的数据处理请求，你怎么能预测到哪些数据页和索引页要处理呢？这就需要一个统一的调度。而且这个统一的调度也影响着缓冲区管理器。你不能请求一个大数据，缓冲区管理器这才火烧屁股才扩大缓冲区，然后装载数据，那样流水线就停下了。缓冲区管理器必须预先知道将在不久要有一个大数据，所以在并行运算的时候就有独立线程来扩展了缓冲区。因为扩大缓冲区还和操作系统有关。你要扩大缓冲区，正好遇到WINDOWS页面失效，就涉及到你的虚拟文件的变化。而页面失效又会影响CPU和I/O。所以页面失效是一个性能影响很大的问题。而提高命中率是我们性能优化一直努力的重点。如果数据长时间不用，缓冲区管理器就要让这块内存数据过期，可以被新的数据覆盖。否则缓冲区老加载不卸载也不行。再说，有些数据已经被更新了，你数据老化了，不重新读入，你的数据就引起读错误了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。