【IT168技术文档】对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明：

　　数据库设计

　　适度的反范式,注意是适度的

　　我们都知道三范式，基于三范式建立的模型是最有效保存数据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　

　　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000 ，导致更新一个单位名称还要更新4000条冗余记录。由此可见，这个冗余根本就是适得其反。

　　下面这个冗余就很好　　

　　可以看到，[学生考试总分]是冗余的，这个分数完全可以通过[得分情况]汇总得到。在【学生考试总分】里，一次考试一个学生只有一条记录，而在【得分情况】里，一个学生针对试卷里一个小题的一个小问一条记录，粗略的算一下比例大概是1：100。而且判卷子得分是不会轻易变的，更新的频率不高，所以说这个冗余是比较好的。

　　适当建立索引

　　说起提高数据库性能，索引是最物美价廉的东西了。不用加内存，不用改程序，不用调sql，只要执行个正确的’create index’，查询速度就可能提高百倍千倍，这可真有诱惑力。可是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的I/O。由于索引的存储结构不同于表的存储，一个表的索引所占空间比数据所占空间还大的情况经常发生。这意味着我们在写数据库的时候做了很多额外的工作，而这个工作只是为了提高读的效率。因此，我们建立一个索引，必须保证这个索引不会“亏本”。一般需要遵守这样的规则：

　　索引的字段必须是经常作为查询条件的字段;

　　如果索引多个字段，第一个字段要是经常作为查询条件的。如果只有第二个字段作为查询条件，这个索引不会起到作用;

　　索引的字段必须有足够的区分度;

　　Mysql 对于长字段支持前缀索引;

　　对表进行水平划分

　　如果一个表的记录数太多了，比如上千万条，而且需要经常检索，那么我们就有必要化整为零了。如果我拆成100个表，那么每个表只有10万条记录。当然这需要数据在逻辑上可以划分。一个好的划分依据，有利于程序的简单实现，也可以充分利用水平分表的优势。比如系统界面上只提供按月查询的功能，那么把表按月拆分成12个，每个查询只查询一个表就够了。如果非要按照地域来分，即使把表拆的再小，查询还是要联合所有表来查，还不如不拆了。所以一个好的拆分依据是最重要的。

　　这里有个比较好的实例        

　　每个学生做过的题都记录在这个表里，包括对题和错题。每个题会对应一个或多个知识点，我们需要根据错题来分析学生在哪个知识点上掌握的不足。这个表很容易达到千万级，迫切需要拆分，那么根据什么来拆呢?从需求上看，无论是老师还是学生，最终会把焦点落在一个学生的身上。学生会关心自己，老师会关心自己班的学生。而且每个学科的知识点是不同的。所以我们很容易想到，联合学科和知识点两个字段来拆分这个表。这样拆下来，每个表大概2万条数据，检索效率非常高。

　　对表进行垂直划分

　　有些表记录数并不多，可能也就2、3万条，但是字段却很长，表占用空间很大，检索表时需要执行大量I/O，严重降低了性能。这个时候需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。        

　　【试题内容】、【答案信息】两个表，最初是作为几个字段添加到【试题信息】里的，可以看到试题内容和答案这两个字段很长，在表里有3万记录时，表已经占了1G的空间，在列试题列表时非常慢。经过分析，发现系统很多时候是根据【册】、【单元】、类型、类别、难易程度等查询条件，分页显示试题详细内容。而每次检索都是这几个表做join，每次要扫描一遍1G的表，很郁闷啊。我们完全可以把内容和答案拆分成另一个表，只有显示详细内容的时候才读这个大表，由此就产生了【试题内容】、【答案信息】两个表。

　　选择适当的字段类型，特别是主键

　　选择字段的一般原则是保小不保大，能用占用字节小的字段就不用大字段。比如主键，我们强烈建议用自增类型，不用guid，为什么?省空间啊?空间是什么?空间就是效率!按4个字节和按32个字节定位一条记录，谁快谁慢太明显了。涉及到几个表做join时，效果就更明显了。值得一提的是，datetime和timestamp，datetime占用8个字节，而timestamp占用4个字节，只用了一半，而timestamp表示的范围是1970—2037，对于大多数应用，尤其是记录什么考试时间，登录时间这类信息，绰绰有余啊。

