记录一次mysql的调优心得

  1. 云栖社区>
  2. 博客>
  3. 正文

记录一次mysql的调优心得

猎人笔记 2015-01-24 19:42:28 浏览399
展开阅读全文

前言:这是最近刚发生在公司的一次应用系统的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管理 ) 

........................................................................................................................................................................

网友评论

登录后评论
0/500
评论
猎人笔记
+ 关注