mysql优化策略.pdf

《mysql优化策略.pdf》由会员分享，可在线阅读，更多相关《mysql优化策略.pdf（14页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的 SELECT语句在 SQL 语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如P

2、owerBuilder、Delphi 等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。分析问题 许多程序员认为查询优化是 DBMS（数据库管理系统）的任务，与程序员所编写的 SQL 语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的 SQL 语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语

3、法检查之后，将语句提交给 DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如 Oracle、Sybase 等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的 SQL 语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面

4、重点说明改善用户查询计划的解决方案。解决问题 下面以关系数据库系统 Informix 为例，介绍改善用户查询计划的方法。1合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用 IBM 最先提出的 ISAM 索引结构。索引的使用要恰到好处，其使用原则如下：在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。在频繁进行排序或分组（即进行 group by 或 order by 操作）的列上建立索引。在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只

5、有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。使用系统工具。如 Informix 数据库有一个 tbcheck 工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用 tbcheck 工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。2避免或简化排序 应当简化或避免对大型表进行重复的排序。当能够利用索引

6、自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：索引中不包括一个或几个待排序的列；group by 或 order by 子句中列的次序与索引的次序不一样；排序的列来自不同的表。为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。3消除对大型表行数据的顺序存取 在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套 3 层的查询，如果每层都查询 1000 行，那么这个查询就要查询 10 亿行数据。避免这种情

7、况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的 where子句强迫优化器使用顺序存取。下面的查询将强迫对 orders 表执行顺序操作：SELECT FROM orders WHERE(customer_num=104 AND order_num1001)OR order_num=1008 虽然在 customer_num 和 order_num 上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫

8、描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：SELECT FROM orders WHERE customer_num=104 AND order_num1001 UNION SELECT FROM orders WHERE order_num=1008 这样就能利用索引路径处理查询。4避免相关子查询 一个列的标签同时在主查询和 where 子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。5避免困难的正规表达式 MATCHES 和

9、 LIKE 关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT FROM customer WHERE zipcode LIKE“98_ _ _”即使在 zipcode 字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为 SELECT FROM customer WHERE zipcode“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。另外，还要避免非开始的子串。例如语句：SELECT FROM customer WHERE zipcode2，3“80”，在 where 子句中采用了非开始子串，因而这个语句也不会使用索引

10、。6使用临时表加速查询 把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：SELECT cust.name，rcvbles.balance，other columns FROM cust，rcvbles WHERE cust.customer_id=rcvlbes.customer_id AND rcvblls.balance0 AND cust.postcode“98000”ORDER BY cust.name 如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：SE

11、LECT cust.name，rcvbles.balance，other columns FROM cust，rcvbles WHERE cust.customer_id=rcvlbes.customer_id AND rcvblls.balance0 ORDER BY cust.name INTO TEMP cust_with_balance 然后以下面的方式在临时表中查询：SELECT FROM cust_with_balance WHERE postcode“98000”临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘 I/O，所以查询工作量可以得到大幅减少。注意：

12、临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。7用排序来取代非顺序存取 非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL 语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。实例分析 下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括 3 个表，模式如下所示：1part 表 零件号零件描述其他列 （part_num）（part_desc）（other column）102，032Seageat 30G disk 500，049Novel 1

13、0M network card 2vendor 表 厂商号厂商名其他列 （vendor _num）（vendor_name）（other column）910，257Seageat Corp 523，045IBM Corp 3parven 表 零件号厂商号零件数量 （part_num）（vendor_num）（part_amount）102，032910，2573,450,000 234，423321，0014，000，000 下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：SELECT part_desc，vendor_name，part_amount FROM part，ve

14、ndor，parven WHERE part.part_num=parven.part_num AND parven.vendor_num=vendor.vendor_num ORDER BY part.part_num 如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：表行尺寸行数量每页行数量数据页数量 （table）(row size)（Row count）（Rows/Pages）（Data Pages）part15010，00025400 Vendor1501，000 2540 Parven1

