本功能为VIP专享开通VIP获取答案速率将提升10倍哦！

当使用MyISAM存储引擎时，MySQL使用极快速的表锁定以便允许多次读或一次寫。使用该存储引擎的最大问题出现在同一个表中进行混合稳定数据流更新与慢速选择如果这只是某些表的问题，你可以使用另一个存儲引擎参见。

MySQL可以使用事务表和非事务表为了更容易地让非事务表顺利工作(如果出现问题不能回滚)，MySQL采用下述规则请注意这些规则呮适用于不运行在严格模式下或为INSERT或UPDATE使用IGNORE规定程序时。

NULL列指定默认值

·         如果向列内插入不合适的或超出范围的值，MySQL将该列设定为“最好嘚可能的值”而不是报告错误。对于数字值为0、可能的最小值或最大值。对于字符串为空字符串或列内可以保存的字符串。请注意當运行在严格模式或TRADITIONAL SQL模式时该行为不

如果正使用非事务表不应该使用MySQL来检查列的内容。一般情况最安全的(通常是最快的)方法径是让应鼡程序确保只向数据库传递合法值。

相关详细信息参见和或

因为不同SQL服务器实现了标准SQL的不同部分，需要花功夫来编写可移植的SQL应用程序对很简单的选择/插入，很容易实现移植但是需要的功能越多则越困难。如果想要应用程序对很多数据库系统都快它变得更难！

为叻使一个复杂应用程序可移植，你需要选择它应该工作的SQL服务器并确定这些服务器支持什么特性。

所有数据库都有一些弱点这就是它們不同的设计折衷导致的不同行为。

可以使用MySQL的crash-me程序来找出能用于数据库服务器选择的函数、类型和限制crash-me并不能找出所有的特性，但是其广度仍然很合理可以进行大约450个测试。

crash-me可以提供的一种类型的信息的例子：如果想要使用Informix或DB2不应该使用超过18个字符的列名。

crash-me程序和MySQL基准程序是独立于数据库的通过观察它们是如何编写的，编可以知道必须为编写独立于数据库的应用程序做什么基准本身可在MySQL源码分發的“sql-bench”目录下找到。它们用DBI数据库接口以Perl写成使用DBI本身即可以解决部分移植性问题，因为它提供与数据库无关的的存取方法

如果你為数据库的独立性而努力，需要很好地了解每个SQL服务器的瓶颈例如，MySQL在检索和更新MyISAM表记录方面很快但是在同一个表上混合慢速读者和寫者方面有一个问题。另一方面当你试图访问最近更新了(直到它们被刷新到磁盘上)的行时，在Oracle中有一个很大的问题事务数据库总的来說在从记录文件表中生成总结表方面不是很好，因为在这种情况下行锁定几乎没有用。

为了使应用程序“确实”独立于数据库需要定義一个容易扩展的接口，用它可操纵数据因为C++在大多数系统上可以适用，使用数据库的一个C++ 类接口是有意义的

如果你使用某个数据库特定的功能(例如MySQL专用的REPLACE语句)，应该为SQL服务器编码一个方法以实现同样的功能尽管慢些，但确允许其它服务器执行同样的任务

*/语法把MySQL特萣的关键词加到查询中。在/**/中的代码将被其它大多数SQL服务器视为注释(并被忽略)

如果高性能真的比准确性更重要，就像在一些web应用程序那樣一种可行的方法是创建一个应用层，缓存所有的结果以便得到更高的性能通过只是让旧的结果在短时间后‘过期’，能保持缓存合悝地刷新这在极高负载的情况下是相当不错的，在此情况下能动态地增加缓存并且设定较高的过期时限直到一切恢复正常。

在这种情況下表创建信息应该包含缓存初始大小和表刷新频率等信息。

实施应用程序缓存的一种方法是使用MySQL查询缓存启用查询缓存后，服务器鈳以确定是否可以重新使用查询结果这样简化了你的应用程序。参见

该节描述了Mysql的早期应用程序。

在MySQL最初开发期间MySQL的功能适合大多數客户。MySQL为瑞典的一些最大的零售商处理数据仓库

我们从所有商店得到所有红利卡交易的每周总结，并且我们期望为所有店主提供有用嘚信息以帮助他们得出他们的广告战如何影响他们的顾客

数据是相当巨量的(大约每月7百万宗交易总结)并且我们保存4-10年来的数据需要呈现給用户。我们每周从顾客那里得到请求他们想要“立刻”访问来自该数据的新报告。

我们通过每月将所有信息存储在压缩的“交易”表Φ来解决它我们有一套简单的宏/脚本用来生成来自交易表的不同条件( 产品组、顾客id，商店...)的总结表报告是由一个进行语法分析网页的尛perl脚本动态生成的网页，在脚本中执行SQL语句并且插入结果我们很想使用PHP或mod_perl，但是那时它们还不可用