　　文件、图片等大文件用文件系统存储，不用数据库

　　不用多说，铁律!!!数据库只存储路径。

　　外键表示清楚，方便建立索引

　　我们都知道，在powerdesigner里为两个实体建立关系，生成物理模型时会自动给外键建立索引。所以我们不要怕建立关系把线拉乱，建立个ShortCut就好了。

　　掌握表的写入时机

　　在库模式相同的情况下，如何使用数据库也对性能有着重要作用。同样是写入一个表，先写和后写对后续的操作会产生很大影响。例如在上面提到的适度冗余里的例子，        

　　我们最初的目的是记录考生的总分，以达到提高检索效率的目的，也就是在录入成绩时写入这个表。在需求里有这样的要求：列出本次考试的所有学生成绩，没有录入成绩的也显示该学生名称，只是总分显示为空。这个查询就需要用【学生信息】left outer join 【学生考试总分信息】，大家都知道outer join 的效率比join是要低的，为了避免这个问题，我们就在布置考试的时候写入这个表，把所有学生都插入进去，分数都是null，这样一来我们就可以用join达到这个效果了。而且还有这样的好处：在某次考试中，安排了一个班所有学生考试，所有学生都录入了成绩。现在班里转来一个新生，那么在此时如果查询学生成绩，就会列出这个新生，结果是未录入成绩，这显然是不对的。如果在安排的时候就写入，就可以记录下该次考试中实际的考生了，这个表的作用，也就不知是冗余了。

　　宁可集中批量操作，避免频繁读写

　　系统里包含了积分部分，学生和老师通过系统做了操作都可以获得积分，而且积分规则很复杂，限制每类操作获得积分不同，每人每天每类积分都有上限。比如登录，一次登录就可以获得1分，但是不管你登录多少次，一天只能累积一个登录积分。这个还是简单的，有的积分很变态，比如老师积分中有一类是看老师判作业的情况，规则是：老师判了作业，发现学生有错的，学生改过了，老师再判，如果这时候学生都对了，就给老师加分，如果学生还是错的，那就接着改，知道学生都改对了，老师都判完了，才能给老师加分。如果用程序来处理，很可能每个功能都会额外的写一堆代码来处理这个鸡肋似的积分。不仅编程的同事干活找不到重点，还平白给数据库带来了很大的压力。经过和需求人员的讨论，确定积分没有必要实时累积，于是我们采取后台脚本批量处理的方式。夜深人静的时候，让机器自己玩去吧。

　　这个变态的积分规则用批处理读出来是这样的：　　

　　这还只是个中间过程，这要是用程序实时处理，即使编程人员不罢工，数据库也会歇了。

　　选择合适的引擎

　　Mysql提供了很多种引擎，我们用的最多的是myisam，innodb，memory这三类。官方手册上说道myisqm比innodb的读速度要快，大概是3倍。不过书不能尽信啊，《OreIlly.High.Performance.Mysql》这本书里提到了myisam和innodb的比较，在测试中myisam的表现还不及innodb。至于memory，哈哈，还是比较好用的。在批处理种作临时表是个不错的选择(如果内存够大)。在我的一个批处理中，速度比近乎1：10。

　　Sql语句优化

　　Sql语句优化工具

　　·慢日志

　　如果发现系统慢了，又说不清楚是哪里慢，那么就该用这个工具了。只需要为mysql配置参数，mysql会自己记录下来慢的sql语句。配置很简单，参数文件里配置：

　　slow_query_log=d:/slow.txt

　　long_query_time = 2

　　就可以在d:/slow.txt里找到执行时间超过2秒的语句了，根据这个文件定位问题吧。

　　·mysqldumpslow.pl

