sql server优化（SQL性能优化：如何定位网络性能问题）

本文目录

• SQL性能优化：如何定位网络性能问题
• MSSQL Server分析服务性能优化浅析
• SQL Server存储过程的编写和优化措施
• 从外到内提高SQL Server数据库性能
• 优化SQL查询：如何写出高性能SQL语句

SQL性能优化：如何定位网络性能问题

name rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB
为了验证我的想法，我在服务器本机测试时间为2秒，如下截图所示
从上面我们知道在客户端执行完该SQL语句，总共耗费了2分23秒。那么客户端的到底获取了多少字节数据，数据传输耗费了多长时间呢？ 能否查看这些DETAIL信息呢？ 答案是可以。在SSMS工具栏，勾选“Include Client Statistics”或使用快捷键SHIFT+ALT+S，然后执行SQL语句，就能得到如下截图的相关信息。
Client Statistics(客户端统计信息）包含三大块： Query Profile Statistics， Network Statistics, Time Statistics。
这些部分的内容很容易理解，无需多说，那么我们来看看吧
NetworkStatistics（网络统计信息）Numberofserverroundtrips:服务器往返的次数TDSpacketssentfromclient:从客户端发送的TDS数据包（个数）TDSpacketsreceivedfromserver:从服务端接收的TDS数据包（个数）Bytessentfromclient:从客户端发送的字节数Bytesreceivedfromserver:从服务器接收的字节数TimeStattistics:（时间统计信息）Clientprocessingtime:客户端处理时间Totalexecutiontime:总执行时间Waittimeonserverreplies:服务器应答等待时间
从客户端发送的字节和从服务端接收的数据大小都很清晰、明了，那么数据从服务器端发送给客户端所需的时间这里没有，其实它基本上接近客户端处理时间（Client processing time），我们也可以将客户端处理时间权当网络数据传输时间，从上面案例，我们可以看到这个时间耗费了140秒（140132 ms）,可以肯定这个SQL性能慢在网络数据传输上，而不是慢在数据库那一块（Server Processing Time）.
我们来看看下图，这个是SQL SERVER的请求接收和数据输出的一个大致流程图，当客户端发送请求开始，当服务器接收客户端发来的最后一个TDS包，数据库引擎开始处理请求，请求完成后，将数据发送给客户端，从图中可以看出，客户端接收服务器端返回的数据也是需要一个过程的（或者说时间）
我们在SQL优化过程中，如果一个SQL出现性能问题时，我们应该站在一个全局的角度来分析问题，从CPU资源、网络带宽、磁盘IO、执行计划等多方面来分析，这样才能有助于你分析、定位问题根源，而不要只要SQL响应很慢时，就一味条件反射式先入为主：这是数据库问题。数据库也不能老背这个黑锅。
在数据库等待事件中，ASYNC_NETWORK_IO可以从另外一个侧面反映网络性能问题。关于ASYNC_NETWORK_IO等待类型：
This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application.
那么回到如何优化这个SQL的问题上来，我们可以从下面几个方面来进行优化。
1： SQL只取必须的字段数据
像这个案例，其实它根本不需要Item_Photo字段数据，那么我们可以修改SQL，只取我们需要的字段数据，就可以避免这个问题，提高SQL性能，另外根据我的经验，开发人员习惯性使用SELECT *，从不管那些数据是需要还是不需要的，先全部取过来再说，这种习惯性行为确实不是一个好习惯。
2：避免这种脑残设计
图片应该以文件形式保存在应用服务器上，数据库只保存其路径信息，这种将图片保存到数据库的设计纯属脑残行为。
参考资料：
***隐藏网址***
SQL性能优化：如何定位网络性能问题
标签：

MSSQL Server分析服务性能优化浅析

在SQL Server数据库管理中，针对分析服务Analysis Services 的性能优化必不可少，这里我们将学习到使用DMV来进行Analysis Services 的优化。使用动态管理视图 (DMV) 监视 Analysis Services 的连接和资源统计信息。 Analysis Services 统计信息的功能可帮助您解决与 Analysis Services 相关的问题并优化 Analysis Services 性能。
注意：您可以从 C:\SQLHOLS\Managing Analysis Services\Starter\Exercise3.txt 复制此练习中使用的脚本。每份脚本前面都带有注释，以标识和代码相关的过程和步骤
1. 在 SQL Server Management Studio中的文件菜单中，指向新建，然后单击Analysis Services MDX 查询(也可以在工具栏中单击新建查询)。
2. 如果显示连接到 Analysis Services 对话框，请单击连接。
3. 在工具栏中的可用数据库列表中，确保选中 Adventure Works OLAP 数据库。
4. 键入下列命令并执行，然后滚动浏览结果，查看所有包含以 DISCOVER_ 开头的 TABLE_NAME 值的行。此查询为您提供可用的 DMV。
SELECT * FROM $SYSTEM.DBSCHEMA_TABLES ORDER BY TABLE_NAME
注意：利用这些 DMV，从服务器检索性能统计信息的方式可以非常灵活。您可以编写自定义应用程序或使用 SQL Server Reporting Services 生成报告，收集并查看解决 Analysis Services 环境问题和优化该环境所需的信息。
5. 在查询页中，使用以下命令替换现有查询，然后单击执行。
SELECT * FROM $SYSTEM.DISCOVER_CONNECTIONS
6. 查看查询结果。调整左起第五列(CONNECTION_HOST_APPLICATION)的列宽，以查看每个连接的完整应用程序名称。请注意 SQL Server Management Studio 查询和 SQL Server Management Studio 的结果是有区分的。
注意：CONNECTION_LAST_COMMAND_START_TIME、CONNECTION_LAST_COMMAND_END_TIME 和 CONNECTION_LAST_COMMAND_ELAPSED_TIME_MS 等值可帮助您找出运行时间长或有问题的查询。
7. 关闭上一练习结束时保留为打开状态的 Adventure Works Cube窗口。
8. 在 MDXQuery1 选项卡中，重新执行步骤 5 的查询 (SELECT * FROM $SYSTEM.DISCOVER_CONNECTIONS)，并注意 SQL Server Management Studio 连接不再呈示。记下当前 CONNECTION_ID 值。
9. 最小化 SQL Server Management Studio。
10. 单击开始|所有程序| Microsoft Office，然后单击 Microsoft Office Excel 2007。
11. 在 Excel 功能区中，单击数据选项卡。
12. 在数据选项卡中，在获取外部数据部分，单击自其他来源，然后单击来自分析服务。
13. 在连接数据库服务器页中，在服务器名称框中键入 (local)，然后单击下一步。
14. 在选择数据库和表中，在选择数据库框中，选择 Adventure Works OLAP 数据库，单击 Adventure Works Cube，然后单击下一步。
15. 在保存数据连接文件并完成页中，单击完成。
16. 在导入数据页中，查看默认设置，然后单击确定。
17. 在数据透视表字段列表中，在 Internet Sales下，展开Sales，然后选中 Internet Sales-Sales Amount复选框。
18. 在数据透视表字段列表中，在Product下，选中Product Categories复选框。
19. 最小化 Microsoft Office Excel，然后最大化 SQL Server Management Studio。
20. 在 MDXQuery1 选项卡中，重新执行步骤 5 的查询 (SELECT * FROM $SYSTEM.DISCOVER_CONNECTIONS)，然后记录 Excel 创建的新连接的 CONNECTION_ID。
21. 在现有查询下，键入以下查询。
SELECT
session_connection_id
, session_spid
, session_user_name
, session_last_command
, session_start_time
, session_CPU_time_ms
, session_reads
, session_writes
, session_status
, session_current_database
, session_used_memory
, session_start_time
, session_elapsed_time_ms
, session_last_command_start_time
, session_last_command_end_time
FROM $SYSTEM.DISCOVER_SESSIONS
22. 选择刚刚输入的查询，然后单击执行。
23. 查看 session_connection_id 与步骤 20 中记录的数字匹配的行的输出。请注意这些结果中包含用户名、上一命令和每个连接的 CPU 时间等有用诊断信息。
注意：session_status 为 1 表示在报告运行时具有活动查询的会话。
24. 键入以下命令并执行，以查看数据库中每个对象的内存使用量。
SELECT * FROM $SYSTEM.DISCOVER_OBJECT_MEMORY_USAGE
25. 键入以下命令并执行，以查看数据库中每个对象的活动。
SELECT * FROM $SYSTEM.DISCOVER_OBJECT_ACTIVITY
26. 关闭 SQL Server Management Studio 和 Microsoft Office Excel 2007。请勿保存任何文件。
27. 关闭 Hyper-V 窗口

SQL Server存储过程的编写和优化措施

在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
详细内容：
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
(a)SQL的使用规范：
i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
iii.　尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写;如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
iv.　注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
v.　不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
vi.　尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
vii.　尽量使用“=”，不要使用“”。
viii.　注意一些or子句和union子句之间的替换
ix.　注意表之间连接的数据类型，避免不同类型数据之间的连接。
x.　注意存储过程中参数和数据类型的关系。
xi.　注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面(400k)，那么系统将会进行锁升级，页级锁会升级成表级锁。
(b)索引的使用规范：
i.　索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
ii.　尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
iii.　避免对大表查询时进行table scan，必要时考虑新建索引。
iv.　在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
v.　要注意索引的维护，周期性重建索引，重新编译存储过程。
(c)tempdb的使用规范：
i.　尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
ii.　避免频繁创建和删除临时表，减少系统表资源的消耗。
iii.　在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度;如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
iv.　如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
v.　如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
vi.　慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
(d)合理的算法使用：
根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。

从外到内提高SQL Server数据库性能

　　如何提高SQL Server数据库的性能 该从哪里入手呢?笔者认为 该遵循从外到内的顺序 来改善数据库的运行性能 如下图

　　 第一层 网络环境

　　到企业碰到数据库反映速度比较慢时 首先想到的是是否是网络环境所造成的 而不是一开始就想着如何去提高数据库的性能 这是很多数据库管理员的一个误区 因为当网络环境比较恶劣时 你就算再怎么去改善数据库性能 也是枉然

　　如以前有个客户 向笔者反映数据库响应时间比较长 让笔者给他们一个提高数据库性能的解决方案 那时 笔者感到很奇怪 因为据笔者所知 这家客户数据库的记录量并不是很大 而且 他们配置的数据库服务器硬件很不错 笔者为此还特意跑到他们企业去查看问题的原因 一看原来是网络环境所造成的 这家企业的客户机有 多台 而且都是利用集线器进行连接 这就导致企业内部网络广播泛滥 网络拥塞 而且由于没有部署企业级的杀毒软件 网络内部客户机存在病毒 掠夺了一定的带宽 不仅数据库系统响应速度比较慢 而且其他应用软件 如邮箱系统 速度也不理想

　　在这种情况下 即使再花十倍 百倍力气去提升SQL Server数据库的性能 也是竹篮子打水一场空 因为现在数据库服务器的性能瓶颈根本不在于数据库本身 而在于企业的网络环境 若网络环境没有得到有效改善 则SQL Server数据库性能是提高不上去的

　　为此 笔者建议这家企业 想跟他们的网络管理员谈谈 看看如何改善企业的网络环境 减少广播包和网络冲突;并且有效清除局域网内的病毒 木马等等 三个月后 我再去回访这家客户的时候 他们反映数据库性能有了很大的提高 而且其他应用软件 性能也有所改善

　　所以 当企业遇到数据库性能突然降低的时候 第一个反应就是查看网络环境 看看其实否有恶化 只有如此 才可以少走冤枉路

　　 第二层 服务器配置

　　这里指的服务器配置 主要是讲数据库服务器的硬件配置以及周边配套 虽然说 提高数据库的硬件配置 需要企业付出一定的代价 但是 这往往是一个比较简便的方法 比起优化SQL语句来说 其要简单的多

　　如企业可以通过增加硬盘的数量来改善数据库的性能 在实际工作中 硬盘输入输出瓶颈经常被数据库管理员所忽视 其实 到并发访问比较多的时候 硬盘输入输出往往是数据库性能的一个主要瓶颈之一 此时 若数据库管理员可以增加几个硬盘 通过磁盘阵列来分散磁盘的压力 无疑是提高数据库性能的一个捷径

　　如增加服务器的内存或者CPU 当数据库管理员发现数据库性能的不理想是由内存或者CPU所造成的 此时 任何的改善数据库服务器本身的措施都将一物用处 所以 有些数据库管理专家 把改善服务器配置当作数据库性能调整的一个先决条件

　　如解决部署在同一个数据库服务器上的资源争用问题 虽然我们多次强调 要为数据库专门部署一个服务器 但是 不少企业为了降低信息化的成本 往往把数据库服务器跟应用服务器放在同一个服务器中 这就会导致不同服务器之间的资源争用问题 如把文件服务器跟数据服务器部署在同一个服务器中 当对文件服务器进行备份时 数据库性能就会有明显的下降 所以 在数据库性能发现周期性的变化时 就要考虑是否因为服务器上不同应用对资源的争夺所造成的

　　故 笔者建议 改善数据库性能时第二个需要考虑的层面 就是要看看能否通过改善服务器的配置来实现

　　 第三层 数据库服务器

　　当通过改善网络环境或者提高服务器配置 都无法达到改善数据库性能的目的时 接下去就需要考察数据库服务器本身了 首先 就需要考虑数据库服务器的配置

　　一方面 要考虑数据库服务器的连接模式 SQL Server数据库提供了很多的数据库模式 不同的数据库连接模式对应不同的应用 若数据库管理员能够熟悉企业自身的应用 并且选择合适的连接模式 这往往能够达到改善数据库性能的目的

　　其次 合理配置数据库服务器的相关作业 如出于安全的需要 数据库管理员往往需要对数据库进行备份 那么 备份的作业放在什么时候合适呢?当然 放在夜晚 夜深人静的时候 对数据库进行备份最好 另外 对于大型数据库 每天都进行完全备份将会是一件相当累人的事情 虽然累得不是我们 可是数据库服务器也会吃不消 差异备份跟完全备份结合将是改善数据库性能的一个不错的策略

　　 第四层 数据库对象

　　若以上三个层面后 数据库性能还不能够得到大幅度改善的话 则就需要考虑是否能够调整数据库对象来完成我们的目的 虽然调整数据库对象往往可以提到不错的效果 但是 往往会对数据库产生比较大的影响 所以 笔者一般不建议用户一开始就通过调整数据库对象来达到改善数据库性能的目的

　　数据库对象有表 视图 索引 关键字等等 我们也可以通过对这些对象进行调整以实现改善数据库性能的目标

　　如在视图设计时 尽量把其显示的内容缩小 宁可多增加视图 如出货明细表 销售人员可能希望看到产品编号 产品中英文描述 产品名字 出货日期 客户编号 客户名字等等 但是 对于财务来说 可能就不需要这么全的信息 他们只需要产品编号 客户编号 出货日期等等少量的信息即可 所以 能可浪费一点代码的空间 设计两张视图 对应不同部门的需求 如此 财务部门在查询数据时 不会为不必要的数据浪费宝贵的资源

　　如可以通过合理设置索引来提高数据库的性能 索引对于提高数据的查询效率 有着非常好的效果 对一些需要重复查询的数据 或者数据修改不怎么多的表设置索引 无疑是一个不错的选择

　　另外 要慎用存储过程 虽然说存储过程可以帮助大家实现很多需求 但是 在万不得已的情况下 不要使用存储过程 而利用前台的应用程序来实现需求 这主要是因为在通常情况下 前台应用程序的执行效率往往比后台数据库存储过程要高的多

　 　第五层 SQL 语句

　　若以上各个层面你都努力过 但是还不满足由此带来的效果的话 则还有最后一招 通过对SQL语句进行优化 也可以达到改善数据库性能的目的

　　虽然说SQL Server服务器自身就带有一个SQL语句优化器 他会对用户的SQL语句进行调整 优化 以达到一个比较好的执行效果 但是 据笔者的了解 这个最多只能够优化一些粗略的层面 或者说 %的优化仍然需要数据库管理员的配合 要数据库管理员跟SQL优化器进行配合 才能够起到非常明显的作用

　　不过 SQL语句的调整对于普通数据库管理员来说 可能有一定的难度 除非受过专业的训练 一般很难对SQL语句进行优化 还好笔者受过这方面的专业训练 对这方面有比较深的认识 如在SQL语句中避免使用直接量 任何一个包含有直接量的SQL语句都不太可能被再次使用 我们数据库管理员要学会利用主机变量来代替直接量 不然 这些不可再用的查询语句将使得程序缓存被不可再用的SQL语句填满 这都是平时工作中的一些小习惯

优化SQL查询：如何写出高性能SQL语句

1、 首先要搞明白什么叫执行计划？
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。
可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要：
(1) SQL语句是否清晰地告诉查询优化器它想干什么？
(2) 查询优化器得到的数据库统计信息是否是最新的、正确的？
2、 统一SQL语句的写法
对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。
select*from dual
select*From dual
其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！
3、 不要把SQL语句写得太复杂
我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。可想而知，数据库的效率会何等低下。
4、 使用“临时表”暂存中间结果
简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
5、 OLTP系统SQL语句必须采用绑定变量
select*from orderheader where changetime 》‘2010-10-20 00:00:01‘
select*from orderheader where changetime 》‘2010-09-22 00:00:01‘
以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。如果采用绑定变量
select*from orderheader where changetime 》@chgtime
@chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，这可以大大降低数据库解析SQL语句的负担。一次解析，多次重用，是提高数据库效率的原则。
6、 绑定变量窥测
事物都存在两面性，绑定变量对大多数OLTP处理是适用的，但是也有例外。比如在where条件中的字段是“倾斜字段”的时候。
“倾斜字段”指该列中的绝大多数的值都是相同的，比如一张人口调查表，其中“民族”这列，90%以上都是汉族。那么如果一个SQL语句要查询30岁的汉族人口有多少，那“民族”这列必然要被放在where条件中。这个时候如果采用绑定变量@nation会存在很大问题。
试想如果@nation传入的第一个值是“汉族”，那整个执行计划必然会选择表扫描。然后，第二个值传入的是“布依族”，按理说“布依族”占的比例可能只有万分之一，应该采用索引查找。但是，由于重用了第一次解析的“汉族”的那个执行计划，那么第二次也将采用表扫描方式。这个问题就是著名的“绑定变量窥测”，建议对于“倾斜字段”不要采用绑定变量。
7、 只在必要的情况下才使用begin tran
SQL Server中一句SQL语句默认就是一个事务，在该语句执行完成后也是默认commit的。其实，这就是begin tran的一个最小化的形式，好比在每句语句开头隐含了一个begin tran，结束时隐含了一个commit。
有些情况下，我们需要显式声明begin tran，比如做“插、删、改”操作需要同时修改几个表，要求要么几个表都修改成功，要么都不成功。begin tran 可以起到这样的作用，它可以把若干SQL语句套在一起执行，最后再一起commit。好处是保证了数据的一致性，但任何事情都不是完美无缺的。Begin tran付出的代价是在提交之前，所有SQL语句锁住的资源都不能释放，直到commit掉。
可见，如果Begin tran套住的SQL语句太多，那数据库的性能就糟糕了。在该大事务提交之前，必然会阻塞别的语句，造成block很多。
Begin tran使用的原则是，在保证数据一致性的前提下，begin tran 套住的SQL语句越少越好！有些情况下可以采用触发器同步数据，不一定要用begin tran。
8、 一些SQL查询语句应加上nolock
在SQL语句中加nolock是提高SQL Server并发性能的重要手段，在oracle中并不需要这样做，因为oracle的结构更为合理，有undo表空间保存“数据前影”，该数据如果在修改中还未commit，那么你读到的是它修改之前的副本，该副本放在undo表空间中。这样，oracle的读、写可以做到互不影响，这也是oracle 广受称赞的地方。SQL Server 的读、写是会相互阻塞的，为了提高并发性能，对于一些查询，可以加上nolock，这样读的时候可以允许写，但缺点是可能读到未提交的脏数据。使用 nolock有3条原则。
(1) 查询的结果用于“插、删、改”的不能加nolock ！
(2) 查询的表属于频繁发生页分裂的，慎用nolock ！
(3) 使用临时表一样可以保存“数据前影”，起到类似oracle的undo表空间的功能，
能采用临时表提高并发性能的，不要用nolock 。
9、 聚集索引没有建在表的顺序字段上，该表容易发生页分裂
比如订单表，有订单编号orderid，也有客户编号contactid，那么聚集索引应该加在哪个字段上呢？对于该表，订单编号是顺序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，这样不容易经常产生页分裂。然而，由于大多数查询都是根据客户编号来查的，因此，将聚集索引加在contactid上才有意义。而contactid对于订单表而言，并非顺序字段。
比如“张三”的“contactid”是001，那么“张三”的订单信息必须都放在这张表的第一个数据页上，如果今天“张三”新下了一个订单，那该订单信息不能放在表的最后一页，而是第一页！如果第一页放满了呢？很抱歉，该表所有数据都要往后移动为这条记录腾地方。
SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引实际上是对表按照聚集索引字段的顺序进行了排序，相当于oracle的索引组织表。SQL Server的聚集索引就是表本身的一种组织形式，所以它的效率是非常高的。也正因为此，插入一条记录，它的位置不是随便放的，而是要按照顺序放在该放的数据页，如果那个数据页没有空间了，就引起了页分裂。所以很显然，聚集索引没有建在表的顺序字段上，该表容易发生页分裂。
曾经碰到过一个情况，一位哥们的某张表重建索引后，插入的效率大幅下降了。估计情况大概是这样的。该表的聚集索引可能没有建在表的顺序字段上，该表经常被归档，所以该表的数据是以一种稀疏状态存在的。比如张三下过20张订单，而最近3个月的订单只有5张，归档策略是保留3个月数据，那么张三过去的 15张订单已经被归档，留下15个空位，可以在insert发生时重新被利用。在这种情况下由于有空位可以利用，就不会发生页分裂。但是查询性能会比较低，因为查询时必须扫描那些没有数据的空位。
重建聚集索引后情况改变了，因为重建聚集索引就是把表中的数据重新排列一遍，原来的空位没有了，而页的填充率又很高，插入数据经常要发生页分裂，所以性能大幅下降。
对于聚集索引没有建在顺序字段上的表，是否要给与比较低的页填充率？是否要避免重建聚集索引？是一个值得考虑的问题！
10、加nolock后查询经常发生页分裂的表，容易产生跳读或重复读
加nolock后可以在“插、删、改”的同时进行查询，但是由于同时发生“插、删、改”，在某些情况下，一旦该数据页满了，那么页分裂不可避免，而此时nolock的查询正在发生，比如在第100页已经读过的记录，可能会因为页分裂而分到第101页，这有可能使得nolock查询在读101页时重复读到该条数据，产生“重复读”。同理，如果在100页上的数据还没被读到就分到99页去了，那nolock查询有可能会漏过该记录，产生“跳读”。
上面提到的哥们，在加了nolock后一些操作出现报错，估计有可能因为nolock查询产生了重复读，2条相同的记录去插入别的表，当然会发生主键冲突。
11、使用like进行模糊查询时应注意
有的时候会需要进行一些模糊查询比如
select*from contact where username like ‘%yue%’
关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%，
12、数据类型的隐式转换对查询效率的影响
sql server2000的数据库，我们的程序在提交sql语句的时候，没有使用强类型提交这个字段的值，由sql server 2000自动转换数据类型，会导致传入的参数与主键字段类型不一致，这个时候sql server 2000可能就会使用全表扫描。Sql2005上没有发现这种问题，但是还是应该注意一下。
13、SQL Server 表连接的三种方式
(1) Merge Join
(2) Nested Loop Join
(3) Hash Join
SQL Server 2000只有一种join方式——Nested Loop Join，如果A结果集较小，那就默认作为外表，A中每条记录都要去B中扫描一遍，实际扫过的行数相当于A结果集行数x B结果集行数。所以如果两个结果集都很大，那Join的结果很糟糕。
SQL Server 2005新增了Merge Join，如果A表和B表的连接字段正好是聚集索引所在字段，那么表的顺序已经排好，只要两边拼上去就行了，这种join的开销相当于A表的结果集行数加上B表的结果集行数，一个是加，一个是乘，可见merge join 的效果要比Nested Loop Join好多了。
如果连接的字段上没有索引，那SQL2000的效率是相当低的，而SQL2005提供了Hash join，相当于临时给A，B表的结果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我认为，这是一个重要的原因。
总结一下，在表连接时要注意以下几点：
(1) 连接字段尽量选择聚集索引所在的字段
(2) 仔细考虑where条件，尽量减小A、B表的结果集
(3) 如果很多join的连接字段都缺少索引，而你还在用SQL Server 2000，赶紧升级吧。
***隐藏网址***
转自：51cto
优化SQL查询：如何写出高性能SQL语句
标签：