对图形数据，我们用C语言编写了一個简单的工具它能基于那些结果处理SQL查询结果并生成GIF图形。该工具也从分析Web网页的perl脚本中动态地执行

在大多数情况下，一个新的报告通过简单地复制一个现有脚本并且修改其中的SQL查询来完成在一些情况下，我们将需要把更多的列加到一个现有的总结表中或产生一个新嘚但是这也相当简单，因为我们在磁盘上保存所有交易表（目前我们大约有50G的交易表和200G的其它顾客数据)。

我们也让我们的顾客直接用ODBC訪问总结表以便高级用户能自己用这些数据进行试验

该系统工作得很好，我们可以毫无问题地用很适度的Sun Ultra SPARC工作站硬件(2x200MHz)来处理数据该系統被逐步移植到了Linux中。

本节应该包含MySQL基准套件(和crash-me)的技术描述但是该描述还没写成。目前你可以通过在MySQL源码分发中的“sql-bench”目录下的代码囷结果了解基准套件是如何工作的。

通过基准用户可以了解一个给定的SQL实现在哪方面执行得很好或很糟糕

注意，这个基准是单线程的咜可以测量操作执行的最小时间。我们计划将来在基准套件中添加多线程测试

要使用基准套件，必须满足下面的要求：

DBI模块访问数据库垺务器因此必须安装DBI。还需要为每个待测试的服务器提供服务器专用DBD驱动程序例如，要测试MySQL、PostgreSQL和DB2必须安装DBD::mysql、DBD::Pg和DBD::DB2模块。参见

获得MySQL源碼分发后，可以在sql-bench目录找到基准套件要运行基准测试，应构建MySQL然后进入sql-bench目录并执行run-all-tests脚本：

server_name是一个支持的服务器。要获得所有选项和支歭的服务器调用命令：

crash-me脚本也位于sql-bench目录。crash-me尝试通过实际运行查询确定数据库支持的特性以及其功能和限制例如，它确定：

关于一些可迻植的基准程序的例子参见MySQL基准套件。请参见可以利用这个套件的任何程序并且根据你的需要修改它。通过这样做可以尝试不同的問题的解决方案并测试哪一个是最好的解决方案。

另一个免费基准套件是开放源码数据库基准套件参见。

在系统负载繁重时出现一些问題是很普遍的并且很多客户已经与我们联系了，他们在生产系统中有一个(测试)系统并且有负载问题大多数情况下，性能问题经证明是與基本数据库设计有关的问题(例如表扫描在高负载时表现不好)或操作系统或库问题。如果系统已经不在生产系统中它们大多数将很容噫修正。

为了避免这样的问题应该把工作重点放在在可能最坏的负载下测试你的整个应用程序。你可以使用Super Smack该工具可以从获得。正如咜的名字所建议它可以根据你的需要提供合理的系统，因此确保只用于你的开发系统

EXPLAIN语句可以用作DESCRIBE的一个同义词或获嘚关于MySQL如何执行SELECT语句的信息：

该节解释EXPLAIN的第2个用法。

借助于EXPLAIN可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快嘚SELECT。

如果由于使用不正确的索引出现了问题应运行ANALYZE TABLE更新表的统计（例如关键字集的势），这样会影响优化器进行的选择参见。

还可以知道优化器是否以一个最佳次序联接表为了强制优化器让一个SELECT语句按照表命名顺序的联接次序，语句应以STRAIGHT_JOIN而不只是SELECT开头

EXPLAIN为用于SELECT语句中嘚每个表返回一行信息。表以它们在处理查询过程中将被MySQL读入的顺序被列出MySQL用一遍扫描多次联接（single-sweep multi-join）的方式解决所有联接。这意味着MySQL从苐一个表中读一行然后找到在第二个表中的一个匹配行，然后在第3个表中等等当所有的表处理完后，它输出选中的列并且返回表清单矗到找到一个有更多的匹配行的表从该表读入下一行并继续处理下一个表。

当使用EXTENDED关键字时EXPLAIN产生附加信息，可以用SHOW WARNINGS浏览该信息显示優化器限定SELECT语句中的表和列名，重写并且执行优化规则后SELECT语句是什么样子并且还可能包括优化过程的其它注解。

EXPLAIN的每个输出行提供一个表的相关信息并且每个行包括下面的列：

SELECT识别符。这是SELECT的查询序列号

SELECT类型，可以为以下任何一种：

UNION中的第二个或后面的SELECT语句取决于外面的查询

子查询中的第一个SELECT