　　慢日志文件可能会很大，让人去看是很难受的事。这时候我们可以通过mysql自带的工具来分析。这个工具可以格式化慢日志文件，对于只是参数不同的语句会归类类并，比如有两个语句select * from a where id=1 和select * from a where id=2，经过这个工具整理后就只剩下select * from a where id=N，这样读起来就舒服多了。而且这个工具可以实现简单的排序，让我们有的放矢。下面介绍下用法。因为这是个perl脚本，先要安装perl环境。脚本在mysql自带的脚本目录里，我的是在D:\mysql-5.1.30-win32\scripts

　　先mysqldumpslow –help以下，俺主要用的是

　　-s ORDER what to sort by (t, at, l, al, r, ar etc), ‘at’ is default

　　-t NUM just show the top n queries

　　-g PATTERN grep: only consider stmts that include this string

　　-s，是order的顺序，说明写的不够详细，俺用下来，包括看了代码，主要有

　　c,t,l,r和ac,at,al,ar，分别是按照query次数，时间，lock的时间和返回的记录数来排序，前面加了a的时倒叙

　　-t，是top n的意思，即为返回前面多少条的数据

　　-g，后边可以写一个正则匹配模式，大小写不敏感的

　　mysqldumpslow -s c -t 20 slow.txt

　　mysqldumpslow -s r -t 20 slow.txt

　　上述命令可以看出访问次数最多的20个sql语句和返回记录集最多的20个sql。

　　mysqldumpslow -t 10 -s t -g “left join” slow.txt

　　这个是按照时间返回前10条里面含有左连接的sql语句。

　　Explain

　　现在我们已经知道是哪个语句慢了，那么它为什么慢呢?看看mysql是怎么执行的吧，用explain可以看到mysql执行计划，下面的用法来源于手册

　　EXPLAIN语法(获取SELECT相关信息)

　　EXPLAIN [EXTENDED] SELECT select_options

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

　　· EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。

　　· 如果在SELECT语句前放上关键词EXPLAIN，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的每个输出行提供一个表的相关信息，并且每个行包括下面的列：

　　· id

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

　　· select_type

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

　　⊙ SIMPLE

　　简单SELECT(不使用UNION或子查询)

　　⊙  PRIMARY

　　最外面的SELECT

　　⊙ UNION

　　UNION中的第二个或后面的SELECT语句

　　⊙ DEPENDENT UNION

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

　　⊙  UNION RESULT

　　UNION的结果。

　　⊙ SUBQUERY

　　子查询中的第一个SELECT

　　⊙ DEPENDENT SUBQUERY

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

　　⊙ DERIVED

　　导出表的SELECT(FROM子句的子查询)

　　· table

　　输出的行所引用的表。

　　· type

　　联接类型。下面给出各种联接类型，按照从非常好的类型到最坏类型进行排序：

　　⊙ system

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

　　⊙ const

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

　　const用于用常数值比较PRIMARY KEY或UNIQUE索引的所有部分时。在下面的查询中，tbl_name可以用于const表：

　　SELECT * from tbl_name WHERE primary_key=1;

　　SELECT * from tbl_name

　　WHERE primary_key_part1=1和 primary_key_part2=2;

　　⊙eq_ref

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

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

　　在下面的例子中，MySQL可以使用eq_ref联接来处理ref_tables：

　　SELECT * FROM ref_table,other_table

　　WHERE ref_table.key_column=other_table.column;

　　SELECT * FROM ref_table,other_table

　　WHERE ref_table.key_column_part1=other_table.column

　　AND ref_table.key_column_part2=1;

　　⊙ref

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

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

　　在下面的例子中，MySQL可以使用ref联接来处理ref_tables：

　　SELECT * FROM ref_table WHERE key_column=expr;

　　SELECT * FROM ref_table,other_table

　　WHERE ref_table.key_column=other_table.column;

　　SELECT * FROM ref_table,other_table

　　WHERE ref_table.key_column_part1=other_table.column

　　AND ref_table.key_column_part2=1;

　　⊙ref_or_null

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

　　在下面的例子中，MySQL可以使用ref_or_null联接来处理ref_tables：

　　SELECT * FROM ref_table

　　WHERE key_column=expr OR key_column IS NULL;

　　⊙ index_merge

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