15、3 15，000300 50 索引键尺寸每页键数量页面数量 （Indexes）(Key Size)（Keys/Page)(Leaf Pages）part450020 Vendor45002 Parven825060 看起来是个相对简单的 3 表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num 上和 vendor_num 上有簇索引，因此索引是按照物理顺序存放的。parven 表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从 part 中顺序读取 400 页，然后再对 parven 表非顺序存取 1 万次，每次 2 页

16、（一个索引页、一个数据页），总计 2 万个磁盘页，最后对 vendor 表非顺序存取 1.5 万次，合 3 万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为 5.04 万次。实际上，我们可以通过使用临时表分 3 个步骤来提高查询效率：1从 parven 表中按 vendor_num 的次序读数据：SELECT part_num，vendor_num，price FROM parven ORDER BY vendor_num INTO temp pv_by_vn 这个语句顺序读 parven（50 页），写一个临时表（50 页），并排序。假定排序的开销为 200页，总共是 300 页。2

17、把临时表和 vendor 表连接，把结果输出到一个临时表，并按 part_num 排序：SELECT pv_by_vn，vendor.vendor_num FROM pv_by_vn，vendor WHERE pv_by_vn.vendor_num=vendor.vendor_num ORDER BY pv_by_vn.part_num INTO TMP pvvn_by_pn DROP TABLE pv_by_vn 这个查询读取 pv_by_vn(50 页)，它通过索引存取 vendor 表 1.5 万次，但由于按 vendor_num次序排列，实际上只是通过索引顺序地读 vendor 表（4

18、02=42 页），输出的表每页约 95 行，共 160 页。写并存取这些页引发 5160=800 次的读写，索引共读写 892 页。3把输出和 part 连接得到最后的结果：SELECT pvvn_by_pn.，part.part_desc FROM pvvn_by_pn，part WHERE pvvn_by_pn.part_num=part.part_num DROP TABLE pvvn_by_pn 这样，查询顺序地读 pvvn_by_pn(160 页)，通过索引读 part 表 1.5 万次，由于建有索引，所以实际上进行 1772 次磁盘读写，优化比例为 301。笔者在 Informix

19、 Dynamic Sever 上做同样的实验，发现在时间耗费上的优化比例为 51(如果增加数据量，比例可能会更大)。小结 20的代码用去了 80的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。我们的优化要抓住关键问题，对于数据库应用程序来说，重点在于 SQL 的执行效率。查询优化的重点环节是使得数据库服务器少从磁盘中读数据以及顺序读页而不是非顺序读页。人们在使用 SQL 时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的 性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理 OLTP 或决策支持系统 DSS）中表现得尤为

20、明 显。笔者在工作实践中发现，不良的 SQL 往往来自于不恰当的索引设计、不充份的连接条件和不可优化的 where 子句。在对 它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结：-为了更直观地说明问题，所有实例中的 SQL 运行时间均经过测试，不超过秒的均表示为（;19991201 and date;2000(25 秒)select date,sum(amount)from record group by date (55 秒)select count(*)from record where date;19990901 and place in(BJ,SH)(2

21、7 秒)-分析：-date 上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描 才能找到这一范围内的全部行。-2.在 date 上的一个群集索引 select count(*)from record where date;19991201 and date;2000（14 秒）select date,sum(amount)from record group by date （28 秒）select count(*)from record where date;19990901 and place in(BJ,SH)（14 秒）-分析：-在群集索引

22、下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的 起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。-3.在 place，date，amount 上的组合索引 select count(*)from record where date;19991201 and date;2000（26 秒）select date,sum(amount)from record group by date （27 秒）select count(*)from record where date;19990901 and place in(BJ,SH)（

23、;19991201 and date;2000(;19990901 and place in(BJ,SH)（;,;=,=）和 order by 、group by 发生的列，可考虑建立群集索引；-.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；-.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。二、不充份的连接条件：-例：表 card 有 7896 行，在 card_no 上有一个非聚集索引，表 account 有 191122 行，在 account_no 上有一个非聚集索 引，试看在不同的表连接条件下，两个 SQL 的执行情况：select sum(a.amo

24、unt)from account a,card b where a.card_no=b.card_no（20 秒）-将 SQL 改为：select sum(a.amount)from account a,card b where a.card_no=b.card_no and a.account_no=b.account_no（1 秒）-分析：-在第一个连接条件下，最佳查询方案是将 account 作外层表，card 作内层表，利用 card上的索引，其 I/O 次数可由以下 公式估算为：-外层表 account 上的 22541 页+（外层表 account 的 191122 行*内层表 c

25、ard 上对应外层表第一行所要查找的 3 页）=595907 次 I/O -在第二个连接条件下，最佳查询方案是将 card 作外层表，account 作内层表，利用 account上的索引，其 I/O 次数可由 以下公式估算为：-外层表 card 上的 1944 页+（外层表 card 的 7896 行*内层表 account 上对应外层表每一行所要查找的 4 页）=33528 次 I/O -可见，只有充份的连接条件，真正的最佳方案才会被执行。-总结：-1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳 方案。连接条件要充份考虑带有索引的表

26、、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查 找的次数确定，乘积最小为最佳方案。-2.查看执行方案的方法-用 set showplanon，打开 showplan 选项，就可以看到连接顺序、使用何种索引的信息；想 看更详细的信息，需用 sa 角色执行 dbcc(3604,310,302)。三、不可优化的 where 子句 -1.例：下列 SQL 条件语句中的列都建有恰当的索引，但执行速度却非常慢：select*from record where substring(card_no,1,4)=5378(13 秒)select*from record where amo

27、unt/30 1000（11 秒）select*from record where convert(char(10),date,112)=19991201（10 秒）-分析：-where 子句中对列的任何操作结果都是在 SQL 运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面 的索引；如果这些结果在查询编译时就能得到，那么就可以被 SQL 优化器优化，使用索引，避免表搜索，因此将 SQL 重写成 下面这样：select*from record where card_no like 5378%（1 秒）select*from record where amount 1000*30

28、（1 秒）select*from record where date=1999/12/01 （10000 和执行:select*from table1 where tID 10000 and name=zhangsan 一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果 tID 是一个聚合索引，那么后一句仅仅从表的 10000 条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个 name=zhangsan的，而后再根据限制条件条件 tID10000 来提出查询结果。事实上，这样的担心是不必要的。SQL SERVER 中有一个“查询分

29、析优化器”，它可以计算出 where 子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。虽然查询优化器可以根据 where 子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。SARG 的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的 AND 连接。形式

30、如下：列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：Name=张三 价格5000 50005000 如果一个表达式不能满足 SARG 的形式，那它就无法限制搜索的范围了，也就是 SQL SERVER 必须对每一行都判断它是否满足 WHERE 子句中的所有条件。所以一个索引对于不满足 SARG 形式的表达式来说是无用的。介绍完 SARG 后，我们来总结一下使用 SARG 以及在实践中遇到的和某些资料上结论不同的经验：1、Like 语句是否属于 SARG 取决于所使用的通配符的类型 如：name like 张%，这就属于 SARG 而：name like%张,就不属于 SARG

31、。原因是通配符%在字符串的开通使得索引无法使用。2、or 会引起全表扫描 Name=张三 and 价格5000 符号 SARG，而：Name=张三 or 价格5000 则不符合SARG。使用 or 会引起全表扫描。3、非操作符、函数引起的不满足 SARG 形式的语句 不满足 SARG 形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、!、NOT EXISTS、NOT IN、NOT LIKE 等，另外还有函数。下面就是几个不满足SARG 形式的例子：ABS(价格)5000 SQL SERVER 也会认为是 SARG，SQL SERVER 会将此式转化为：WHERE 价格2500/2

32、 但我们不推荐这样使用，因为有时 SQL SERVER 不能保证这种转化与原始表达式是完全等价的。4、IN 的作用相当与 OR 语句：Select*from table1 where tid in(2,3)Select*from table1 where tid=2 or tid=3 是一样的，都会引起全表扫描，如果 tid 上有索引，其索引也会失效。5、尽量少用 NOT 6、exists 和 in 的执行效率是一样的 很多资料上都显示说，exists 要比 in 的执行效率要高，同时应尽可能的用 not exists 来代替 not in。但事实上，我试验了一下，发现二者无论是前面带不带 n

33、ot，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用 SQL SERVER 自带的 pubs 数据库。运行前我们可以把 SQL SERVER 的 statistics I/O 状态打开：（1）select title,price from titles where title_id in(select title_id from sales where qty30)该句的执行结果为：表 sales。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。表 titles。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。（2）select title,price

34、 from titles where exists(select*from sales where sales.title_id=titles.title_id and qty30)第二句的执行结果为：表 sales。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。表 titles。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。我们从此可以看到用 exists 和用 in 的执行效率是一样的。7、用函数 charindex()和前面加通配符%的 LIKE 执行效率一样 前面，我们谈到，如果在 LIKE 前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的

35、。但有的资料介绍说，用函数 charindex()来代替 LIKE 速度会有大的提升，经我试验，发现这种说明也是错误的：select gid,title,fariqi,reader from tgongwen where charindex(刑侦支队,reader)0 and fariqi2004-5-5 用时：7 秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。select gid,title,fariqi,reader from tgongwen where reader like%+刑侦支队+%and fariqi2004-5-5 用时：7 秒，另外：扫描计数

36、 4，逻辑读 7155 次，物理读 0 次，预读 0 次。8、union 并不绝对比 or 的执行效率高 我们前面已经谈到了在 where 子句中使用 or 会引起全表扫描，一般的，我所见过的资料都是推荐这里用 union 来代替 or。事实证明，这种说法对于大部分都是适用的。select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16 or gid9990000 用时：68 秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。select gid,fariqi

37、,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16 union select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid9990000 用时：9 秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。看来，用 union 在通常情况下比用 or 的效率要高的多。但经过试验，笔者发现如果 or 两边的查询列是一样的话，那么用 union 则反倒和用 or的执行速度差很多，虽然这里 union 扫描的是索引，而 or 扫描

38、的是全表。select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16 or fariqi=2004-2-5 用时：6423 毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16 union select gid,fariqi,neibuyonghu,reader,title from Tgongwen where

39、 fariqi=2004-2-5 用时：11640 毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。9、字段提取要按照“需多少、提多少”的原则，避免“select*”我们来做一个试验：select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc 用时：4673 毫秒 select top 10000 gid,fariqi,title from tgongwen order by gid desc 用时：1376 毫秒 select top 10000 gid,fariqi f

40、rom tgongwen order by gid desc 用时：80 毫秒 由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。10、count(*)不比 count(字段)慢 某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：select count(*)from Tgongwen 用时：1500 毫秒 select count(gid)from Tgongwen 用时：1483 毫秒 select count(fariqi)from Tgongwen 用时：3140 毫秒 select

41、 count(title)from Tgongwen 用时：52050 毫秒 从以上可以看出，如果用 count(*)和用 count(主键)的速度是相当的，而 count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。我想，如果用count(*)，SQL SERVER 可能会自动查找最小字段来汇总的。当然，如果您直接写 count(主键)将会来的更直接些。11、order by 按聚集索引列排序效率最高 我们来看：（gid 是主键，fariqi 是聚合索引列）：select top 10000 gid,fariqi,reader,title from tgon

42、gwen 用时：196 毫秒。扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc 用时：4720 毫秒。扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc 用时：4736 毫秒。扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。select to

43、p 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc 用时：173 毫秒。扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc 用时：156 毫秒。扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。从以上我们可以看出，不排序的速度以及逻辑读次数都是和“order by 聚集索引列”的速度是相当的，但这些都比“order by 非聚集索引列”的查

44、询速度是快得多的。同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。12、高效的 TOP 事实上，在查询和提取超大容量的数据集时，影响数据库响应时间的最大因素不是数据查找，而是物理的 I/0 操作。如：select top 10*from(select top 10000 gid,fariqi,title from tgongwen where neibuyonghu=办公室 order by gid desc)as a order by gid asc 这条语句，从理论上讲，整条语句的执行时间应该比子句的执行时间长，但事实相反。因为，子句执行后返回的是 10000 条记

45、录，而整条语句仅返回 10 条语句，所以影响数据库响应时间最大的因素是物理 I/O 操作。而限制物理 I/O 操作此处的最有效方法之一就是使用TOP 关键词了。TOP 关键词是 SQL SERVER 中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现 TOP 确实很好用，效率也很高。但这个词在另外一个大型数据库 ORACLE 中却没有，这不能说不是一个遗憾，虽然在 ORACLE中可以用其他方法（如：rownumber）来解决。在以后的关于“实现千万级数据的分页显示存储过程”的讨论中，我们就将用到 TOP 这个关键词。到此为止，我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然，我们介绍的这些方法都是“软”方法，在实践中，我们还要考虑各种“硬”因素，如：网络性能、服务器的性能、操作系统的性能，甚至网卡、交换机等。