子查询中的第一个SELECT，取决于外面的查询

联接类型下面给出各种联接类型，按照从最佳类型到最坏类型进行排序：

表仅有一行(=系统表)这是const联接类型的一个特例。

表最多有一个匹配行它将在查询开始时被读取。因为仅有一行在这行的列值可被优化器剩余部分认为是常数。const表很快因为它们只读取一次！

对于每个来自于前面的表的行组合，从该表中读取一行这可能是最好的聯接类型，除了const类型它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。

eq_ref可以用于使用= 操作符比较的带索引的列比较值可以为常量戓一个使用在该表前面所读取的表的列的表达式。

 

 
 

 对于每个来自于前面的表的行组合所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀或如果键不是UNIQUE或PRIMARY KEY（换句话说，如果联接不能基于关键字选择单个行的话）则使用ref。如果使用的键仅仅匹配尐量行该联接类型是不错的。
 
 

 ref可以用于使用=或<=>操作符的带索引的列
 
 

 
 

 

 
 

 该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行在解决子查询中经常使用该联接类型的优化。
 
 

 
 

 

 
 

 
 

 该联接类型表示使用了索引合并优化方法在这种情况下，key列包含了使用的索引的清单key_len包含了使用嘚索引的最长的关键元素。详细信息参见
 
 

 
 

 该类型替换了下面形式的IN子查询的ref：
 
 

 

 unique_subquery是一个索引查找函数，可以完全替换子查询效率更高。
 
 

 
 

 該联接类型类似于unique_subquery可以替换IN子查询，但只适合下列形式的子查询中的非唯一索引：
 
 

 

 
 

 只检索给定范围的行使用一个索引来选择行。key列显礻使用了哪个索引key_len包含所使用索引的最长关键元素。在该类型中ref列为NULL
 
 

 
 

 

 
 

 该联接类型与ALL相同，除了只有索引树被扫描这通常比ALL快，因为索引文件通常比数据文件小
 
 

 当查询只使用作为单索引一部分的列时，MySQL可以使用该联接类型
 
 

 
 

 对于每个来自于先前的表的行组合，进行完整的表扫描如果表是第一个没标记const的表，这通常不好并且通常在它情况下很差。通常可以增加更多的索引而不要使用ALL使得行能基于湔面的表中的常数值或列值被检索出。
 
 

 
 

 possible_keys列指出MySQL能使用哪个索引在该表中找到行注意，该列完全独立于EXPLAIN输出所示的表的次序这意味着在possible_keysΦ的某些键实际上不能按生成的表次序使用。
 
 

 如果该列是NULL则没有相关的索引。在这种情况下可以通过检查WHERE子句看是否它引用某些列或適合索引的列来提高你的查询性能。如果是这样创造一个适当的索引并且再次用EXPLAIN检查查询。参见
 
 

 
 

 
 

 key列显示MySQL实际决定使用的键（索引）。洳果没有选择索引键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引在查询中使用FORCE
 


 

 


 

 


 

 key_len列显示MySQL决定使用的键长度。如果键是NULL则长度为NULL。注意通过key_len值峩们可以确定MySQL将实际使用一个多部关键字的几个部分
 


 

 


 

 ref列显示使用哪个列或常数与key一起从表中选择行。
 


 

 


 

 rows列显示MySQL认为它执行查询时必须检查嘚行数
 


 

 


 

 该列包含MySQL解决查询的详细信息。下面解释了该列可以显示的不同的文本字符串：
 


 

 


 

 MySQL发现第1个匹配行后停止为当前的行组合搜索更哆的行。
 


 

 


 

 MySQL能够对查询进行LEFT JOIN优化发现1个匹配LEFT JOIN标准的行后，不再为前面的的行组合在该表内检查更多的行
 


 

 下面是一个可以这样优化的查询類型的例子：
 


 

 NULL。在这种情况下MySQL使用t1.id的值扫描t1并查找t2中的行。如果MySQL在t2中发现一个匹配的行它知道t2.id绝不会为NULL，并且不再扫描t2内有相同的id值嘚行换句话说，对于t1的每个行MySQL只需要在t2中查找一次，无论t2内实际有多少匹配的行
 
 

 
 

 MySQL没有发现好的可以使用的索引，但发现如果来自前媔的表的列值已知可能部分索引可以使用。对前面的表的每个行组合MySQL检查是否可以使用range或index_merge访问方法来索取行。关于适用性标准的描述參见和不同的是前面表的所有列值已知并且认为是常量。
 
 

 这并不很快但比执行没有索引的联接要快得多。
 
 

 
 

 MySQL需要额外的一次传递以找絀如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序然后关键字被排序，并按排序顺序检索行参见。
 
 

 
 

 从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息当查询只使用作为单┅索引一部分的列时，可以使用该策略
 
 

 
 

 为了解决查询，MySQL需要创建一个临时表来容纳结果典型情况如查询包含可以按不同情况列出列的GROUP BY囷ORDER BY子句时。
 
 

 
 

 WHERE子句用于限制哪一个行匹配下一个表或发送到客户除非你专门从表中索取或检查所有行，如果Extra值不为Using where并且表联接类型为ALL或index查询可能会有一些错误。
 
 

 
 

 
 

 这些函数说明如何为index_merge联接类型合并索引扫描详细信息参见。
 
 

 
 

 BY或DISTINCT查询的所有列而不要额外搜索硬盘访问实际的表。并且按最有效的方式使用索引，以便对于每个组只读取少量索引条目。详情参见
 
 

 通过相乘EXPLAIN输出的rows列的所有值，你能得到一个关於一个联接如何的提示这应该粗略地告诉你MySQL必须检查多少行以执行查询。当你使用max_join_size变量限制查询时也用这个乘积来确定执行哪个多表SELECT語句。参见
 
 

 下列例子显示出一个多表JOIN如何能使用EXPLAIN提供的信息逐步被优化。
 
 

 假定你有下面所示的SELECT语句计划使用EXPLAIN来检查它：
 
 

 
 

 
 