　　⊙ unique_subquery

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

　　value IN (SELECT primary_key FROM single_table WHERE some_expr)

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

　　⊙ index_subquery

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

　　value IN (SELECT key_column FROM single_table WHERE some_expr)

　　⊙ range

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

　　当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较关键字列时，可以使用range：

　　SELECT * FROM tbl_name

　　WHERE key_column = 10;

　　SELECT * FROM tbl_name

　　WHERE key_column BETWEEN 10 and 20;

　　SELECT * FROM tbl_name

　　WHERE key_column IN (10,20,30);

　　SELECT * FROM tbl_name

　　WHERE key_part1= 10 AND key_part2 IN (10,20,30);

　　⊙ index

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

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

　　⊙ALL

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

　　· possible_keys

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

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

　　为了看清一张表有什么索引，使用SHOW INDEX FROM tbl_name。

　　· key

　　key列显示MySQL实际决定使用的键(索引)。如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

　　对于MyISAM和BDB表，运行ANALYZE TABLE可以帮助优化器选择更好的索引。对于MyISAM表，可以使用myisamchk --analyze。

　　· key_len

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

　　· ref

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

　　· rows

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

　　· Extra

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

　　 ⊙Distinct

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

　　⊙Not exists

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

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

　　SELECT * 从t1 LEFT JOIN t2 ON t1.id=t2.id

　　WHERE t2.id IS NULL;

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

　　⊙ range checked for each record (index map: #)

　　MySQL没有发现好的可以使用的索引，但发现如果来自前面的表的列值已知，可能部分索引可以使用。对前面的表的每个行组合，MySQL检查是否可以使用range或index_merge访问方法来索取行。

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

　　⊙Using filesort

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

　　⊙Using index

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

　　⊙Using temporary

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

　　⊙Using where

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

　　如果想要使查询尽可能快，应找出Using filesort 和Using temporary的Extra值。

　　⊙Using sort_union(...), Using union(...), Using intersect(...)

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

　　⊙Using index for group-by

　　类似于访问表的Using index方式，Using index for group-by表示MySQL发现了一个索引，可以用来查询GROUP BY或DISTINCT查询的所有列，而不要额外搜索硬盘访问实际的表。并且，按最有效的方式使用索引，以便对于每个组，只读取少量索引条目。

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

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

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

　　EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,

　　tt.ProjectReference, tt.EstimatedShipDate,

　　tt.ActualShipDate, tt.ClientID,

　　tt.ServiceCodes, tt.RepetitiveID,

　　tt.CurrentProcess, tt.CurrentDPPerson,

　　tt.RecordVolume, tt.DPPrinted, et.COUNTRY,

　　et_1.COUNTRY, do.CUSTNAME

　　FROM tt, et, et AS et_1, do

　　WHERE tt.SubmitTime IS NULL

　　AND tt.ActualPC = et.EMPLOYID

　　AND tt.AssignedPC = et_1.EMPLOYID

　　AND tt.ClientID = do.CUSTNMBR;

　　对于这个例子，假定：

　　· 被比较的列声明如下：　　

　　· 表有下面的索引：　　

　　· tt.ActualPC值不是均匀分布的。

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

　　table type possible_keys key key_len ref rows Extra

　　et ALL PRIMARY NULL NULL NULL 74

　　do ALL PRIMARY NULL NULL NULL 2135

　　et_1 ALL PRIMARY NULL NULL NULL 74

　　tt ALL AssignedPC, NULL NULL NULL 3872

　　ClientID,

　　ActualPC

　　range checked for each record (key map: 35)

　　因为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个字符：

　　mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

　　现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)，再执行EXPLAIN语句产生这个结果：

　　table type possible_keys key key_len ref rows Extra

　　tt ALL AssignedPC, NULL NULL NULL 3872 Using

　　ClientID, where

　　ActualPC

　　do ALL PRIMARY NULL NULL NULL 2135

　　range checked for each record (key map: 1)

　　et_1 ALL PRIMARY NULL NULL NULL 74

　　range checked for each record (key map: 1)

　　et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1

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

