前言：这是最近刚发生在公司的一次应用系统的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、很多人员不管是乙方还是甲方技术都还是半桶水的时候，就大谈数据库架构、应用架构，其实如果真正去观察其实很多数据库的标准方案如果研究透了，已经足够满足公司的日常运营了，这些所谓架构很大一部分是在忽悠老板的；
........................................................................................................................................................................
本文作者：JOHN，某上市公司DBA，业余时间专注于数据库的技术管理，从管理的角度去运用技术。
ORACLE技术博客：ORACLE 猎人笔记 数据库技术群：367875324 （请备注ORACLE管理 ）
........................................................................................................................................................................
