服务器解析请求的SQL语句。
1:SQL计划缓存,经常用查询分析器的朋友大概都知道这样一个事实,往往一个查询语句在第一次运行的时候需要执行特别长的时间,但是如果你马上或者在一定时间内运行同样的语句,会在很短的时间内返回查询结果。
原因:
1):服务器在接收到查询请求后,并不会马上去数据库查询,而是在数据库中的计划缓存中找是否有相对应的执行计划,如果存在,就直接调用已经编译好的执行计划,节省了执行计划的编译时间。
2):如果所查询的行已经存在于数据缓冲存储区中,就不用查询物理文件了,而是从缓存中取数据,这样从内存中取数据就会比从硬盘上读取数据快很多,提高了查询效率.数据缓冲存储区会在后面提到。
2:如果在SQL计划缓存中没有对应的执行计划,服务器首先会对用户请求的SQL语句进行语法效验,如果有语法错误,服务器会结束查询操作,并用返回相应的错误信息给调用它的应用程序。
服务器解析请求的SQL语句。
1:SQL计划缓存,经常用查询分析器的朋友大概都知道这样一个事实,往往一个查询语句在第一次运行的时候需要执行特别长的时间,但是如果你马上或者在一定时间内运行同样的语句,会在很短的时间内返回查询结果。
原因:
1):服务器在接收到查询请求后,并不会马上去数据库查询,而是在数据库中的计划缓存中找是否有相对应的执行计划,如果存在,就直接调用已经编译好的执行计划,节省了执行计划的编译时间。
2):如果所查询的行已经存在于数据缓冲存储区中,就不用查询物理文件了,而是从缓存中取数据,这样从内存中取数据就会比从硬盘上读取数据快很多,提高了查询效率.数据缓冲存储区会在后面提到。
2:如果在SQL计划缓存中没有对应的执行计划,服务器首先会对用户请求的SQL语句进行语法效验,如果有语法错误,服务器会结束查询操作,并用返回相应的错误信息给调用它的应用程序。
注意:此时返回的错误信息中,只会包含基本的语法错误信息,例如select 写成selec等,错误信息中如果包含一列表中本没有的列,此时服务器是不会检查出来的,因为只是语法验证,语义是否正确放在下一步进行。
3:语法符合后,就开始验证它的语义是否正确,例如,表名,列名,存储过程等等数据库对象是否真正存在,如果发现有不存在的,就会报错给应用程序,同时结束查询。
4:接下来就是获得对象的解析锁,我们在查询一个表时,首先服务器会对这个对象加锁,这是为了保证数据的统一性,如果不加锁,此时有数据插入,但因为没有加锁的原因,查询已经将这条记录读入,而有的插入会因为事务的失败会回滚,就会形成脏读的现象。
5:接下来就是对数据库用户权限的验证,SQL语句语法,语义都正确,此时并不一定能够得到查询结果,如果数据库用户没有相应的访问权限,服务器会报出权限不足的错误给应用程序,在稍大的项目中,往往一个项目里面会包含好几个数据库连接串,这些数据库用户具有不同的权限,有的是只读权限,有的是只写权限,有的是可读可写,根据不同的操作选取不同的用户来执行,稍微不注意,无论你的SQL语句写的多么完善,完美无缺都没用。
6:解析的最后一步,就是确定最终的执行计划。当语法,语义,权限都验证后,服务器并不会马上给你返回结果,而是会针对你的SQL进行优化,选择不同的查询算法以最高效的形式返回给应用程序。例如在做表联合查询时,服务器会根据开销成本来最终决定采用hash join,merge join ,还是loop join,采用哪一个索引会更高效等等,不过它的自动化优化是有限的,要想写出高效的查询SQL还是要优化自己的SQL查询语句。
当确定好执行计划后,就会把这个执行计划保存到SQL计划缓存中,下次在有相同的执行请求时,就直接从计划缓存中取,避免重新编译执行计划。
第三步：语句执行。
服务器对SQL语句解析完成后,服务器才会知道这条语句到底表态了什么意思,接下来才会真正的执行SQL语句。
此时分两种情况:
1):如果查询语句所包含的数据行已经读取到数据缓冲存储区的话,服务器会直接从数据缓冲存储区中读取数据返回给应用程序,避免了从物理文件中读取,提高查询速度。
2):如果数据行没有在数据缓冲存储区中,则会从物理文件中读取记录返回给应用程序,同时把数据行写入数据缓冲存储区中,供下次使用。
说明:SQL缓存分好几种,这里有兴趣的朋友可以去搜索一下,有时因为缓存的存在,使得我们很难马上看出优化的结果,因为第二次执行因为有缓存的存在,会特别快速,所以一般都是先消除缓存,然后比较优化前后的性能表现,这里有几个常用的方法:
DBCC DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
DBCC FREEPROCCACHE
从过程缓存中删除所有元素。
DBCC FREESYSTEMCACHE
从所有缓存中释放所有未使用的缓存条目。SQL Server 2005 数据库引擎会事先在后台清理未使用的缓存条目，以使内存可用于当前条目。但是，可以使用此命令从所有缓存中手动删除未使用的条目。
这只能基本消除SQL缓存的影响,目前好像没有完全消除缓存的方案,如果大家有,请指教。
执行顺序：
- FROM 子句返回初始结果集。
- WHERE 子句排除不满足搜索条件的行。
- GROUP BY 子句将选定的行收集到 GROUP BY 子句中各个唯一值的组中。
- 选择列表中指定的聚合函数可以计算各组的汇总值。
- 此外，HAVING 子句排除不满足搜索条件的行。
- 计算所有的表达式；
- 使用order by对结果集进行排序。
8.查找你要搜索的字段。
二 oracle 共享原理
ORACLE将执行过的SQL语句存放在内存的共享池(shared buffer pool)中，可以被所有的数据库用户共享
当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的 执行路径. 这个功能大大地提高了SQL的执行性能并节省了内存的使用
三 oracle 语句提高查询效率的方法
.1：.. where column in(select * from … where …);
2：… where exists (select ‘X’ from …where …);
第二种格式要远比第一种格式的效率高。在Oracle中可以几乎将所有的IN操作符子查询改写为使用EXISTS的子查询
使用EXIST，Oracle系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间
Oracle系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在在一个加了索引的临时表中
避免使用having字句
避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销
Shared locks (S) 共享锁
Update locks (U): 更新锁是共享锁和独占锁的组合.用UPDLOCK保持更新锁
Exclusive locks (X): 独占锁是为了锁定数据被一个session修改的数据, 而不能够被另外的session修改. 只能指定NOLOCK来读取.
Intent locks (I): 意向锁用于建立锁的层次结构. 意向锁包含三种类型：意向共享 (IS)、意向排他 (IX) 和意向排他共享 (SIX)。
数据库引擎使用意向锁来保护共享锁S 锁）或排他锁X 锁）放置在锁层次结构的底层资源上。 意向锁之所以命名为意向锁，是因为在较低级别锁前可获取它们，因此会通知意向将锁放置在较低级别上。
意向锁有两种用途：
防止其他事务以会使较低级别的锁无效的方式修改较高级别资源。
提高数据库引擎在较高的粒度级别检测锁冲突的效率。
Schema locks (Sch): 架构锁
Schema stability lock(Sch-S): 保持架构稳定性,用在生成执行计划时,不会阻止对数据的访问.
Schema modification lock (Sch-M):用在DDL操作时.当架构正在被改变时, 阻止对对象数据的访问.
Bulk Update locks (BU):
数据库引擎在将数据大容量复制到表中时使用了大容量更新 (BU) 锁, 并指定了 TABLOCK 提示或使用 sp_tableoption 设置了 table lock on bulk load 表选项. 大容量更新锁BU 锁）允许多个线程将数据并发地大容量加载到同一表, 同时防止其他不进行大容量加载数据的进程访问该表.
Key – Range locks
在使用可序列化事务隔离级别时, 对于 Transact-SQL 语句读取的记录集, 键范围锁可以隐式保护该记录集中包含的行范围. 键范围锁可防止幻读. 通过保护行之间键的范围, 它还防止对事务访问的记录集进行幻像插入或删除.
Microsoft SQL Server 数据库引擎死锁监视器定期检查陷入死锁的任务。 如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。 这样，其他任务就可以完成其事务。 对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。
锁由数据库引擎的一个部件称为“锁管理器”）在内部管理. 当数据库引擎实例处理Transact-SQL 语句时, 数据库引擎查询处理器会决定将要访问哪些资源. 查询处理器根据访问类型和事务隔离级别设置来确定保护每一资源所需的锁的类型. 然后, 查询处理器将向锁管理器请求适当的锁. 如果与其他事务所持有的锁不会发生冲突, 锁管理器将授予该锁.
不使用select * 可以：
1）不用去解析数据字典中的相应字段。
2）减少不必要的网络流量。
3）防止应用上引用，导致后续如果添加字段可能问题出现。
如果列名包含了所有的列那么和SELECT * 没有区别。
如果只有部分列，那就仅仅SELECT你所需要的，比SELECT * 效率高，特别是有时候这些列可以直接来自索引。
列存储是不定长的，ORACLE读到块之后必须算出每个列的偏移，然后去取列数据，每行都要算。越靠后的列这个计算开销越大。SELECT的列越多这个开销越大。
首先我们要分析清楚select *和select a1,a2,a3的区别。
首先sql server是按照数据块来存取数据的，一个数据块是8K，当你需要的数据在某个数据块上时，sql server会将整个8K的数据从磁盘上加载到内存中，而不仅仅是读取你需要的a1、a2这几个字段，从这种意义上来说，select *和select a1,a2,a3这种写法速度是一样的。
但是有一个问题在于有索引，当有索引的时候就不一样了，比如a1, a2, a3都在索引字段里面（包括inclue），这个时候如果select a1, a2,a3的话只要扫描索引就好了，而select *却要扫描表，通常这种情况下select a1, a2, a3要快一些。但是如果只有a1, a2在索引中，而a3不在索引中，那么select a1, a2, a3的时候就需要先扫描索引得到a1, a2，再通过索引找到表中对应的数据块取出来a3（注意取a3的时候是8K数据块一起取得），这时你会发现select a1, a2, a3又没什么优势了。当取得数据特别多的时候，扫描索引再去查找表，反而不如直接扫描表来的快，所以有时可能select *反而快。
所以要具体问题具体分析，具体的要看查询计划，确定问题所在。
数据最小单位是页 (也就是你所说的块)大小8K左右 另外聚集索引扫描与表扫描在IO开销与执行时间上差距非常小 可以忽略不计，索引查找与表扫描差距才是最大的，索引查找只需要选择性的找描部分数据页。
另外聚集索引数据直接存在叶子节点，而非聚集索引只是存指向数据的指针。你说的第二种情况属于书签查找，原理正如你所说！
到底是select * 快还是select a1,a2 与索引确实有系，生成的执行计划不同执行时间也会不同，当然返回所有列与返回选定列 抛开索引的影响，肯定是列越少IO的开销就越小速度也就越快
SQL SERVER复制技术类型有三种，分别是：快照复制、事务复制、合并复制。
SQL SERVER 服务器于客户端的交互主要依靠Open Data Services（简称ODS）组件，中文名 “开放数据服务”。在《SQL SERVER 2000技术内幕》中，译者将Open Data Services 翻译为“开放式数据服务”，但是这里的OPEN应该意味着“把数据开放”，“开放式”有一点不准确，联系上下文来看的话，无伤大雅。
ODS组件主要负责监听新的连接，清理失败的连接，以及将关系引擎返回的数据集、消息和状态值等信息返回给客户端。ODS组件可以响应一下三种事件：连接事件、语言事件、以及远程存储过程事件。也就是说，当我们打开查询分析器，填好SQL服务器名称，用户名和密码点击确定后，SQL服务器的ODS将触发连接事件进行安全性检查。如果安全性检查能够通过，ODS组件将准许建立连接，其具体的操作就是将在服务器端为客户端分配两个输入缓冲区（读缓冲区）和一个输出缓冲区（写缓冲区）。其中，写缓冲区用于存储关系引擎返回的数据集，当写缓冲被填满（达到4096个字节）或者数据集SQL语句已经执行完毕以后，写缓冲中的数据将被封装成一个TDS包（TDS将在后面详述）通过NET-LIB返回给客户端。ODS维护着与客户端的连接，当客户端断开连接或者意外断网的时候，ODS将负责回收资源，释放为客户端而保持的锁等资源。
这里有一个性能相关的问题大家要注意一下。当关系引擎源源不断地将得到的数据集写入输出缓冲区时，当输出缓冲区被填满而数据集仍然没有返回完毕时，输入缓冲区内的数据将被源源不断地发送到SQL客户端，在这期间，为该SQL客户端而分配的排它锁等资源将一直保持，直到关系引擎返回数据集完毕。这也意味着，当客户端与服务器端之间的网速慢得传输数据出现较大延迟，客户端来不及读取返回数据时，锁将会保留，甚至扫描也将被悬挂，那样SQL服务器将或多或少受到影响。
TDS的全称叫Tabular Data Stream，中文名叫表格数据流。它是SQL 客户端与服务器端用来通信的专用协议。它包含了描述列名称、数据类型、命令（比如中途取消）、各种客户端与服务器“协商”的令牌（就好像IP数据包中包含拥塞控制信息一样）等信息
对于数据量比较大的表其实不是很建议对大表排序或者对大表的某个重复次数多的字段去重运算。所以我们这里可以对ShipCity进行优化一下。可以对ShipCity创建一个非聚集索引。
CREATE INDEX Index_ShipCity On Orders(ShipCity desc)
go
ShipCountry和CustomerID的分组查询看上去很类似，但是为什么执行计划会不同呢？这是因为ShipCountry包含了大量的重复值，CustomerID重复值非常少，所以Sql server系统给ShipCountry推送的哈希聚合，而CustomerID推送的是流聚合。也就是说Sql server系统会动态的根据查询的情况选择合适的聚合方式。所以我们在做SQL优化的时候不能仅根据SQL语句来优化，还得结合具体数据分布的环境。
运算过程监控指标
4.1.监控元素：
可视化查看运行时间
T-sql语句查询时间
占用内存
T-sql语句查询IO