　　第2种方法能消除tt.AssignedPC = et_1.EMPLOYID和tt.ClientID = do.CUSTNMBR比较的列的长度失配问题：

　　mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),

　　-> MODIFY ClientID VARCHAR(15);

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

　　table type possible_keys key key_len ref rows Extra

　　et ALL PRIMARY NULL NULL NULL 74

　　tt ref AssignedPC, ActualPC 15 et.EMPLOYID 52 Using

　　ClientID, where

　　ActualPC

　　et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1

　　do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

　　这几乎很好了。

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

　　mysql> ANALYZE TABLE tt;

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

　　table type possible_keys key key_len ref rows Extra

　　tt ALL AssignedPC NULL NULL NULL 3872 Using

　　ClientID, where

　　ActualPC

　　et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1

　　et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1

　　do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

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

　　我们需要特别注意的是key、Extra字段。Key字段显示用了哪个索引，注意看是不是用了索引，如果用了是不是效率最高的。Extra字段会说明是否用了临时表，是否用了基于磁盘的临时表，是否用了文件排序，是否用了全索引扫描，where是有数据库engine产生的还是由数据库server限制的。

　　如果数据库慢了，想要看看mysql正在干什么，可以执行这个语句，可以列出mysql当前连接在执行的sql语句。　　

　　………………………………………………………………

　　以下内容摘自手册

　　SHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程(也就是，与您正在使用的MySQL账户相关的线程)。如果您不使用FULL关键词，则只显示每个查询的前100个字符。

　　本语句报告TCP/IP连接的主机名称(采用host_name:client_port格式)，以方便地判定哪个客户端正在做什么。

　　如果您得到“too many connections”错误信息，并且想要了解正在发生的情况，本语句是非常有用的。MySQL保留一个额外的连接，让拥有SUPER权限的账户使用，以确保管理员能够随时连接和检查系统(假设您没有把此权限给予所有的用户)。

　　在来自SHOW PROCESSLIST的输出中常见的一些状态：

　　· Checking table

　　线程正在执行(自动)表格检查。

　　· Closing tables

　　意味着线程正在刷新更改后的表数据，并正在关闭使用过的表。这应该是一个快速的操作。如果不快，则您应该验证您的磁盘没有充满，并且磁盘没有被超负荷使用。

　　· Connect Out

　　连接到主服务器上的从属服务器。

　　· Copying to tmp table on disk

　　临时结果集合大于tmp_table_size。线程把临时表从存储器内部格式改变为磁盘模式，以节约存储器。

　　· Creating tmp table

　　线程正在创建一个临时表，以保持部分结果。

　　· deleting from main table

　　服务器正在执行多表删除的第一部分，只从第一个表中删除。

　　· deleting from reference tables

　　服务器正在执行多表删除的第二部分，从其它表中删除匹配的行。

　　· Flushing tables

　　线程正在执行FLUSH TABLES，并正在等待所有线程，以关闭表。

　　· FULLTEXT initialization

　　服务器正在准备执行一个自然语言全文本搜索。

　　· Killed

　　有人已经向线程发送了一个KILL命令。在下一次检查终止标记时，应放弃。该标记在MySQL的每个大循环中都检查，但是在有些情况下，线程终止只需要较短的时间。如果该线程被其它线程锁定，则只要其它线程接触锁定，终止操作就会生效。

　　· Locked

　　该查询被其它查询锁定。

　　· Sending data

　　线程正在为SELECT语句处理行，同时正在向客户端发送数据。

　　· Sorting for group

　　线程正在进行分类，以满足GROUP BY要求。

　　· Sorting for order

　　线程正在进行分类，以满足ORDER BY要求。

　　· Opening tables

　　线程正在试图打开一个表。这应该是非常快的过程，除非打开操作受到阻止。例如，一个ALTER TABLE或一个LOCK TABLE语句可以阻止打开一个表，直到语句完成为止。

　　· Removing duplicates

　　查询正在使用SELECT DISTINCT。使用时，在早期阶段，MySQL不能优化不同的操作。因此，MySQL要求一个额外的阶段，以便在把结果发送给客户端之前取消所有的复制行。

