EXPLAIN列的解释：
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key：实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句
中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MYSQL认为必须检查的用来返回请求数据的行数
Extra：关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢

extra列返回的描述的意义
Distinct:一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
Not exists: MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
Range checked for each Record（index map:#）:没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
Using filesort: 看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
Using temporary 看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）
system 表只有一行：system表。这是const连接类型的特殊情况
const:表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
eq_ref:在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
range:这个连接类型使用索引返回一个范围中的行，比如使用>或
index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
ALL:这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免

　　设计SQL后，应使用explain命令检查SQL，看是否使用到索引，是否存在filesort,重点检查检索的行数（rows）是否太大。

　　一般来说.

　　rows<1000，是在可接受的范围内的。

　　rows在1000~1w之间，在密集访问时可能导致性能问题，但如果不是太频繁的访问（频率低于1分钟一次），又难再优化的话，可以接受，但需要注意观察

　　rows大于1万时，应慎重考虑SQL的设计，优化SQL，优化db，一般来说不允许频繁运行（频率低于1小时一次）。

　　rows达到10w级别时，坚决不能做为实时运行的SQL。但导数据场合除外，但导数据必须控制好时间，频度。

　　explain SQL语句应该是日常开发中的习惯动作，有时explain出来的结果，可能会出于偏离设计的意料之外,所以

　　**强烈建议在设计SQL，尤其是稍微复杂的SQL时，一定要在测试环境甚至是实际环境上预先进行explain**

　　2.MySQL慢查询日志

　 　一般应打开MySQL的慢查询日志(在my.cnf中加入log_slow_queries和long_query_time两个参数),会记录所有查 询持续时间超过long_query_time的SQL语句，把这些语句log下来之后，再一一分析(explain)优化。

　　3.监视当前进程

　　登陆MySQL,使用showprocesslist查看正在运行的SQL语句，如果正在运行的语句太多，运行时间太长，表示MySQL效率有问题。必要的时候可以将对应的进程kill掉。

　　4.系统命令

　　使用top/vmstat等系统命令来检查MySQL进程占用的cpu,内存,以及磁盘IO量。

　　对MySQL优化的文章很多，这里只提几点平时工作中比较常用到的方法。

　　建表时,显式指定使用innodb数据库引擎，而不是myisam,myisam引擎的锁是表锁,读锁和写锁是互斥的，读写操作是串行的，锁冲突会严重影响并发.而innodb提供行级锁，能提供较好的并发表现，在我们的业务场景里，也不会引起死锁。

　　善用索引，对SQL语句where条件里使用到的字段，合理建立索引。虽然对表建立索引一定程度上会影响写入效率，但在表数据规模不大，写入压力不是特别高的情况下，索引带来的好处是更多的。

　　当SQL语句是由代码动态生成的，如在运行时根据用户操作加入不同的where参数，应在测试阶段对SQL生成的典型情况和边界情况进行测试，看是否有可能造成性能问题。并应适当生成一些日志，供提取最终生成的SQL进行效率分析。

　　对数据应合理分库分表，由应用层去动态的选择库和表。MySQL的innodb表虽然理论上可以装海量的数据，但在我们的业务场景下，数据控制在500w以下会比较合理，追求性能的话，最好控制在200w以下，合理索引。

　　需要联合查询时善用center join/center join而不是直接多表联合，怎么用，查manul ^_^

　　尽量不要使用select套select的复合查询，如果能拆开，尽量拆开,多条精悍的SQL,组合起来可能就是一条庞大的SQL，应该避免。

　　善用cache,将不常修改的，数据量有限的,又是被密集查询的信息，加载到cache里，可以有效的降低数据库压力。在一般的业务场景里，推荐使用开源memcache，简单高效。

　　如果一些逻辑可以放到应用层去完成，可以考虑放到应用层去完成。但如果将SQL逻辑分拆到应用层可能导致对数据更频繁的访问的话，那么需要考虑修改应用逻辑，数据结构，或回到合理的联合查询上来。

　 　比如某些数据的排序可以load到php数组里，再sort.又比如需要查询A,B两个表，A表里的数据是B表里某个字段的对照说明（如 A:t_service表，B.t_task表），A表数据量有限，可以做联合查询，也可以先将A表先load到进程或内存里，用hash结构cache 起来，再查B表，然后在cache里依次查询hash，获得对照说明。

　　关于导数据和统计性查询.导数据在计算和磁盘io上对数据库压力都会很大，应在时间和空间上合理分摊数据库压力如果需要导出批量的特定数据做分析，应建立专供数据分析的数据库服务器，或者建立临时库表，先导出数据，再在上面做分析运算。

　 　导数据等可能引起批量数据读取的操作，应建立定时任务，在数据库不繁忙的时段（凌晨1~7时)运行一般的统计操作，对实时性要求都不会太高（5~10分 钟以上，甚至一天，一周等），这种数据不应在每次访问时运行库中直接count,group,而是应该由定时任务导出，建立结果表或中间结果表，供最终用 户使用。

　　生产数据库上的操作权限应严格控制，而开发人员在生产数据库上直接运行SQL语句，要尽量慎重。

　　能做到以上这些，基本上可以算MySQL以及相关系统优化入门，可以保证不要让我们的数据库整天累趴下了。

　　最后，即使做足了功课，也还是要例行的对数据库运行情况进行观察，监控，尽早发现其性能瓶颈，在未造成危害前解决掉。

　　编辑推荐

　　通过分区（Partition）提升MySQL性能

　　用好SELECT索引 提高MySQL查询统计速度

　　PHP实现的MySQL读写分离