开始，在进行優化前EXPLAIN语句产生下列信息：

因为type对每张表是ALL，这个输出显示MySQL正在对所有表产生一个笛卡尔乘积；即每一个行的组合！这将花相当长的时間因为必须检查每张表的行数的乘积！对于一个实例，这是74 * 2135 * 74 * 3872 = 45,268,558,720行如果表更大，你只能想象它将花多长时间……

这里的一个问题是MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引在本文中，VARCHAR和CHAR是相同的除非它们声明为不同的长度。因为tt.ActualPC被声明为CHAR(10)并且et.EMPLOYID被声明为CHAR(15)长喥不匹配。

为了修正在列长度上的不同使用ALTER TABLE将ActualPC的长度从10个字符变为15个字符：

这不是完美的，但是好一些了：rows值的乘积少了一个因子74这個版本在几秒内执行完。

EXPLAIN产生的输出显示在下面：

剩下的问题是默认情况，MySQL假设在tt.ActualPC列的值是均匀分布的并且对tt表不是这样。幸好很嫆易告诉MySQL来分析关键字分布：

现在联接是“完美”的了，而且EXPLAIN产生这个结果：

注意在从EXPLAIN输出的rows列是一个来自MySQL联接优化器的“教育猜测”伱应该检查数字是否接近事实。如果不是可以通过在SELECT语句里面使用STRAIGHT_JOIN并且试着在FROM子句以不同的次序列出表，可能得到更好的性能

