华中科技大学
硕士学位论文MySQL查询优化的研究和改进
姓名：孙辉
申请学位级别：硕士
专业：计算机软件与理论指导教师：吴恒山
20070606
摘要
查询是数据库系统中最基本也是最常用的一种操作，因此查询是否具有较快的执行速度，已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL查询优化技术的基础上，主要从MySQL配置参数调优，MySQL查询重用功能，MySQL查询重写的相关规则，MySQL计划优化四个方面展开工作。
针对配置参数调优问题，主要从数据缓冲区和日志缓冲区两方面详细介绍了MySQL相关的调优参数。然后研究了MySQL调优的两种方法：人工调优和基于案例的调优，并在此基础上提出了一种动态的自调优算法－爬山法，该方法有效解决了MySQL自身两种调优方法存在的不足。
对于查询重用问题，主要针对MySQL重用实现存在的两个问题：重用性不高和不能合理处理大数据集，做出了改进。对于前者，通过增加规范SQL语句关键字和消除多余无效字符的模块来解决。对于后者，通过增加缓存查询执行计划模块来解决，使用缓存查询计划模块来代替MySQL原本的缓存查询结果模块。
对于查询重写问题，在研究MySQL现有查询重写技术的基础上，以带IN谓词的子查询为例归纳了其子查询合并的算法，然后提出了两个查询重写规则，NOT操作符重写和外连接转换为一般连接。通过重写，确实提高了MySQL查询的速度。
针对计划优化问题，主要研究了MySQL基于规则的优化和基于代价的优化这两种方法。对于前者，详细的介绍了MySQL预定义的一些连接类型及其优先级，对于后者，研究了MySQL在决定表连接顺序时所采用的贪婪算法的具体实现。
所有的实验都是采用TPCH标准测试，数据量为10M，实验对改进工作进行了验证，实验结果表明我们的改进工作确实提高了MySQL的查询速度。
关键词：查询优化，查询重用，查询重写，计划优化
Abstract
Query is one of the basic and commonly using operations in DBMS. So whether the query has the fast execution speed has become a core problem for the users and designers of DBMS. We mainly focus on four main problems: MySQL parameters self-tuning, realization of MySQL query reuse, MySQL query transform and the optimization of query execution plan in the base of the research on the open source DBMS of MySQL.
For the problem of parameters tuning, we focus on the data buffer and log buffer to introduce some tuning parameters of MySQL. And we introduce two tuning ways of MySQL:manual tuning and based on cases tuning, Then we will propose a new dynamic self-tuning methods—mountain algorithm and it solves the former fault.
In the problem of query reuse, we aim at two problems—poorly reuse and unable to deal with big result situation in the MySQL and do some improvements. For the former, we add two functions to normalize the key words and remove some invalid and redundant characters in the SQL statements. For the latter, we buffer the query execution plan instead of buffering the query result by adding execution plan buffer module.
For the problem of query rewrite, we deduce the algorithm of sub-query merging.Then, we add two rewrite rules—NOT operation rewrite and Outer join transforms to normal join. By the transforming, the query execution speed really becomes fast.
For the problem of plan optimization, we mainly focus on two problems—base on rule optimization and base on cost optimization. For the former, we introduce some redefine join types and their priority. For the latter, we present the greedy algorithm which decides the order of tables.
All the experiments base on the benchmark test—TPCH and the test data size is 10M. The experimental results obtained from the tests indicate that our work really effectly improve the speed of queries in MySQL.
Key words：Query optimize, Query reuse, Query transform, Plan optimization
独创性声明
本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到，本声明的法律结果由本人承担。
学位论文作者签名：
日期：2007年 6月 6日
学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
保密□，在_____年解密后适用本授权书。
本论文属于
不保密□。
（请在以上方框内打“√”）
学位论文作者签名：指导教师签名：
日期： 2007年 6 月 6 日日期：2007年6 月 6 日
1 绪论
1.1 课题背景
本课题来源于国家863数据库重大专项“大型通用数据库管理系统DM5的研究开发及其应用”中的一个子项目。该子项目要求对MySQL的查询优化器及其实现技术进行分析和改进，指导国产数据库管理系统DM5的查询优化器的设计和实现。
高效地管理大批量数据对于大多数的计算机应用领域都是至关重要的。数据库管理系统(Database Management System，DBMS)是使得单个或多个用户可以方便有效地管理并操纵大量数据的系统软件，它作为数据处理和管理的标准工具，已经逐步成为现代信息系统的基础和核心。
数据库管理系统软件是数据处理的核心，国防、政府、金融等要害部门对自主安全的数据库管理系统提出了非常迫切的要求。因此发展国产数据库管理系统软件，将对我国软件产业及其相关产业发挥重大影响。在此背景下，武汉华工达梦数据库有限公司经过努力，研发出拥有完全自主版权的DM系列数据库管理系统软件。
关系数据库系统的一个主要功能就是使用户通过强大的关系查询语言访问和修改数据库中的数据。查询是数据库系统中最基本和常用的一种操作，查询是否具有较高的执行速度，已成为数据库用户和设计者极其关心的问题。为了提高数据库系统的性能，对查询进行优化是必不可少的，现今大型商业数据库管理系统的成功很大程度上要归功于查询优化技术的发展和应用。查询优化是数据库系统中一个极为关键的技术问题，历来都是研究的热点问题[1, 2]。
MySQL是一个基于SQL的C/S模式关系数据库管理系统，凭借其易用性，可移植性，高可靠性，优异的联网和安全性得到越来越多用户的青睐[3, 4]。更难能可贵的是MySQL是一个完全开源的系统，任何人和组织都可以获得它用于非商业用途。其公开的源代码和较为详细的用户手册为数据库技术的进一步研究提供了便利。
本课题的目的和意义在于通过对MySQL查询优化器的研究，特别是针对其查询优化的实现技术进行分析、改进和实验，从而为DM5等国产数据库管理系统中查询优化器的设计和实现提供一定的指导和参考。
1.2 国内外概况
1.2.1 查询优化相关技术的研究概况
目前查询优化研究的主要内容有以下几个方面：
1．数据库配置参数调优方法的研究
传统数据库系统参数的调优主要采用人工调优的方法。数据库系统要求数据库管理员(Database Administrators, DBA)和应用开发人员做大量的人工调节，才能使数据库的性能保持良好。主要是由数据库管理系统向DBA提供一些可调的资源参数，DBA根据自己的经验和当前的负载特征调整这些参数，以达到优化性能的目的[5, 6]。但这种方法具有低效率和盲目性的缺点，并且对DBA和应用开发人员的水平提出了比较高的要求。某些数据库厂商在经过大量实验和具体实际应用案例的基础上，总结了一些典型应用案例情况下数据库参数的推荐配置值，从而为用户的调优工作提供了一定的参考和借鉴，这种方法称为基于案例的调优方法[7, 8]。基于案例的方法不是利用以前解决问题得出的规则，而是运用以前解决问题的实际案例结果来解决问题。但它过于模板化，忽略了实际应用项目之间的差异，不容易推广。针对上述两种方法存在的缺点，目前有人正在进行动态自调优方法的研究[9]。利用DBMS提供的一些可调参数和选项(如同时使用数据库的用户数目，缓冲区分配参数、工作线程的数目、锁的数目等)来驱动动态自调优的算法。优化的配置是在调整过程中动态找到的，期望能够用高效的自动调优方法代替传统的人工调优和基于案例调优的方法。
2．查询重用方法的研究
查询重用对于优化查询性能的意义非常重大。相同模式的查询语句一般具有相同的优化结果，相同模式的查询语句只需作一次语法分析和优化，甚至只需要执行一次(若前后两次的查询语句完全相同)。为了避免多次的语法分析和优化过程，有必要对这些查询语句进行缓冲，查询重用缓冲机制有效的解决了这个问题[10,11,12]。
目前查询重用主要有两类方法的研究：
(1) 查询执行结果的重用
查询重用缓冲区缓存了查询语句的文本字符串和执行结果集，当数据库服务器接收到相同的SQL语句时，直接将缓存的该SQL语句的执行结果集发送给用户。
(2) 查询执行计划的重用
查询重用缓冲区缓存的是查询的语法树和执行计划，当数据库服务器接收到相
同的SQL语句时，从缓存中取出该语句的语法树和查询执行计划，然后执行该语句并将查询结果发送给用户。
3．查询重写规则的研究
查询重写是现代数据库系统在查询处理方面所采用的一项先进技术，它将一个查询语句根据一定的规则，转换为另一个效率更高或更易于优化的查询语句。八十年代IBM Almaden研究中心开发的可扩充数据库原型系统Starburst[13]，首次采用了这一新的查询优化技术。
目前的研究工作主要集中于以下四大方面[14,15]：
(1) 视图重写技术
视图重写就是将对视图的引用重写为对视图基本表的引用，可以方便优化器做进一步的优化处理。若没有此重写功能，查询优化器所能生成执行计划的唯一选择就是先执行视图定义，再将视图的查询结果作为临时表参与查询的其余处理，这种处理方式在绝大多数情况下效率极低。
(2) 子查询的合并技术
子查询的合并就是将某些特定的子查询重写为多表的连接查询。一般来讲，计划优化只对同一层次上的查询所生成的计划进行评估和优化。子查询合并的作用在于将查询语句的层次尽可能的减少，从而方便计划优化的处理。
(3) 等价谓词重写技术
由于具体数据库执行引擎对各种谓词的处理方法不同，某些谓词处理效率要高于其它谓词，因此把逻辑表达式重写成等价的且效率更高的形式，是提高查询执行效率的有效方法。
(4) where和having条件化简技术
由于where和having条件经常由许多表达式组成，而这些表达式在某些时候并不是孤立的，它们彼此之间存在一定的联系。因此利用等式和不等式的性质，可以将where和having条件化简。
如何改进这些模块现有查询重写规则的算法效率，如何发现更多更有效的重写规则，是当前查询优化的主要热点研究内容之一[16,17]。
4．查询优化算法的研究
对于优化算法的研究仍然是查询优化研究的一个难点和重点。在关系数据库系统中，最难处理和优化的一个逻辑操作符是连接JOIN[18,19]。由于多个关系连接时可
以有很多不同的连接次序，因此对应于查询的执行计划的数目会随着该查询包含的关系个数呈指数级增长，当关系个数很多时，将会导致搜索空间极度膨胀。传统的数据库管理系统大多采用的是基于SYSTEM R的空间搜索算法或其变形算法，这些都是近乎于穷举的搜索算法。在决策支持系统中，由于查询所涉及的关系数目通常都非常大，使得这类穷举的搜索算法往往无能为力。一个典型的例子就是Postgres[20]，德国弗来堡矿业及技术大学自动控制系的研究员在试图将Postgres DBMS作为用于电力网维护中做决策支持的知识库系统的后端时，遇到了上面的问题。现在的查询优化通常都引入了启发式搜索算法或随机算法处理关系数目比较多的情况[21,22]。
5．扩宽查询优化的研究对象
传统的联机事务处理(On-line Transaction Processing，OLTP)应用中，大量使用基于选择(SELECT)，投影(PROJECT)，连接(JOIN)三种基本操作相结合的查询，我们称作SPJ查询。因此，过去的研究重点大部分都集中于SPJ查询的优化上[23]。但伴随着在线分析处理(On-line Analytical Processing，OLAP)和决策支持系统(Decision Support System，DSS)等广泛应用，越来越多的非SPJ查询出现在这些应用之中。例如在决策支持系统中使用的查询，很大一部分都是带有GROUP BY子句的查询，因此高效合理地处理带有GROUP BY聚组函数的查询具有特别的意义。而传统的基于SPJ的查询在处理此类问题时没有考虑到聚组等非SPJ查询的特征，往往不太有效，当和一个由非SPJ查询构成的视图连接时，处理起来就更加低效[24]。现在的研究表明，可以对非SPJ查询进行转换，将非SPJ操作提前或推迟处理(称为GROUP BY节点的PUSH DOWN, PULL UP技术)，由于非SPJ操作可以大幅度的减少中间结果的大小，这种处理方式可以极大的提高效率。采用这种技术，同时还可以处理一些涉及到非SPJ定义的视图的合并操作[24,25]。
6．并行查询的优化
现代数据库应用的发展，企业组织不断增长的大量数据，使得高性能的并行机或分布式系统逐步取代传统的大型机进行大型数据库的管理和事务处理。但传统的查询优化技术并没有考虑到并行特性，从而不能最大限度的发挥并行机或分布式系统的能力。因此当前的查询优化也把并行查询的优化问题作为研究的重点，并行查询引入了以下的问题：
(1) 代价模型的评估。由于查询是并行执行的，因此代价模型会更复杂，因为不仅要考虑到传统的CPU+I/O代价，而且还要将划分的代价，偏斜和竞争资源等代价
都要考虑进去[26]。
(2) 计划空间搜索算法的改进。并行执行计划的引入将大大增加执行计划的计划空间，因此，通过考虑所有的候选计划来优化并行查询比优化串行查询的代价要高得多。所以，通常采用启发式的方法来减少需要考虑的并行执行计划的数目[27]。
(3) 并行执行计划的表示。并行执行计划的表示在一定程度上也决定了执行计划是怎样被并行执行的。例如，对于共享内存和无共享的这两种不同的并行数据库管理系统体系结构，在某种条件下，可以考虑其表示是否可以合并在一起。
1.2.2 国内外数据库产品查询优化技术的实现概况
本小节介绍目前国内外商用数据库管理系统中的查询优化技术。
1．Oracle的查询优化技术
在配置参数调优方面，除了传统的人工调优和基于案例的调优方法，Oracle还在数据库服务器上引入了一套复杂的自管理系统，该系统允许数据库自我收集数据，并利用这些数据自动调节环境参数或者自动修复潜在的问题，这个特性是使得Oracle 成为目前唯一一个智能化的自管理和自调优的产品。
在查询重用方面，Oracle采用了查询执行结果的重用和查询执行计划的重用相结合的方式[29,30]。
Oracle支持的一些主要的查询重写和转换有：
(1) 视图重写合并：即将查询中视图的引用用视图定义所代替，但这种转换并不对所有的视图适用。
(2) 子查询的整平：即通过一系列的转换将不同种类的子查询转变为连接半连接或者反连接。
(3) 物化视图的重写：Oracle具有自动重写查询的能力，以利用物化视图的优点。若查询中的某个部分可以与一个已存在的物化视图匹配，那么Oracle能够用建立该物化视图的基表的应用来替代这个部分。
(4) 星形转换：即Oracle支持依据星形模式的查询估算。
Oracle支持的计划优化为：Oracle有一个基于代价的优化器决定连接顺序，连接方法以及访问路径。优化器选取的每个操作都有一个相应的代价函数，优化器总是试图产生总体代价最小的操作组合。在优化器的代价模型中，Oracle同时使用CPU ＋磁盘I/O的代价模型。为了平衡这两者，优化器保存了CPU速度和磁盘I/O性能
的度量，作为优化器统计数据的一部分，Oracle收集优化器统计数据的软件包负责计算这些度量的标准。
2．IBM DB2的查询优化技术
在配置参数调优方面，DB2主要实现了传统的人工调优和基于案例的调优方法，它在动态自调优方面目前技术还不成熟，没有成型的产品。
在查询重用方面，IBM DB2也采用了查询执行结果的重用和查询执行计划的重用相结合的方式[29,30]。
IBM DB2支持的一些主要的查询重写和转换如下：(1) 子查询变为连接的转换；
(2) 分组操作下推到连接以下；(3) 利用物化视图或汇总表(使用聚集的物化视图)来重写查询。
DB2有一个基于代价的优化器决定连接顺序，连接方法以及访问路径。优化器可以配置成能在不同级别的复杂度上进行操作。在最高级，它使用一个动态程序设计算法来考虑所有的查询技术，并选择其中代价最小的查询计划。在中级，优化器不考虑特定的计划或访问方法(或索引)，也不考虑一些重写规则。在最低级中，优化器采用贪婪算法来选择一个好的但不一定最佳的查询计划。DB2也是同时使用CPU ＋磁盘I/O的代价模型。优化器使用查询处理的细节模型(考虑内存大小和预取这样的细节)来获取对CPU和I/O的开销的准确估计。
3．国产数据库查询优化技术的现状
由于国内对数据库技术的研究起步较晚，国产的数据库系统比较少，对查询技术的研究和应用相对国外的技术来说还不是成熟，但也有一些国产数据库产品已经使用了查询优化技术[31-34]，其中最有代表的产品是东软的OpenBASE 系列和武汉华工达梦数据库有限公司的DM 系列。在配置参数调优方面，两者仅仅实现了传统的人工调优方法。在查询重用方面，两者采用了查询执行计划的重用的方式，而没有实现查询结果重用方式。OpenBASE没有考虑查询重写，针对计划优化在搜索执行计划时采用了近乎穷举的方法，因此在处理大量表连接时效率往往会比较低下。DM 采用了查询重写和计划优化相结合的方式，但DM查询重写模块比较简单，仅仅实现了一些基本的查询重写功能，另外计划优化的代价评估模型仅仅只考虑了I/O开销，还不完善，因此在处理一些比较复杂的查询时效率可能会很低。
1.3 课题主要研究工作
本课题将在研究MySQL源代码的基础上，主要从配置参数的调优，查询重用技术，查询重写技术和计划优化这四个方面来展开工作。在研究MySQL查询优化技术实现的基础上，做出一定的改进，从而为DM5等国产数据库管理系统查询优化器的设计和实现提供一定的参考。本课题的主要工作包括下面几个方面。
1．MySQL配置参数调优的研究和改进
主要准备从MySQL的调优参数和调优方法两方面来展开研究工作。前者，主要从数据缓冲区和日志缓冲区两方面详细介绍相关的MySQL调优参数。后者，介绍MySQL参数调优的两种方法，人工调优和基于案例的调优方法，并在此基础上将提出一种动态自调优算法－爬山法，期望解决MySQL自身调优方法存在的不足。最后，将通过实验验证人工调优和动态自调优对MySQL查询执行速度的影响。
2．MySQL查询重用的研究和改进
在研究现有MySQL查询重用部分具体实现的基础上，针对MySQL实现存在的两个问题：重用性不高和不能合理处理大数据集，准备进行改进。前者，通过增加规范化SQL语句关键字和消除多余的无效字符模块解决。后者，通过增加缓存查询执行计划功能模块解决，使用缓存查询计划代替MySQL原本的缓存查询结果模块。这两个模块均将给出相应的算法实现。最后，将通过实验验证改进后的MySQL查询重用模块对查询执行速度的影响。
3．MySQL查询重写的研究和改进
在介绍MySQL查询重写的基础上，以带In谓词的子查询为例，归纳MySQL 的子查询合并算法，然后提出两个查询重写规则，NOT操作符重写和外连接转换为一般连接的重写，并给出这两个重写规则的算法实现。最后，将通过实验验证这两个重写规则对MySQL查询执行速度的影响。
4．MySQL计划优化的研究
这部分准备从基于规则的优化和基于代价的优化两方面来展开工作。前者，通过详细介绍MySQL预定义的一些连接类型及其优先级，后者，将归纳MySQL在决定表连接顺序时所采用的贪婪算法的具体实现。
所有的实验都将采用TPCH标准测试，数据量为10M，实验机器为P3 800Hz,256MB内存。通过实验将验证改进工作对于MySQL的查询执行速度的影响。
2 MySQL配置参数调优的研究和改进
本章研究MySQL配置参数调优的问题。首先简要介绍配置参数调优的意义。然后从数据缓冲区和日志缓冲区两方面介绍MySQL调优参数，研究了其调优的两种方法：人工调优和基于案例的调优，并在此基础上提出一种动态自调优算法－爬山法。最后利用实验验证人工调优和动态自调优对MySQL查询性能的影响。
2.1 配置参数调优的意义
影响MySQL数据库系统性能效率的因素很多，涉及服务器硬件、网络结构、操作系统、MySQL数据库系统实现本身采用的算法和数据结构、应用系统、并发用户数和系统环境配置等[3]。而其中最简单和直观改进数据库性能的方法就是调整数据库的配置参数。
MySQL的配置参数在安装到系统后使用的都是默认值。有些默认值不能充分利用系统的资源，如join_buffer_size(执行笛卡尔积连接操作时分配给表的缓冲区)，在执行没有索引的大表连接应用时，该变量的默认值128kB就显得太小了。还有一些参数的默认值设置不合理，如参数query_cache_size(存放查询执行结果的缓冲区)缺省的默认值为0，表示禁用查询重用的功能，即不缓存查询执行结果。服务器再次接收到相同的查询时，就不能利用查询重用的优点来提高查询的速度。因此根据实际数据库系统运行的负载情况，进行相应的数据库配置参数调优，可以有效的减少磁盘I/O操作，对于优化查询执行的速度有重大的意义。
2.2 调优参数的选择和介绍
选取适当的调整参数是数据库性能调优的关键一环。首先要选择对系统性能影响较大的参数，同时要选择彼此间影响较小的参数，如果有的参数选取不当，造成调整抖动，将不利于性能的调整。
对于参数调优研究的许多成果为我们如何进行调整提供了依据和思路。这些文章虽各有侧重点，但都不约而同的将影响DBMS性能的问题集中在：内存管理、缓冲区分配、锁控制、索引的建立和物理视图的设计等方面。
Brown等人研究了自动内存管理[35]。重点说明了用户事务模型和缓冲池的内存
分配之间的关系，并实现了当所有负载和调整目标都明确时，发现缓冲池配置问题的方法。
Xu等人将内存自动管理问题当做缓冲池的配置[36]。他们认为内存管理的关键是如何将表和索引放入缓冲池，因此着重讲述如何合理分配缓冲区以放置表和索引的方法。
Chaudhuri 和Narasayya通过观测DBMS查询优化的自动统计来进行动态资源分配[37]。DBMS根据数据的存储位置来决定其查询计划，重点讲述数据的存放对查询优化的影响。
本文主要选择和介绍MySQL内存缓冲区相关调优参数。MySQL的内存缓冲区从结构上主要可分为数据缓冲区和日志缓冲区两大部分。
2.2.1 数据缓冲区
数据缓冲区是MySQL在将数据块(包含数据表，索引和数据字典等)写入磁盘之前以及从磁盘块读取数据之后，数据块所存储的地方。这是MySQL至关重要的内存区域之一，若将其设置的太小，会导致缓冲块命中率低，磁盘I/O操作特别频繁；若设置的太大，又会造成与操作系统本身的内存争用，导致系统效率低下，因此合理的设置其大小非常重要。下面是几个在数据缓冲区中影响查询性能的参数：1．key_buffer_size
索引缓冲区，它的空间为所有数据库共享，最大值可以设置为4GB，实际值最好设置为空闲内存的25%左右。该变量的缺省默认值为8MB。
2．join_buffer_size
全连接缓冲区。在执行笛卡尔积全连接操作时，系统为每个参与连接的表分配的缓冲区大小。若应用涉及到大量的多表连接操作，且没有适合的索引可用，要进行笛卡尔积操作时，应该增大该缓冲区的大小。该变量的缺省默认值为128KB。
3．read_buffer_size
全表扫描缓冲区。若要对数据库表进行全表扫描操作，数据库系统此时就为每张表分配该缓冲区。该参数的默认值为60KB。
4．sort_buffer_size
排序缓冲区。系统为ORDER BY和GROUP BY操作分配的缓冲区大小。该参数的默认值为256KB。
5．tmp_table_size
临时表缓冲区。针对生成物理查询计划或排序归并连接时，可能要用到一些临时表。该参数的默认值为20MB。
6．query_cache_size
重用查询执行结果缓冲区，用来控制MySQL查询重用功能。若启动该功能，MySQL服务器接收到相同查询时，可以直接将缓存在缓冲区中的查询结果发送给客户。该参数的默认值为0，表示禁用该缓存查询结果的功能。显然这是不合理的，需要根据实际情况进行调整。
2.2.2 日志缓冲区
日志缓冲区是MySQL专门开辟的一段内存用来存放日志文件的。当日志写满了后，它会要求I/O操作将日志内容写回磁盘中，因此为了减少不必要的磁盘I/O操作，适当的调整日志缓冲区的大小是非常有意义的。下面我们介绍几个在日志缓冲区中与查询性能相关的几个参数：
1．binlog_cache_size
更新日志缓存区大小。若应用涉及到包含许多复杂SQL语句的更新事务时，增大其大小，可以有效的避免多次的I/O操作。该参数的默认值为32KB。
2．sync_binlog
日志同步的频率。一般为了避免频繁的日志同步更新，都将该值尽可能的设置为比较大的常数N，表明在写了N次更新日志时再将其写回磁盘中。该参数的默认值为0，表示只有当内存中的日志文件写满后，再将其写回磁盘中保此同步。
当然，影响数据库性能的参数远远不止这些。例如还有应用程序的堆栈分配空间，线程空间分配，连接数据库的句柄数目，检查点时间间隔的选择，锁的数目等，但是它们对MySQL数据库查询优化方面的影响不如上面详细介绍的几个因素。
2.3 MySQL参数调优方法的研究和改进
2.3.1 调优方法的研究
MySQL实现了人工调优和基于案例的调优这两种方法[3,4]。
1．MySQL的人工调优
MySQL提供了一些可调参数，由DBA在DBMS的维护中或在应用程序运行过
程中手动进行调整。一般情况下通过调整资源配置参数，可以达到性能调优的目的。但由于调整负载不同、软硬件平台不同以及DBA水平的千差万别，这种手动调整难以推广，效率低，需要DBA具有较高的水平，但就目前而言，这种调优方法仍然是一种最为常见且应用较为广泛的方法。
2．MySQL的基于案例的调优
基于案例的方法是一种利用已成功解决问题的经验解决新问题的方法，基于案例的方案不是利用以前解决问题得出的规则，而是运用了以前解决问题的实际案例结果来解决问题。MySQL官方通过大量实验和实际应用案例，提供了在五种标准情况下，相应的MySQL服务器配置参数的推荐值。
2.3.2 调优方法的改进
在实际的DBMS系统中，有太多的资源需要考虑，它们之间的关系也过于复杂，现实的应用系统往往也千差万别。人工调优主要依赖于人，效率往往比较低下，基于案例的调优忽略了系统的动态性和不同系统间存在的差异，单纯的依赖人工调优和基于案例的优化方法是不够的。因此这里提出一种动态的自调优算法－爬山法来解决前两种方法存在的不足。
设H(h1,h2,h3)是一个参数向量，其中h1，h2，h3分别是影响数据库服务器性能的三个可调节参数。每个参数都应该有一个最小值和最大值，因此对该参数进行调优时只能在这两个值范围之间进行调整。假设每一次参数的变化调整都取当前参数的一个相邻值，即只能将该参数上调一个单位或者下调一个单位。并且假定一次只调整一个参数，而不能同时调整多个参数。下面通过一个例子来说明这一点。
设有参数向量V=(C1,C2,C3)，参数C1的取值范围为0，1，2；参数C2的取值范围为1，2；参数C3的取值范围为9，10，11。假设参数向量V的当前取值为V=(1,2,11)，那么能够调整的方法有：调整参数C1时，可以将参数向量调整为V=(0,2,11)或V=(2,2,11)；调整参数C2时，可以将参数向量调整为V=(1,1,11)；调整参数C3时，可以将参数向量调整为V=(1,2,10)或V=(1,2,9)。
在不断调整参数的过程中，我们也在不断的评估此时数据库服务器的性能。一种最简单的方法就是让数据库服务器在每调整一次参数完毕后就执行相同的SQL语句，通过观察SQL语句执行时间的变化来评价数据库服务器性能。一般服务器的配置列表涉及到的参数非常多，可以从中选择几个对查询执行影响最大的参数组成待
调整参数向量，进行相关的自调优，下面是该算法的具体实现：
算法2.1：动态调优爬山法
输入：当前配置列表，待调整参数向量和向量中相应每个参数的取值范围输出：最优配置列表
算法描述：
step 1: 用当前配置列表初始化最优配置列表；
step 2：设数据库服务器性能提高标志flag为否；
step 3： do
{ 若性能提高标志flag为否;
最高评估性能 = 当前的评估性能;
step 4： for(i = 1;i <=n; i++)
{
step 5：if (第i个待调整参数向下移动一个单位还没越界)
{
if(移动后的评估性能>最高评估性能)
{
最高评估性能= 当前评估性能；
将当前配置列表相应的该参数值下移一个单位；
最优配置列表 = 当前配置列表；
性能提高标志flag赋为真；
}
}
step 6：else if (第i个待调整参数向上移动一个单位还没越界)
{
if(移动后的评估性能>最高评估性能)
{
最高评估性能= 当前评估性能；
将当前配置列表相应的该参数值上移一个单位；
最优配置列表 = 当前配置列表；
性能提高标志flag赋为真；
}
}
step 7：else ;
}
step 8: while(已经达到了最高性能)
step 9: return 最优配置列表;
这种动态的自调优方法，由于在运行过程中不需要人工的干预，解决了人工调优低效的问题，并且它是根据当前服务器的性能进行动态调优的，解决了基于案例的调优忽略系统动态性的问题。因此它解决了MySQL自身两种调优方法存在的不足。
2.4 实验测试和分析
在这里进行调优实验测试，验证参数调优前后对于MySQL查询执行速度的影响。本实验选取TPCH标准测试的Q4，Q7和Q12三个语句进行测试，做三个实验。实验1人工调整参数的默认值，为了简化调优过程和便于观察结果，这里只选择key_buffer_size，read_buffer_size和sort_buffer_size三个参数进行调整，验证人工自调优对查询执行速度的影响。实验2和实验1类似，只不过我们采用了算法2.1对参数进行动态调整，验证动态自调优－爬山法对查询执行速度的影响。实验3中只调整参数query_cache_size的值，即单独测试缓存查询结果对查询优化速度的影响。其中每个测试用例都单独执行5次，这里显示的执行时间表示5次执行时间的平均值。具体测试用例的详细说明可以参考附录。
1．实验1结果及其分析
表2.1 实验1配置参数的取值
参数key_buffer_size read_buffer_size sort_buffer_size 缺省默认值8MB64KB256KB 人工调优后的值30MB8MB16MB
表2.2 实验1人工自调优前后语句执行时间对比
测试用例Q4Q7Q12
调优前0.0425s0.0575s0.6900s
调优后0.0325s0.0350s0.4050s
分析：由上面实验1结果分析可知，经过人工调优后Q4、Q7和Q12语句的查询执行速度都有不同程度的提高。因此即使在数据量不大(本实验测试数据仅为10M)的情况下，通过调整配置参数，可以达到比较好的优化查询的效果。
2．实验2结果及其分析
实验2利用算法2.1来动态调整配置参数的值，假设参数key_buffer_size取值为[4MB,32MB]，调整单位为512KB，read_buffer_size取值为[64KB,4MB]，调整单位为256KB，sort_buffer_size取值范围[256KB,2MB]，调整单位为64KB。
这三个参数的缺省配置值即为动态自调优过程的初始值。实际上，这些参数的取值范围和调整单位可以根据实际的应用情况进行进一步的调整。为了保证能够退出动态自调优过程，算法2.1在实现时设置了一个计数器。
表2.3 实验2配置参数的取值
参数key_buffer_size read_buffer_size sort_buffer_size 缺省默认值8MB64KB256KB 动态调优后的值4MB832KB320KB
表2.4 实验2动态自调优前后语句执行时间对比
测试用例Q4Q7Q12
调优前0.0425s0.0575s0.6900s
调优后0.0240s0.0320s0.4050s 分析：由上面实验2结果分析可知，经过动态自调优后Q4、Q7和Q12语句的查询执行速度都有不同程度的提高。因此即使在数据量不大(本实验测试数据仅为10M)的情况下，通过动态调整配置参数，可以达到比较好的优化查询的效果。将实验2和实验1进行比较，我们发现动态自调优可以根据查询语句实际的情况和当前系统的动
态负载，合理地调整相应的配置参数值，避免了DBA 调整时的盲目性和低效率。而
且实验2的结果同时显示，动态自调优对查询速度的提升往往好于人工自调优，而且
使用更少的系统资源就能达到较好的优化效果。
3．实验3结果及其分析
在进行实验3之前，假设MySQL 数据库服务器已经缓存了Q4，Q7，Q12这三个
语句的文本字符串和相应的查询结果集。
表2.5 实验3中参数的取值
表2.6 实验3调优前后语句执行时间对比 Q4语句 Q7语句 Q12语句 测试用例
测试1 测试2 测试1 测试2 测试1 测试2 执行时间 0.04s 0.00s 0.06s 0.00s 0.69s 0.00s
分析：由实验3结果分析可知，测试1将query_cache_size 参数设置为0，分别执行
Q4、Q7和Q12语句时，由于禁用了查询重用功能，因此不能利用已经缓存的执行结
果，故执行时间不为0。测试2中将query_cache_size 参数设置为30M ，打开查询重用功能，因此可以利用缓存了的Q4、Q7和Q12语句及其执行结果集，故查询执行时间
为0。因此在MySQL 服务器启动时，开启查询重用功能，对于某些需要多次重复执行
相同语句的应用，可以达到比较好的优化查询的效果。
通过上面的分析和实验比较可知，合理调整MySQL 的配置参数，对于查询优化
可以起到比较好的效果，而且这种方法也比较容易和直观。具体实施时还可以利用
windows 操作系统自带的任务管理器和MySQL 自带的性能诊断工具如mysqlshow 等
来帮助我们分析此时MySQl 服务器的相关状态和各个相关配置参数的使用情况。因
此这种方法，应该作为我们进行查询优化时最先采取的措施和手段，也是比较有效
和最直接的手段。
参数 query_cache_size 缺省默认值 0 改变后的值 30MB
2.5 本章小结
本章主要研究MySQL配置参数调优问题。首先介绍了配置参数调优的意义。接着主要从数据缓冲区，日志缓冲区两方面详细介绍了6个MySQL的相关调优参数。然后研究了MySQL调优的两种方法，人工调优和基于案例的调优，分析了各自的优缺点，并在此基础上提出了一种动态自调优算法－爬山法，给出了该算法的具体实现，该算法有效的解决了人工调优和基于案例的调优方法存在的不足。通过实验验证了人工调优和动态自调优对MySQL查询执行的影响，实验结果表明进行参数调优可以优化查询执行的速度，并且动态自调优的方法在优化查询性能方面要好于人工调优的方法。因此这种方法，应该作为我们进行查询优化时最先采取的措施和手段，也是比较有效和最直接的手段。
数据库的查询优化方法分析 i=r 随着计算机应用的深入 ,计算机技术的成熟 , 各种应用软件 的普及,应用数据也随着日常工作而迅速增长 , 作为数据仓库的 数据库的重要性也日益显著。 数据库系统作为管理信息系统的核心 , 各种基于数据库的联 机事务处理以及联机分析处理正慢慢的转变成为计算机应用的 最为重要的部分 ,根据以往大量的应用实例来看 , 在数据库的各 种操作中 ,查询操作所占的比重最大 , 而在查询操作中基于 SELECT 吾句在SQL 语句中又是代价最大的语句。如果在使用中 采用了优秀的查询策略 ,往往可以降低查询的时间 , 提高查询的 效率,由此可见查询优化在数据库中的重要性。本文就数据库查 询优化中的策略进行介绍及探索。 1 基于索引的优化 数据库的优化方法多种多样 , 不同的方法对提高数据库查询 效率也不相同。 索引作为数据库中的重要数据结构 , 它的根本目的就是为 了提高查询的效率。而优化查询的重要方法就是建立索引 因为查询而造成的输入输出开销 , 有效提高数据库数据的查 询速 度, 优化了数据库性能。然而在创建索引时也增加了系统时间和 空间的开销。所以创建索引时应该与实际查询需求相结合 , 这样 才能实现真正的优化查询。 1.1 判断并建立必要的索引 对所要创建的索引进行正确的 判断 ,使所创建的索引对数据库的工作效率提高有所帮助。为了 实现这一点 , 我们应做到以下要求 : 在熟记数据库程序中的相关 适合关系数据库系统的索引 , 这样就可以避免表扫描 , 并减少了 , 建立
SQL语句的前提下，统计出常用且对性能有影响的语句;判断数据库系统中哪些表的哪些字段要建立索引。其次 , 对数据库中操作频繁的表 , 数据流量较大的表 , 经常需要与其他表进行连接的表等，要进行重点关注。这些表上的索引将对 SQL语句的性能产生重要的影响。 1.2对索引使用的一些规则索引的使用在一些大型数据库系统中会经常使用到 , 这样可以有效的提高数据库性能 , 使数据库的访问速度得到提高。但索引的使用要恰倒好处 , 所以我们在使用索引时应遵守使用原则 : 建立索引可以提高数据库的查询速度, 但索引过多 ,不但不能实现优化查询 ,反而会影响到数据库的整体性能。索引作为数据库中实际存在的对象 , 每个索引都要占用一定的物理空间。所以对于索引的建立要考虑到物理空间容量以及所建立索引的必要性和实用性。 1.3合理的索引对SQL语句的意义索引建立之后，还要确保其得到了真正的使用 , 发挥了其应有的作用。首先 , 可以通过 SQL语句查询来确定所建立的索引是否得到了使用，找出没有使用到的索引。分析索引建立但没有使用的原因 , 使其真正发挥作
大型ORACLE数据库优化设计方案 本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。 对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级 包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不 同方面介绍ORACLE数据库优化设计方案。 一.数据库优化自由结构OFA(Optimal flexible Architecture) 数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。数据库逻辑设计的结果应当符合下面的准则：(1)把以同样方式使用的段类型存储在一起； (2)按照标准使用来设计系统；(3)存在用于例外的分离区域；(4)最小化表空间冲突；(5)将数 据字典分离。 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA 包括以下几个部分： 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存，占整个数据库大小 的1%-2%，用来存储从数据库重读取的数据块(表、索引、簇等)，因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表 说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法 管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这
龙源期刊网 https://www.doczj.com/doc/db17101009.html, 如何优化数据库，提高查询效率 作者：代鸿彬 来源：《学习与科普》2019年第10期 摘要：随着信息时代的到来，生活和工作当中已经无法避免的需要和计算机打交道，和 计算机打交道的同时就必须要用到数据库。数据库系统是计算机当中的一项重要系统，储存在用户的关键信息，不仅对个人影响很大，同时对企事业单位也有着重要影响。 关键词：信息时代；数据库；索引 数据库是信息的载体也是数据的最佳表现形式，它的共享性导致了数据会被大量的搜索查询，为了提高查询的效率，就不得不对数据库进行优化。 一、利用索引进行优化。 索引是数据库的重要组成部分，也是使用者根据需要进行查询最直接的方法，优化索引可以提高查询的效率。当前的数据库当中大部分还是使用国际商业机器公司以前的索引顺序存取方法，对于用户来说肯定会选择方便、快捷的索引方式，怎么方便怎么来。在建立索引的时候针对不同的内容，需要建立不同的连接方式，但是随着用户的增多，查询内容和方向的多元化，这就造成了在实际工作当中经常会有使用频率很少的索引出现，甚至也会出现没有查询所需的索引，这种情况可以通过查询优化器进行自动生成的索引进行查询。对于使用频率较为频繁的列，需要对其进行排序或者分组的列上建立索引时，要优化索引提高效率，对于使用频率很少的列可以不建立索引。 二、简化排序进行优化。 对于部分企事业单位需要排序的内容很多时，就要使用大型数据表来满足查询需求，但是大型数据表涉及的内容很多，为了避免出现重复排序的现象需要对数据表进行简化。在大型数据表当中有一部分的内容可以自动进行排序的次序输出，这时就可以直接利用查询优化器进行优化，将复杂的排序简单化，从而提高索引查询效率。需要排序的列对索引优化影响较大，就像语言当中的ORDER BY 或者GROUP BY句子当中的列次序和索引当中的列次序基本是不同的，但是排序的列可通过表的不同形式表现出来。通过简化排序避免了重复的排序，并且将数据库进行了合理的合并。如果不进行简化排序，就需要将排序的范围进行缩小简化，从而提高查询使用的效率。 三、大型表行数据库存取的合理消除。 数据库系统的存储量是有上限的，所有的索引内容都占有数据库空间，尤其是大型数据表占有的空间更大，将会造成索引时间变长。但是大型表行数据有些内容是不必要的，在进行索引查詢时，数据表当中的存取顺序对查询的效率有直接的影响。例如需要采用存取策略时，通
sql语句（mysql优化）绝对经典 误区1：count(1)和count(primary_key) 优于count(*) 很多人为了统计记录条数，就使用count(1) 和count(primary_key) 而不是count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对count(*) 计数操作做了一些特别的优化。 误区2：count(column) 和count(*) 是一样的 这个误区甚至在很多的资深工程师或者是DBA 中都普遍存在，很多人都会认为这是理所当然的。实际上，count(column) 和count(*) 是一个完全不一样的操作，所代表的意义也完全不一样。count(column) 是表示结果集中有多少个column字段不为空的记录，count(*) 是表示整个结果集有多少条记录 误区3：select a,b from … 比select a,b,c from …可以让数据库访问更少的数据量 这个误区主要存在于大量的开发人员中，主要原因是对数据库的存储原理不是太了解。实际上，大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作block 或者page)为单位，一般为4KB，8KB… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。当然，也有例外情况，那就是我们的这个查询在索引中就可以完成，也就是说当只取a,b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。在这样的情况下，二者的IO量会有较大差异。(覆盖索引) 误区4：order by 一定需要排序操作 我们知道索引数据实际上是有序的，如果我们的需要的数据和某个索引的顺序一致，而且我们的查询又通过这个索引来执行，那么数据库一般会省略排序操作，而直接将数据返回，因为数据库知道数据已经满足我们的排序需求了。实际上，利用索引来优化有排序需求的SQL，是一个非常重要的优化手段。延伸阅读：MySQL ORDER BY 的实现分析，MySQL 中GROUP BY 基本实现原理以及MySQL DISTINCT 的基本实现原理。（order by null）
SQL Server 2008数据查询的优化方法研究摘要 随着数据存储需求的日益增长，对关系数据的管理和访问就成为数据库技术必须解决的问题。本文主要论述关系数据库查询优化技术，并从它的优化技术进行深入探讨，对系统实现做了一定的论述，并进行了部分的程序实现。 关键词：数据库查询系统优化 引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。 影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种： 1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 SQLServer数据查询优化方法 1、避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary 是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: select name from employee where salary ＞60000
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
分布式数据库查询优化技术 摘要在分布式数据库中，由于高可靠性和高速度性是其重要特点，所以对查询执行的要求也就更高。而查询执行中查询优化是执行的关键环节，查询优化在很大程度上决定查询的效率或快慢。本文讨论的重点是对分布式查询执行的全局处理策略进行优化，尽可能避免通信代价的开销，并着眼于查询执行的实际代价，从分布式系统中选出一个最优的执行节点。从查询执行的效果出发，通过统计的方式，不断从最近的查询执行代价学习纠正最近查询执行的统计代价，为查询的全局处理提供参考，以达到优化执行、提高执行效率和速度的目的。 1 分布式数据库概述 1.1 分布式数据库的定义 所谓分布式数据库系统就是由分布于多个计算机结点上的若干个数据库组成, 每个子数据库系统都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统，分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。简单的说，分布式数据库系统是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构上是分布式的[1]。 1.2 分布式数据库系统的组成 如图1-1所示，分布式数据库系统由以下述成分组成: (1)多台计算机设备，并由计算机网络连接。 (2)计算机网络设备，网络通讯的一组软件。 (3)分布式数据库管理系统，它包括GDBMS、LDBMS、CM,除了具有全局用户接口由GDBMS连接外，还可以具有自治场地用户接口，由场地DBMS，并持有独立的场地目录。 (4)分布式数据库管理者（DDB），包括全局数据库(GDB)和局部数据库(LDB)以及自制场地的自治场地数据库。 (5)分布式数据库管理者(DDBA)，它可分为二级，一级为全局数据库管理者(GDBA),另一级问局部或自治场地数据库管理者，统称为局部数据库管理者(LDBA)。 (6)分布式数据库系统软件文档，这是一组与软件相匹配的软件文档及系统各种使用说明和文件。 图1-1 分布式数据库系统的结构 1.3 分布式数据库系统的功能 通常的集中式数据库管理系统应具备以下几个基本的功能[2]: (1)数据库定义功能; (2)数据存取功能; (3)数据库运行管理; (4)数据库的建立和维护功能。 分布式数据库除了须具备以上集中式数据库的功能外，一般还须具有以下几个方面的功能: (1)分布在网络中的各节点的数据库，其物理位置对用户透明; 在用户眼里见到的只是整个系统中有哪些数据库，无论是本地还是远程数据库，用户操纵某一数据库就像操纵本地数据库一样。 (2)处于网络中的各数据库共享的数据应保证一致性:
一、数据库结构的设计 如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器端程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。 在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。 所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的访问造成，数据库的响应时间不能跟上数据刷新的速度。具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发访问的情况下，不会发生问题，但是在当日期临界时的访问量相当大，且在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。 为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。（例如用户表的地区，我们可以把地区另外存放到一个地区表中）如果数据冗余低，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。 另外，最好不要用自增属性字段作为主键与子表关联，不便于系统的迁移和数据恢复。 原来的表格必须可以通过由它分离出去的表格重新构建。使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。（例如一个通行证系统，我可以将USERID，USERNAME，USERPASSWORD，单独出来做个表，再把USERID作为其他表的外键） 表的设计具体注意的问题： 1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。 2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 3、对于不可变字符类型char和可变字符类型varchar 都是8000字节，char 查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计
1性能优化基本步骤 1.1定位跟踪耗费资源较多的SQL语句步骤 1.1.1 通过SQL查询 (1): 查询出最耗费资源的SQL语句 select t1.SID, t1.SERIAL#, tt.HASH_VALUE, tt.ADDRESS, tt.BUFFER_GETS, --读内存次数 tt.DISK_READS, --磁盘物理读次数 tt.EXECUTIONS, --语句的执行次数 tt.BUFFER_GETS / tt.EXECUTIONS, --平均读内存次数 tt.SQL_FULLTEXT from v$sqlareatt, v$session t1 where (tt.BUFFER_GETS>100000 or tt.DISK_READS>100000) and tt.HASH_VALUE = t1.SQL_HASH_VALUE and tt.ADDRESS = t1.SQL_ADDRESS and t1.STATUS = 'ACTIVE' orderby tt.BUFFER_GETS desc (2)：根据客户端程序发出的SQL来定位需要跟踪的session select s.sid sid, s.SERIAL# "serial#", https://www.doczj.com/doc/db17101009.html,ername, s.machine, s.program, s.server, s.LOGON_TIME from v$session s 1.1.2 通过Oracle提供的SQL TRACE进行SQL跟踪 (1)：跟踪前设定相应参数 1．查询得到需要跟踪的session 2．打开时间开关
Show parameter timed_statistics alter session set timed_statistics=true; execsys.dbms_system.set_bool_param_in_session(sid => 8,serial# => 3,parnam => 'timed_statistics',bval => true); 3．设置跟踪文件存放位置 Show parameter user_dump_dest alter system set user_dump_dest='c:\temp'; (2)：启动跟踪功能并让系统运行一段时间 alter session set sql_trace=true; execsys.dbms_system.set_sql_trace_in_session(8, 3, true); (3)：关闭跟踪功能 alter session set sql_trace=false; execsys.dbms_system.set_sql_trace_in_session(8, 3, false); (4)：格式化跟踪数据文件，并分析跟踪结果文件 tkprof dsdb2_ora_18468.trc dsdb2_trace.txt EXPLAIN=SCOTT/TIGER tkprof各参数含义： ' traced_file ' 指定输入文件，即oracle产生的trace文件 'formatted_file'指定输出文件，即我们想得到的易于理解的格式化文件 'EXPLAIN' 利用哪个用户对trace文件中的sql进行分析得到该sql语句的执行计划1.2查看分析执行计划 1.2.1查看执行计划 (1)：Sqlplus中可按F5查看执行计划 (2)：使用执行计划表进行查看 使用语句将SQL语句的执行计划装入plan_table表，然后进行分析查看explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value (3)：示例演示 1．让ORALCE自动选择最优的执行计划，不人为干预 explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value
数据库优化方案设计 XX信息管理平台从大型数据库环境四个不同级别的调整分析入手，分析数据库平台的系统结构和工作机理，从九个不同方面设计数据库的优化方案。 对于数据库的数据优化，主要有四个不同的调整级别，第一级调整是操作系统级包括硬件平台，第二级调整是RDBMS级的调整，第三级是数据库设计级的调整，最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不同方面介绍数据库优化设计方案。 一、数据库优化自由结构 数据库的逻辑配置对数据库性能有很大的影响。为此，数据库平台一般对表空间设计提出有相应的优化结构，如ORACLE公司的OFA(Optimal flexible Architecture)，使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构，简单地讲就是在数据库中可以高效自由地分布逻辑数据对象，因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类，这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。 数据库逻辑设计的结果应当符合下面的准则： （1）把以同样方式使用的段类型存储在一起； （2）按照标准使用来设计系统； （3）存在用于例外的分离区域； （4）最小化表空间冲突； （5）将数据字典分离。 二、充分利用系统全局区域 系统全局区域是数据库平台的心脏，如Oracle数据库的SGA（SYSTEM GLOBAL AREA) 。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分： 1、数据块缓冲区（data block buffer cache）是SGA中的一块高速缓存，占整个数据库大小的1%-2%，用来存储从数据库重读取的数据块（表、索引、簇等），因此采用least recently used (LRU，最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU 算法管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这些内存缓冲区的合理设置，可以大大加快数据查询速度，一个足够大的内存区可以把绝大多数数据存储在内存中，只有那些不怎么频繁使用的数据，才从磁盘读取，这样就可以大大提高内存区的命中率。 三、规范与反规范设计数据库
2010年4月第6卷第2期 系统仿真技术 Syste m S i m u l ation Tec hno l ogy A pr.,2010 V o.l6,N o.2 中图分类号:TP39 文献标识码:A Creator三维模型数据库优化技术 张 建 (91404部队93分队,河北秦皇岛 066001) 摘 要:从提高视景仿真系统的运行效率角度出发,首先简要介绍了著名的三维建模软件M ulti G en Creator,然后针对用于视景仿真系统的三维模型数据库的特点,详细阐述了Creator模型数据库的优化技术。通过对模型数据库进行减少多边形数量、优化层次结构、使用布告板等方法,能显著提高视景仿真系统的运行效率。 关键词:可视化仿真;三维模型;数据库;优化 Optim i zati on Technique of Cr eat or Thr ee dimensi onalModel Database Z HANG J ian (Th e93Un it of91404PLA,Q i nhuangdao066001,Ch i na) Abstract:Taking i m prove the r un efficiency o f v isua l si m ulation syste m as purpo se,the author i n troduce t h e M ulti G en C reato r,then,base on the characteristics o f t h ree di m ensi o nal m ode l da taba se,ill u m i n a te t h e opti m ization techn i q ue o f C reato r three d i m ensiona l m o de l database.The run effic i e ncy o f v isua l si m u l a ti o n sy ste m can be i m prov e through reduce the nu m bers o f po lygon,opti m ize arrange m ent structure and B ill b oard,etc. Key words:scene si m u lation;t h ree di m ensi o nalm ode;l database;opti m izati o n 1 引 言 视景仿真技术(V isual S i m u lation Technology)是计算机技术、图形处理与图像生成技术、立体影像和音响技术、信息合成技术、显示技术等高新技术的综合运用。它分为仿真环境制作和仿真运行驱动2个环节,仿真环境制作主要包括:模型设计、场景构造、纹理设计制作、特效设计等,它要求构造出逼真的三维模型和制作逼真的纹理与特效。仿真驱动主要包括:场景驱动、模型调动处理、分布交互等,它要求高速逼真的再现仿真环境,实时响应交互操作等。 随着三维场景数据量的日益增大以及专为图形渲染设计的图形处理器(graph ic processing un i,t GPU)的普及,在不明显降低图形质量和复杂程度的前提下,解决大数据量仿真场景在速度、质量及场景复杂度之间越来越突出的矛盾,成为一个值得研究的问题。对于可视化仿真系统而言,重要的是仿真系统运行时的速度和流畅性,要在保证系统运行速度的前提下适当提高模型逼真度,在模型逼真度和运行速度之间找到1个平衡点。 2 M ulti G en Creator简介 著名的三维图形建模软件,如M aya,3DMAX, 3Dstud i o等,都以视觉效果为第一建模目标,能生成逼真的三维模型。但是这些软件不考虑模型的
MySQL5.1性能优化方案 1.平台数据库 1.1.操作系统 Red Hat Enterprise Linux Server release 5.4 (Tikanga) ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 32位Linux服务器，单独作为MySQL服务器使用。 1.2.M ySQL 系统使用的是MySQL5.1，最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面： 1）默认存储引擎更改为InnoDB InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但MySQL5.1之前的版本默认引擎均为MyISAM，此次MySQL5.5终于将默认数据库存储引擎改为InnoDB，并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟(InnoDB plugin 1.0.7，InnoDB plugin 1.1，恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储，节约存储，提高内存命中率，并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。 Multi Rollback Segments：原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。 2）多核性能提升
关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。 冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。 冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。 3、主键的设计 主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。 在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。 主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前
mysql性能优化-慢查询分析、优化索引和配置目录 一、优化概述 二、查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三、配置优化 1) max_connections 2) back_log 3) interactive_timeout 4) key_buffer_size 5) query_cache_size 6) record_buffer_size 7) read_rnd_buffer_size 8) sort_buffer_size 9) join_buffer_size 10) table_cache 11) max_heap_table_size 12) tmp_table_size
13) thread_cache_size 14) thread_concurrency 15) wait_timeout 一、优化概述 MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈，CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘I/O瓶颈发生在装入数据远大于内存容量的时候，如果应用分布在网络上，那么查询量相当大的时候那么平瓶颈就会出现在网络上，我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态。 除了服务器硬件的性能瓶颈，对于MySQL系统本身，我们可以使用工具来优化数据库的性能，通常有三种：使用索引，使用EXPLAIN分析查询以及调整MySQL的内部配置。 二、查询与索引优化分析 在优化MySQL时，通常需要对数据库进行分析，常见的分析手段有慢查询日志，EXPLAIN 分析查询，profiling分析以及show命令查询系统状态及系统变量，通过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。 1 性能瓶颈定位 Show命令 我们可以通过show命令查看MySQL状态及变量，找到系统的瓶颈： Mysql> show status ——显示状态信息（扩展show status like ‘XXX’） Mysql> show variables ——显示系统变量（扩展show variables like ‘XXX’） Mysql> show innodb status ——显示InnoDB存储引擎的状态 Mysql> show processlist ——查看当前SQL执行，包括执行状态、是否锁表等
大型数据库的优化方法及实例 尹德明杨富玉杨莹时鹏泉 中国金融电子化公司 E_mail: dm_mis@https://www.doczj.com/doc/db17101009.html, 1.引言 随着银行业数据集中，作为整个系统核心的数据库，其存放、管理的数据越来越庞大，已经超越GB而到达TB数据量层次，数据库的性能成为整个系统性能的关键。 国库会计核算系统是国库部门用以进行国库业务的会计核算，并通过支付系统、国库内部往来、同城票据交换系统进行资金清算的计算机网络系统。国家金库会计核算系统每天处理的税票数据多达10万笔，税收高峰可能会到100万笔，这样一年累计下来其中历史登记簿中的数据达到2000万条以上，给检索和数据处理带来非常大的困难。 如何对于一个已经上线运行的重要业务系统，通过对数据库的优化和简单的系统流程调整，实现系统性能的大幅提升具有现实、迫切、重要的意义。 2.优化策略 根据Sybase的数据存储机制，在进行一段时期的数据删除、插入和更新等操作后，数据库往往会产生大量的碎片。大量碎片的存在，会严重影响数据库的I/O性能，如果在使用数据库一段时间后，整理碎片，可以提高数据库的性能。由于国家金库会计核算系统在预处理、日间报解、日初始化等步骤，会大批量进行数据删除、插入和更新等操作，因此会产生大量的数据碎片。碎片整理对于国家金库会计核算系统性能优化将会有重要效果。 Sybase Adaptive Server对于按顺序存储和访问的页，在单个I/O中最多读取八个数据页。由于大部分I/O时间都花在磁盘上的物理定位和搜寻上，因此大I/O可极大地减少磁盘访问时间。在大多数情况下，希望在缺省数据高速缓存中配置一个16K缓冲池。为事务日志创建4K缓冲池可极大地减少数据库系统日志写操作的数量。 好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。 3.数据库碎片整理 由于Sybase是通过OAM页、分配单元和扩展页来管理数据的，所以对OLTP应用的Database Server会十分频繁地进行数据删除、插入和更新等操作，时间一长就会出现以下几种情况： (1)页碎片 即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上，Database Server就要访问多个扩展单元，因此降低了系统性能。 (2)扩展单元碎片 在堆表中，当删除数据链中间的记录行时，会出现空页。随着空页的累积，扩展单元的利用率也会下降，从而出现扩展单元碎片。带cluster index的table也有可能出现扩展单元碎片。当有扩展单元碎片存在，会出现以下问题： 对表进行处理时，常常出现死锁；利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度；行操作的争用。 （3）扩展单元遍历 带有cluster index的table会由于插入记录而导致页分裂，但当删除记录后，页会获得释放，从而形成跨几个扩展单元和分配单元的数据，而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长，开始时数据库的性能虽然较高，