　　· Reopen table

　　线程得到一个表锁定，但是在得到锁定后被通知带下方的表结构已更改了。它已经释放了锁定，关闭了表，并试图重新打开它。

　　· Repair by sorting

　　修复代码正在使用一个分类来创建索引。

　　· Repair with keycache

　　修复代码正在通过关键缓存一个接一个地使用创建关键字。这比通过分类修复要慢很多。　　

　　· Searching rows for update

　　线程正在进行第一阶段，以在更新之前，查找所有匹配的行。如果UPDATE正在更改用于查找相关行的索引，则必须这么做。

　　· Sleeping

　　线程正在等待客户端，以向它发送一个新语句。

　　· System lock

　　线程正在等待得到一个用于表的外部系统锁定。如果您没有正在使用多个正在访问同一个表的mysqld服务器，则您可以使用--skip-external-locking选项禁用系统锁定。

　　· Upgrading lock

　　INSERT DELAYED管理程序正在试图得到一个表锁定，以插入行。

　　· Updating

　　线程正在搜索行，并正在更新这些行。

　　· User Lock

　　线程正在等待GET_LOCK()。

　　· Waiting for tables

　　线程得到一个通知，表的底层结构已经改变，需要重新打开表以得到新的结构。但是，为了能重新打开表，必须等待，直到所有其它的线程已经关闭了正在被质询的表。

　　如果其它线程已经对正在被质询的表使用了FLUSH TABLES或以下语句之一：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE或OPTIMIZE TABLE;则会出现通知。

　　· waiting for handler insert

　　INSERT DELAYED管理程序已经处理了所有处于等待状态的插入，并正在等待新插入。

　　多数状态对应于非常快的操作。如果一个线程在这些状态下停留了数秒，则可能是有问题，需要进行调查。

　　有一些其它的状态，在前面的清单中没有提及，但是其中有很多状态对于查找服务器中的程序错误是有用的。

　　从这里可以看到是不是有表锁死了，是不是有些语句执行了很久，甚至可以通过kill id 语句灭了捣乱的连接。

　　减少不必要的表关联

        有时候一个查询需要很多表关联，表一多了就容易让人犯晕，没必要join的也都给塞进来了，看看下面这个句子：　　

        老师在布置作业的时候，会写入【布置班级】表和【学生作业评价】表，现在要检索每个班、每个学生在一段时间内做过的作业。我们的同事开始的join是走了红色的那条线，后来经过分析，显然蓝线就够了。

　　尽可能的限制条件

　　Where条件多了好啊，多了建索引的可能，也减少了结果集，尤其对于那种以查询结果做derived表的，更应该从中间就限制结果集。比如这个查询　　

　　可以看到，derived表t是限制了v.bas_person_id =12762，最终的结果集是只查一个人的情况，derived表t、t1是针对所有人做的汇总，而在和derived表t 做join的时候，给过滤掉了，最终只保留了v.bas_person_id =12762的记录，这是何苦呢?直接在t1 和 t2里过滤掉多好，于是在t1 和t2里分别加上条件person_id=12762。

　　过大的子查询用临时表处理效果会好的多

　　-- /*以学生做题本为基础，加载某一天各班级的做题信息*/　　

　　-- 临时表扶正

　　truncate table bas_class_do_list;

　　drop table bas_class_do_list;

　　rename table tmp_bas_class_do_list to bas_class_do_list;

　　大家可以看到，我是先把select的结果insert到临时表里，建立索引后，又用derived表t2更新临时表的数据，最后临时表替换成正式表。最初的时候，我是直接用select表和derived表t2做关联，直接insert到正式表里，这样写的select和t2做join的速度非常慢。改成这种写法后，速度由8分钟减少到40秒。

　　通过这个例子我们也可以看到，大批量插入前先删除索引，插入后再建立索引，效果要比直接插入好的多。

　　Join Vs select 结果集作列

　　有时候我们需要关联很多表统计：

　　select f1, f2, count(*) from a join b join c join d join e ……