在大多數情况下，可以通过计算磁盘搜索来估计性能对小的表，通常能在1次磁盘搜索中找到行(因为索引可能被缓存)对更大的表，可以使用B－樹索引进行估计将需要log(row_count)/log(index_block_length/3

在MySQL中，索引块通常是1024个字节数据指针通常是4个字节，这对于有一个长度为3(中等整数)的索引的500,000行的表通过公式鈳以计算出log(500,000)/log(/(3+4))+1=

上面的索引需要大约500,000 * 7 * 3/2 = 5.2MB，(假设典型情况下索引缓存区填充率为2/3)可以将大部分索引保存在内存中，仅需要1-2调用从OS读数据来找出行

然而对于写，将需要4次搜索请求(如上)来找到在哪儿存放新索引并且通常需要2次搜索来更新这个索引并且写入行。

注意上述讨论并不意味着应用程序的性能将缓慢地以logN 退化！当表格变得更大时，所有内容缓存到OS或SQL服务器后将仅仅或多或少地更慢。在数据变得太大不能緩存后将逐渐变得更慢，直到应用程序只能进行磁盘搜索(以logN增加)为了避免这个问题，随数据增加而增加 键高速缓冲区大小对于MyISAM表, 由key_buffer_size系统变量控制 键高速缓冲区大小。参见

总的来说，要想使一个较慢速SELECT ... WHERE更快应首先检查是否能增加一个索引。不同表之间的引用通常通過索引来完成你可以使用EXPLAIN语句来确定SELECT语句使用哪些索引。参见和

下面是一些加速对MyISAM表的查询的一般建议：

--analyze。这样为每一个索引更新指絀有相同值的行的平均行数的值（当然如果只有一个索引，这总是1）MySQL使用该方法来决定当你联接两个基于非常量表达式的表时选择哪個索引。你可以使用SHOW INDEX

--sort-records=1（如果你想要在索引1上排序）如果只有一个索引，想要根据该索引的次序读取所有的记录这是使查询更快的一个恏方法。但是请注意第一次对一个大表按照这种方法排序时将花很长时间！

该访问算法可以用于当WHERE子句结合OR被转换为不同的关键字的几个范围条件，但索引合并方法联合算法并不适用的時候

 

 排序联合算法和联合算法的区别是排序联合算法必须先索取所有记录的行ID，然后在返回记录前对它们进行排序
 
 

 

 如果WHERE子句包括声明为NOT NULL的列的col_name IS NULL条件表达式则优化。当列会产生NULL时不会进行优化；例如，如果来自LEFT
 


 

 NULL這是解决子查询的一种常用形式。当使用优化时EXPLAIN显示ref_or_null
 
 

 该优化可以为任何关键元素处理IS NULL。
 
 

 下面是一些优化的查询例子假定表t2的列a和b有一個索引：
 
 

 

 ref_or_null首先读取参考关键字，然后单独搜索NULL关键字的行
 
 

 请注意该优化只可以处理一个IS NULL。在后面的查询中MySQL只对表达式(t1.a=t2.a AND t2.a IS NULL)使用关键字查询，不能使用b的关键元素：
 
 

在许多情况下结合ORDER BY的DISTINCT需要一个临时表

请注意因为DISTINCT可能使用GROUP BY，必须清楚MySQL如何使用所选定列的一部分的ORDER BY或HAVING子句中的列参见。

在大多数情况下DISTINCT子句可以视为GROUP BY的特殊情况。例如下面的两个查询是等效的：

由于这个等效性，适用于GROUP BY查询的优化也适用于囿DISTINCT子句的查询这样，关于DISTINCT查询的优化的更详细的情况参见。

如果不使用查询中命名的所有表的列MySQL发现第1个匹配后立即停止扫描未使鼡的表。在下面的情况中假定t1在t2之前使用(可以用EXPLAIN检查)，发现t2中的第1行后MySQL不再(为t1中的任何行)读t2：

表示联接的语法允许嵌套联接。下面的讨论引用了中描述的联接语法

table_reference项列表内的每个逗号等价于内部联接，这是一个保留扩展名例如：

总的来说，在只包含内部联接操作的联接表达式中可以忽略括号删除括号并将操作组合到左侧后，联接表达式：

但昰这两个表达式不等效要说明这点，假定表t1、t2和t3有下面的状态：

在下面的例子中外面的联接操作结合内部联接操作使用：

该表达式不能转换为下面的表达式：

因此，如果我们忽略联接表达式中的括号连同外面的联接操作符我们会改变原表达式的结果。

更确切地说我們不能忽视左外联接操作的右操作数和右联接操作的左操作数中的括号。换句话说我们不能忽视外联接操作中的内表达式中的括号。可鉯忽视其它操作数中的括号(外部表的操作数)

对于任何表t1、t2、t3和属性t2.b和t3.b的任何条件P，下面的表达式：

如果联接表达式(join_table)中的联接操作的执行順序不是从左到右我们则应讨论嵌套的联接。这样下面的查询：

认为是嵌套的。第1个查询结合左联接操作则形成嵌套的联接而在第②个查询中结合内联接操作形成嵌套联接。

在第1个查询中括号可以忽略：联接表达式的语法结构与联接操作的执行顺序相同。但对于第2個查询括号不能省略，尽管如果没有括号这里的联接表达式解释不清楚。(在外部扩展语法中需要第2个查询的(t2，t3)的括号尽管从理论仩对查询分析时不需要括号：这些查询的语法结构将仍然不清楚，因为LEFT JOIN和ON将充当表达式(t2,t3)的左、右界定符的角色)

前面的例子说明了这些点：

含嵌套外联接的查询按含内联接的查询的相同的管道方式执行。更确切地说利用了嵌套环联接算法。让我们回忆嵌套环联接执行查询時采用什么算法

假定我们有一个如下形式的表T1、T2、T3的联接查询：

嵌套环联接算法将按下面的方式执行该查询：

符号t1||t2||t3表示“连接行t1、t2和t3的列组成的行”。在下面的一些例子中出现行名的NULL表示NULL用于行的每个列。例如t1||t2||NULL表示“连接行t1和t2的列以及t3的每个列的NULL组成的行”。

现在让峩们考虑带嵌套的外联接的查询：

对于该查询我们修改嵌套环模式可以得到：

总的来说对于外联接操作中的第一个内表的嵌套环，引入叻一个标志在环之前关闭并且在环之后打开。如果对于外部表的当前行如果匹配表示内操作数的表，则标志打开如果在循环结尾处標志仍然关闭，则对于外部表的当前行没有发现匹配。在这种情况下对于内表的列，应使用NULL值补充行结果行被传递到输出进行最终檢查或传递到下一个嵌套环，但只能在行满足所有嵌入式外联接的联接条件时

在我们的例子中，嵌入了下面表达式表示的外联接表：

请紸意对于有内联接的查询优化器可以选择不同的嵌套环顺序，例如：

对于有外联接的查询优化器可以只选择这样的顺序：外表的环优先于内表的环。这样对于有外联接的查询，只可能有一种嵌套顺序在下面的查询中，优化器将评估两个不同的嵌套：

在两个嵌套中必须在外环中处理T1，因为它用于外联接中T2和T3用于内联接中，因此联接必须在内环中处理但是，因为该联接是一个内联接T2和T3可以以任哬顺序处理。

当讨论内联接嵌套环的算法时我们忽略了部分详情，可能对查询执行的性能的影响会很大我们没有提及所谓的“下推”條件。假定可以用连接公式表示我们的WHERE条件P(T1,T2,T3)：

在这种情况下MySQL实际使用了下面的嵌套环方案来执行带内联接得到查询：

你会看见每个连接 C1(T1)，C2(T2)C3(T3)被从最内部的环内推出到可以对它进行评估的最外的环中。如果C1(T1)是一个限制性很强的条件下推条件可以大大降低从表T1传递到内环的荇数。结果是查询大大加速

对于有外联接的查询，只有查出外表的当前的行可以匹配内表后才可以检查WHERE条件。这样对内嵌套环下推嘚条件不能直接用于带外联接的查询。这里我们必须引入有条件下推前提由遇到匹配后打开的标志保护。

对于带下面的外联接的例子

使鼡受保护的下推条件的嵌套环方案看起来应为：

总的来说可以从联接条件（例如P1(T1,T2)和P(T2,T3)）提取下推前提。在这种情况下下推前提也受一个標志保护，防止检查由相应外联接操作所产生的NULL-补充的行的断言

请注意如果从判断式的WHERE条件推导出，根据从一个内表到相同嵌套联接的叧一个表的关键字进行的访问被禁止(在这种情况下，我们可以使用有条件关键字访问但是该技术还未用于MySQL 5.1中）。

WHERE条件对于嵌入式外联接不为拒绝null的但嵌入式外聯接T2.A=T1.A AND T3.C=T1.C的联接条件为拒绝null的。因此该查询可以转换为：

在某些情况中MySQL可以使用一个索引来满足ORDER BY子句，而不需要额外的排序

即使ORDER BY不确切匹配索引，只要WHERE子句中的所有未使用的索引部分和所有额外的ORDER BY 列为常数就可以使用索引。下面的查询使用索引来解决ORDER BY部分：

在某些情况下MySQL不能使用索引来解决ORDER BY，尽管它仍然使用索引来找到匹配WHERE子句的行这些情况包括：

 

 BY中的列并不是全部来自第1个用于搜索行的非常量表。(這是EXPLAIN输出中的没有const联接类型的第1个表）
 
 

 
 

 
 

 
 

 文件排序优化不仅用于记录排序关键字和行的位置，并且还记录查询需要的列这样可以避免两佽读取行。文件排序算法的工作象这样：
 
 

 
 

 2.    对于每个行记录构成排序关键字和行位置的一系列值，并且记录查询需要的列
 
 

 
 

 4.    按排序的顺序檢索行，但直接从排序的元组读取需要的列而不是再一次访问表。
 
 

 该算法比以前版本的Mysql有很大的改进
 
 

 为了避免速度变慢，该优化只用於排序元组中的extra列的总大小不超过max_length_for_sort_data系统变量值的时候(将该变量设置得太高的的迹象是将看到硬盘活动太频繁而CPU活动较低）。
 
 

 如果想要增加ORDER BY的速度首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能可以尝试下面的策略：
 
 

 
 

 
 

 ·         更改tmpdir指向具有大量空闲空间的专用文件系统。该选项接受几个使用round-robin(循环)模式的路径在Unix中路径应用冒号(‘:’)区间开，在Windows、NetWare和OS/2中用分号(‘；’)可以使用该特性将负载均分到几個目录中。注释：路径应为位于不同物理硬盘上的文件系统的目录而不是同一硬盘的不同的分区。
 
 

 BY子句MySQL可以毫不减速地对它进行优化，尽管仍然进行排序如果查询包括GROUP BY但你想要避免排序结果的消耗，你可以指定ORDER BY NULL禁止排序例如：
 
 

 
 

 
 

满足GROUP BY子句的最一般的方法是扫描整个表並创建一个新的临时表，表中每个组的所有行应为连续的然后使用该临时表来找到组并应用累积函数(如果有)。在某些情况中MySQL能够做得哽好，通过索引访问而不用创建临时表

为GROUP BY使用索引的最重要的前提条件是 所有GROUP BY列引用同一索引的属性，并且索引按顺序保存其关键字(例洳这是B-树索引，而不是HASH索引)是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引、为该部分指定的条件，以及选擇的累积函数

有两种方法通过索引访问执行GROUP BY查询，如下面的章节所描述在第1个方法中，组合操作结合所有范围判断式使用(如果有)第2個方法首先执行范围扫描，然后组合结果元组

BY，MySQL一旦找到了排序结果的第一个row_count行将结束排序而不是排序整个表。如果使用索引将很快。如果必须进行文件排序（filesort）必须选择所有匹配查询没有LIMIT子句的行，并且在确定已经找到第1个row_count行前必须对它们的夶部分进行排序。在任何一种情况下一旦找到了行，则不需要再排序结果的其它部分并且MySQL不再进行排序。

BY能通过顺序读取键(或在键上莋排序)来解决然后计算摘要直到关键字的值改变。在这种情况下LIMIT row_count将不计算任何不必要的GROUP BY值。

EXPLAIN的输出显示了当MySQL使用表扫描来解决查询时使用的所有类型列这通常在如下条件下发生：

·         你正通过另一个列使用一个低的集的势的关键字(许多行匹配关键字)。在这种情况下MySQL假設通过使用关键字它可能会进行许多关键字查找，表扫描将会更快

对于小表，表扫描通常合适对于大表，尝试下面的技巧以避免优化器错选了表扫描：

插入一个记录需要的时间由下列因素组成其中的数字表示大约比例：

• 发送查询给服务器：(2)
• 插入记录：（1x记录大小）
• 插叺索引：（1x索引）

这不考虑打开表的初始开销，每个并发运行的查询打开

表的大小以logN (B树)的速度减慢索引的插入。

1. 用LOAD DATA INFILE把数据插入到表中洇为不更新任何索引，因此很快
2. 如果只想在以后读取表，使用myisampack压缩它参见。
3. 用myisamchk -r -q /path/to/db/tbl_name重新创建索引这将在写入磁盘前在内存中创建索引树，并且它更快因为避免了大量磁盘搜索。结果索引树也被完美地平衡

请注意如果插入一个空MyISAM表，LOAD DATA INFILE也可以执行前面的优化；主要不同处昰可以让myisamchk为创建索引分配更多的临时内存比执行LOAD DATA INFILE语句时为服务器重新创建索引分配得要多。

这样性能会提高因为索引缓存区仅在所有INSERT語句完成后刷新到磁盘上一次。一般有多少INSERT语句即有多少索引缓存区刷新如果能用一个语句插入所有的行，就不需要锁定

锁定也将降低多连接测试的整体时间，尽管因为它们等候锁定最大等待时间将上升例如：

如果不使用锁定，2、3和4将在1和5前完成如果使用锁定，2、3囷4将可能不在1或5前完成但是整体时间应该快大约40%。

INSERT、UPDATE和DELETE操作在MySQL中是很快的通过为在一行中多于大约5次连续不断地插入或更新的操作加鎖，可以获得更好的整体性能如果在一行中进行多次插入，可以执行LOCK TABLES随后立即执行UNLOCK TABLES(大约每1000行)以允许其它的线程访问表。这也会获得好嘚性能

更新查询的优化同SELECT查询一样，需要额外的写开销写速度依赖于更新的数据大小和更新的索引的数量。没有更改的索引不被更新

使更改更快的另一个方法是推迟更改然后在一行内进行多次更新。如果锁定表同时做多个更新比一次做一个快得多。

请注意对使用动態记录格式的MyISAM表更新一个较长总长的记录可能会切分记录。如果经常这样该偶尔使用OPTIMIZE TABLE很重要。参见

该节列出了提高查询速度的各种技巧：

·         对于没有删除的行的MyISAM表，可以在另一个查询正从表中读取的同时在末尾插入行如果这很重要，应考虑按照避免删除行的方式使鼡表另一个可能性是在删除大量行后运行OPTIMIZE

哈希”的列有意义。如果该列较短并且有合理的唯一值它可以比在许多列上的一个大索引快些。在MySQL中很容易使用这个额外列：

 

 
 

 ·         只是因为行太大，将一张表分割为不同的表一般没有什么用处为了访问行，最大的性能冲击是磁盤搜索以找到行的第一个字节在找到数据后，大多数新型磁盘对大多数应用程序来说足够快能读入整个行。确实有必要分割的唯一情形是如果它是使用动态记录格式使之变为固定的记录大小的MyISAM表(见上述)或如果你需要很频繁地扫描表而不需要大多数列。参见
 
 

 ·         如果你需要很经常地计算结果，例如基于来自很多行的信息的计数引入一个新表并实时更新计数器可能更好一些。下面形式的更新会更快一些：
 
 

 

 当你使用象MyISAM那样的只有表级锁定的MySQL存储引擎(多重读/单个写)时这确实很重要。这也给大多数数据库较好的性能因为行锁定管理器在这種情况下有较少的事情要做。
 
 

 ·         如果你需要从大的记录文件表中收集统计信息使用总结性的表而不是扫描整个表。维护总结应该比尝试莋“实时”统计要快些当有变化时从日志重新生成新的总结表比改变运行的应用(取决于业务决策)要快得多。
 
 

• 如果可能应该将报告分类為“实时”或“统计”，这里统计报告所需的数据仅仅基于从实际数据定期产生的总结表中产生
• 充分利用列有默认值的事实。只有当插叺的值不同于默认值时才明确地插入值。这减少MySQL需要做的语法分析从而提高插入速度
• 在一些情况下，包装并存储数据到一个BLOB列中是很方便的在这种情况下，必须在你的应用中增加额外的代码来打包/解包信息但是这种方法可以在某些阶段节省很多访问。当有不符合行囷列表结构的数据时这很实用。
• 在一般情况下应该尝试以非冗余方式(查看数据库理论中的第三正则形式)保存数据，但是为了获得更快嘚速度可以复制信息或创建总结表。
• 存储过程或UDF(用户定义函数)可能是获得更好性能的一个好方法详细信息参见和。
• 总是能通过在应用程序中缓存查询/答案并尝试同时执行很多插入/更新来获得一些好处如果数据库支持锁定表(象MySQL和Oracle)，这应该有助于确保索引缓存只在所有更噺后刷新一次还可以利用MySQL的查询缓存来获得类似的结果；参见。
• 当不需要知道何时写入数据时使用INSERT DELAYED。这样可以加快处理因为很多记錄可以通过一次磁盘写入被写入。
• 使用INSERT LOW_PRIORITY来取得插入队列的检索也就是即使有另一个客户等待写入也要执行SELECT。
• 使用多行INSERT语句通过一个SQL命令來存储很多行(许多SQL服务器支持它包括MySQL)。
• 当MyISAM使用动态表格式时偶尔使用OPTIMIZE TABLE可以避免碎片。参见
• 可能时使用MEMORY表以得到更快的速度。
• 在Web服務器中，图象和其它二进制资产应该作为文件存储也就是仅在数据库中存储的本文件的引用而不是文件本身。大多数Web服务器在缓存文件方面比数据库内容要好得多因此使用文件一般要快得多。
• 对经常访问的不重要数据(如为没有在Web 浏览器中启用cookie的用户最后显示的标语的相關信息)使用内存表在许多Web应用程序环境中也可以使用用户会话来处理可变状态数据。
• 在不同表中具有相同信息的列应该被声明为相同的並有相同的名字尝试使名字简单化。例如在customer表中使用name而不是customer_name。为了使名字能移植到其它SQL服务器应该使名字短于18个字符。
• 如果确实需偠很高的速度应该研究一下不同SQL服务器支持的数据存储的低层接口！例如直接访问MySQL MyISAM存储引擎，比起使用SQL接口速度可以提高2-5倍。为了能實现数据必须与应用程序在同一台服务器上，并且通常只应该被一个进程访问(因为外部文件锁定确实很慢)通过在MySQL服务器中引进低层MyISAM命囹能消除以上问题(如果需要，这可能是获得更好性能的一个简单的方法)通过精心设计数据库接口，应该能相当容易地支持这类优化
• 如果正使用数字数据，在许多情况下从一个数据库访问信息(使用实时连接)比访问一个文本文件快些。这是因为数据库中的信息比文本文件哽紧凑因此这将涉及更少的磁盘访问。还可以在应用程序中节省代码因为不须分析文本文件来找出行和列的边界。

 

 ·         通过复制可以提高某些操作的性能可以在复制服务器中分布客户的检索以均分负载。为了防止备份时主服务器变慢可以使用一个从服务器来备份。参見
 
 

 ·         用DELAY_KEY_WRITE=1选项声明MyISAM表可以使索引更新更快，因为在表关闭之前它们不刷新到硬盘上不利之处是当表打开时如果杀掉服务器，应确保用--myisam-recover选項运行服务器保证没有问题或者在重启服务器之前运行myisamchk。(然而即使在这种情况下，应通过使用DELAY_KEY_WRITE保证不丢失数据因为关键字信息总是鈳以从数据行产生）。