一次mysql优化经历

某日运维突然说无线终端的频道页接口訪问量非常大，memcache缓存扛只是来。导致mysql并发查询量太大，导致server不停地宕机，仅仅能不停地重新启动机器。遗憾的是运维并没有告诉mysql查询量详细有多大【无量化，比方一秒多少个查询…】。

针对这个问题。有同事建议改了mysql+memcache的架构。採用redis存储更佳。可是问题的真正原因是什么呢？mysql一秒钟扛几百个并发查询应该是能够的吧？带着疑问。我让运维给出慢查询log。

Oh,my god…慢查询记录太多，都是一秒钟以上的。可是基本上是同一条语句的查询。

explain一下：

Sql语句中有order by zj_lastupdate，明明在这个字段上建立了索引的，但为什么没用呢【这个表上建立了太多联合索引，以致zj_lastupdate被无视了】，所以导致这条查询使用了暂时表【using temporary】和文件排序【usingfilesort】。

 解决的办法是在sql语句中加上use index(zj_lastupdate)。提醒mysql引擎使用指定索引字段。

再explain一下：

显然。这次查询引擎会使用zj_lastupdate了。

优化的效果是相当的明显，从之前的1.5秒降到0.015秒，百倍的性能提升。

当然，这个问题解决之后，也就没有出现宕机的情形了，我们也没有改架构。

 

再说一个mysql优化经历，2表相连，一对一的关系。优化之前的sql语句大概是selectdistinct(movieid) as id…，explain的结果是：

显然，一对一关系的表，无需加入distinctkeyword【算是画蛇添足吧】，去掉之后，再explain：

优化前后性能提升10倍左右。

Mysql的查询优化有非常多基础理论，能够从查询语句。表结构【分表，字段冗余】，字段类型，索引，存储引擎，缓存，系统内核參数。磁盘IO等方面考虑，可是非常重要的一点是写出详细的sql语句，针对这特定的语句进行详细的优化，当然前提是保证结果是准确的。