　　如果结果集很小，只统计出几条数据来，那么可以换成这样写

　　Select f1, f2, (select count(*) from a join b ) from c……

　　比如下面的例子：　　

　　改写成下面的，速度由0.625秒优化到: 0.032　　

　　如果什么都做不了，试试全索引扫描

　　如果一个语句实在不能优化了，那么还有一个方法可以试试：索引覆盖。

　　如果一个语句可以从索引上获取全部数据，就不需要通过索引再去读表，省了很多I/O。比如这样一个表        

　　如果我要统计每个学生每道题的得分情况，我们除了要给每个表的主键外键建立索引，还要对【得分情况】的实际得分字段索引，这样，整个查询就可以从索引得到数据了。

　　Join、In、not in、exist、not exist并不是绝对的

　　网上很多教程讨论了join、in和exist 的性能差异，其实这不是绝对的，对于效率不理想的语句，还是应该换换写法试试看。

　　Like

　　Like毕竟效率太低，必要的话可以试试全文检索。对于中文全文检索，可以结合程序分词来实现。

　　什么情况下查询用不到索引

　　参见手册 7.4.3列索引, 7.4.4所列索引, 7.4.5 mysql如何使用索引

　　去掉不必要的排序，如果必要，尽量用主键排序代替

　　显而易见却容易被忽视的问题。

　　数据库参数配置

　　最重要的参数就是内存，我们主要用的innodb引擎，所以下面两个参数调的很大

　　# Additional memory pool that is used by InnoDB to store metadata

　　# information. If InnoDB requires more memory for this purpose it will

　　# start to allocate it from the OS. As this is fast enough on most

　　# recent operating systems, you normally do not need to change this

　　# value. SHOW INNODB STATUS will display the current amount used.

　　innodb_additional_mem_pool_size = 64M

　　# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and

　　# row data. The bigger you set this the less disk I/O is needed to

　　# access data in tables. On a dedicated database server you may set this

　　# parameter up to 80% of the machine physical memory size. Do not set it

　　# too large, though, because competition of the physical memory may

　　# cause paging in the operating system. Note that on 32bit systems you

　　# might be limited to 2-3.5G of user level memory per process, so do not

　　# set it too high.

　　innodb_buffer_pool_size = 5G

　　对于myisam，需要调整key_buffer_size

　　当然调整参数还是要看状态，用show status语句可以看到当前状态，以决定改调整哪些参数

　　Cretated_tmp_disk_tables 增加tmp_table_size

　　Handler_read_key 高表示索引正确 Handler_read_rnd高表示索引不正确

　　Key_reads/Key_read_requests 应小于0.01 计算缓存损失率，增加Key_buffer_size

　　Opentables/Open_tables 增加table_cache

　　select_full_join 没有实用索引的链接的数量。如果不为0，应该检查索引。

　　select_range_check 如果不为0，该检查表索引。

　　sort_merge_passes 排序算法已经执行的合并的数量。如果该值较大，应增加sort_buffer_size

　　table_locks_waited 不能立即获得的表的锁的次数，如果该值较高，应优化查询

　　Threads_created 创建用来处理连接的线程数。如果Threads_created较大，要增加 thread_cache_size值。

　　缓存访问率的计算方法Threads_created/Connections。

　　合理的硬件资源和操作系统

　　如果你的机器内存超过4G，那么毋庸置疑应当采用64位操作系统和64位mysql

　　读写分离

　　如果数据库压力很大，一台机器支撑不了，那么可以用mysql复制实现多台机器同步，将数据库的压力分散。　　

　　Master

　　Slave1

　　Slave2

　　Slave3

　　主库master用来写入，slave1—slave3都用来做select，每个数据库分担的压力小了很多。

　　要实现这种方式，需要程序特别设计，写都操作master，读都操作slave，给程序开发带来了额外负担。当然目前已经有中间件来实现这个代理，对程序来读写哪些数据库是透明的。官方有个mysql-proxy，但是还是alpha版本的。新浪有个amobe for mysql，也可达到这个目的，结构如下　　

　　使用方法可以看amobe的手册。