MYSQL一次调优经验

前言：这是最近刚发生在公司的一次应用系统的mysql调优过程，事情的过程是这样的：公司的一个销售系统，用的是mysql数据库，在元旦的前夕突然就宕机了。差不多导致业务系统4个小时左右使用有问题；

因为这个系统乙方公司尚未完全交付，所以数据库的运维的工作，作为甲方也还未交接到我的手上，这个事情也是元旦过后上班才知道的；

 

其实对于这种问题我是可以不用管的，相信很多人也会选择当作不知道。但是我还是想把问题找出来并解决掉，这个出于以下两个原因：

• 业务系统有问题，受伤的是公司，作为公司的一员，当然希望公司的系统能够运行的更好；
• 处理这个问题过后，经验的积累是一笔很重要的财富；（当然也有一些朋友更愿意出现的场景是：系统出现问题了，其他所有人都搞不定，这个时候老板又很着急，然后关键时刻我挺身而出，来一句经典台词：“我来试一下”，就像电视或电影里面的英雄一样，敲一下键盘，整个系统又恢复正常了；然后整个办公室的人都跳起来了，老板也笑了），虽然以上都是不可能发生，在一个不重视it技术的团队里，我只能像雷锋一样把默默做的把每件好事记录起来；

 

以上那么多废话，其实是给我们这些在甲方做技术的朋友们听的（特别是非互联网企业），因为有时候我们做了一件很有价值的事情，但是老板和领导却当作很平常一样。但是不管老板和领导是怎样的态度，作为我们还是要把事情做好了，如果你不明白，请百度一下苹果树的故事；

 

以下是整个问题解决的过程：

解决过程第一步：了解系统的情况，知己知彼，百战不殆

1、检查操作系统的配置：CPU、内存、还有存储空间（需要了解数据是放在本地硬盘还是在存储上面，如果是本地硬盘的话，需要了解做raid几）

2、咨询整个系统的架构：这套系统采用了主从结构，并实现了读写分离（这种读写分离不是完全的，很多及时性要求非常高的业务读还是在主库上面进行）

3、检查数据库的参数配置：数据库的版本、表的存储引擎、表空间的管理、数据库内存的配置等；

4、和业务咨询该系统的使用业务类型（OLTP或OLAP，其实很多OLTP的系统偶尔也做着OLAP的工作）

5、了解数据库的表数据量；（几千行的数据跟几百万行的数据是完全不一样的概念）

6、了解系统发生问题之前是否有相应的变更；

7、检查数据库的报错日志；

 

第二步：经过了解以上的内容之后，打开数据库的慢查询日志和没有使用索引的语句；（把运行超过10秒的语句记录下来）

这里的操作步骤，在前面的文档中已经写了，麻烦自己查找一下；

 

第三步：打开慢查询一个多星期之后发现了一个很明显的问题，这里直接上图

1

Count: 10063 Time=16.94s (170462s)

Update  spkcb a Set  gg1_id=(Select id From com_base_guige1 gg1 Where gg1.ggdm = a.gg1dm limit N ), gg2_id=(Select id From com_base_guige2 gg2 Where gg2.ggdm = a.gg2dm limit N ), sp_id = (Select id From com_base_shangpin sp Where sp.spdm = a.spdm), zd_id = (Select id From com_base_kehu kh Where kh.khdm = a.drp_ckdm) Where mid= 'S'

以上只是慢查询中的一个最最典型的例子：有一个过程在这差不多10天的时间里，运行了10063次，每次运行了16.94秒，每天平均云习惯1000次，经了解这是一个更新库存的语句。

这个表spkcb有30万的数据；

再次查询mid具有很强的选择性；

 

看到这里简直被打败了，这么一条语句，居然没有加索引。。。。。。。。。。。。。

 

第四步：列优化方案（时间跨度，是为了保证采样的典型性）

1、在一个月之内监控数据库所有超过10秒的慢查询日志；

2、在第二个月开始监控数据库所有超过5秒的慢查询日志；

3、在第三个月开始监控数据库所有超过3秒的慢查询日志；

4、在这期间业务对于一些数量大、且实时性要求不高的表建议通过类似物化视图的方式进行；

 

插曲：整个过程还让乙方提供了解决方案：分库分表、把一些应用搭建在阿里云上面……………………………………………….等等一些很炫的技术方案；（接着忽悠）

 

从整个文档的记录下来，我一直在思考一个问题：为什么一个简单的索引问题，乙方公司不能发现？

思考之下，得出自己的答案：

1、乙方公司没有一个专业的DBA；

2、开发人员在设计应用的时候，工作往往停留在应用的层面，比如编写SQL语句、存储过程之类，他们往往会忽略了这个时候索引的存在，或者认为这是DBA的工作；

3、DBA一般不了解业务的情况，不会在系统正常运行时添加索引，一般都是业务反馈有问题或者系统宕掉的情况下，经过监控后才增加索引的；

4、很多人员不管是乙方还是甲方技术都还是半桶水的时候，就大谈数据库架构、应用架构，其实如果真正去观察其实很多数据库的标准方案如果研究透了，已经足够满足公司的日常运营了，这些所谓架构很大一部分是在忽悠老板的；