MySQL通用优化技巧 | Ucloud运维在线微信群分享

MySQL通用优化技巧 | Ucloud运维在线微信群分享

2015-09-17  MySQL中文网

本文根据DevOps华南运维圈@UCloud微信群「大话运维」的嘉宾分享整理而成。「大话运维」将邀请业界运维前线技术专家做为分享嘉宾，分享技术趋势和技术实战，为运维朋友提供各类踩坑、躲坑、绕坑新技能。

嘉宾介绍

叶金荣
Oracle MySQL ACE，国内最先的MySQL推广者。2006年创办国内首个MySQL专业技术网站 MySQL 中文网。资深MySQL专家，10余年MySQL经验，擅长MysQL性能优化、架构设计、故障排查。

内容提纲

1. MySQL的特色；

2. 硬件、系统优化；

3. MySQL 配置优化；

4. SCHEMA设计优化；

5. SQL 优化；

6. 其余优化。

MySQL 的特色

首先，须要明确的是。想要作好MySQL优化，须要先了解MySQL都有哪些特色：

简言之，MySQL通常用于互联网业务的数据持久化存储，而且用于保证数据的一致性、可靠性，而不是用于：

• 复杂查询；

• 复杂运算；

• 大二进制存储。

等奇葩用途。

CPU的利用特色

看看MySQL不一样版本对CPU多核的支持、利用状况：

建议：

• 采用最新MySQL版本，以提高其CPU利用率；

• 每一个SQL足够简单，不要太过复杂；

• 每一个链接足够快速完成，不要“恋战”。

内存利用特色

内存利用、管理方面有什么特色呢？

建议：

• 关闭query cache；

• 采用InnoDB；

• 采用Percona\MariaDB分支版本；

• 简单KV数据用NOSQL存储，不使用MySQL。

磁盘的利用特色

最后看下磁盘I/O方面的特色：

建议：

• 使用多盘提高总体I/O性能；

• 多使用高速I/O设备；

• 尽可能加大内存，缓解I/O负载。

MySQL 优化

了解完MySQL各方面的特色后，咱们能够开始进行优化工做了。

在开始以前，咱们须要先明确几点：

1. 为什么而优化？领导指派\用户投诉\监控预警\没事找事？当前跑得好好的话，就不必折腾神马优化没事找抽，即使想练手，也要悠着点，防止误操做；

2. 优化的目标是什么，说白了，就是要解决什么瓶颈，切忌在过程当中偏离初心；

3. 计算投入产出比，好比为了让性能提高1%而投入1人月，基本上是很是不划算了，还不如去干点别的；

4. 优化前作好现场信息采集，优化后再次采集作对比，确认优化成果（用来邀功啊，让老板看到你的成绩，年末加加薪什么的，最起码也能锻炼总结概括文档能力吧）。

一般，咱们进行MySQL优化工做的套路是这样的：

确认需求，先明确当前的运行状态，是否真的须要进行优化，别没事找事；

常见瓶颈：

• 绝大多数瓶颈在于I/O子系统；

• 若CPU很高，90%以上是由于索引不当；

• 发生swap时，可能由于内存分配过小或过大；

• iowait过高时，想办法从索引角度入手优化，以及提升I/O设备性能，增长内存，减小排序，减小SELECT一次性读取数据量。

经常使用优化策略

1. 瞬间并发很高，采用thread pool；

2. 频繁order by\group by，索引入手；

3. 适当调整内存，不要太大或过小。通常ibp设置为50% ~ 70%为宜；

4. iowait高，加内存，提升iops，减小数据读写；

制定方案时，重点解决发生频率高的问题（量变动容易引发质变）；回顾反馈，整理文档，回顾总结，从零散资料中总结出规律，预防风险再次出现。

通常采用下面几个瓶颈分析工具：

绝大多数状况下，有经验的工程师靠sysstat工具集中的就足够了，不少问题一看现象大概就能知道瓶颈何在。

在MySQL层面，有哪些确认瓶颈的手段呢？

硬件、系统优化

咱们继续MySQL优化之旅。先来看看从硬件以及OS层面，都有哪些能够优化的。首先主要是BIOS中关于CPU和内存的参数调整，其次是RAID方面的优化。

再来看看几个参考配置图：

一、CPU选择最大性能模式，避免节能模式致使性能不足

二、关闭NUMA，下降swap几率

三、采用RAID-10，而且选择FORCE WB

在OS层面，能够有几个优化手段：

• 调整IO Scheduler

• 使用XFS

• 调整其余内核选项备

备注：

1. vm.swappiness，下降发生swap的概率

2. vm.dirty_background_ratio & vm.dirty_ratio，避免瞬间大量I/O请求致使系统卡死

从这个压测结果能够看到noop/deadline有明显优点

这个io scheduler还能够在线修改的哦，还等神马？

echo deadline > /sys/block/sdc/queue/scheduler

在用PCIe SSD设备作测试时，XFS的IOPS能跑到ext4的4倍，表现很是好。

还有什么理由不用XFS呢？

xfs挂载参数：

/dev/sdc1 /data xfs defaults,noatime,nodiratime,nobarrier 0 0

格式化参数不用特别指定，默认的便可。

MySQL配置优化

前面讲到，给MySQL分配的内存不要太大或过小，那么多少合适呢。

首先，要搞清楚MySQL的内存都由哪些部分组成：

1. global buffers和oracle的SGA一个意思，就是全局一次分配，多个线程间共享。

2. thread buffers和oracle的PGA一个意思，每一个线程单独分配，线程间不能相互共享，所以不要分配过大，避免内存不够使用，发生OOM。

原则： 对这些选项调整时，不要照猫画虎随便调整，要先作到内心有数，了解其具体做用才动手。

看看innodb_flush_log_at_trx_commit分别为0、一、2的性能对好比：

若是再启用binlog后的对比：

最后，再加上sync_binlog选项不一样设置的对比：

备注： 这3个测试结果图均来自Percona。

结论&建议：

1. 想要保证数据安全，就设置 trx_commit =1 & sync_binlog = 1

2. 在slave上或非关键场景，能够都改为0

SCHEMA设计优化

接下来看看MySQL的模式（SCHEMA）设计优化要点：

要点：

1. 默认地，使用InnoDB引擎，别上MyISAM给本身找事；

2. InnoDB必需要有自增（或相似自增）属性的主键；

3. 不使用或少使用TEXT/BLOB列；

4. NOT NULL主要是为了优化索引效率；

5. 若无特殊需求，都可使用latin1字符集，不然用utf8\utf8mb4等大字符集保证通用性。

其余要点：

SQL优化

SQL优化层面有几个要点：

以及 COUNT(*)、大分页 的优化要点：

接下来，咱们来看看EXPLAIN的结果中，有哪些关键信息要注意的。首先看下EXPLAIN结果的type列，均可以给咱们什么信息：

再看看Extra列有哪些状态要引发重视：

以及

MySQL的慢日志可用下面的工具来进行解析和管理：

pt-query-digest + Box Anemometer的案例，能够对slow log进行便捷管理。

关于JOIN优化有下面的几个关键点：

接下来看看哪些状况下，没法有效使用索引的：

再看看几个杀手级SQL的案例及其优化建议：

在平时，咱们登入MySQL服务器后，若是以为有问题，能够重点关注下面的一些线程状态：

其余优化

关于DBA的利器，经常使用percona-toolkit工具简介：

附：关于MariaDB及Percona分支版本的简介

Q&A

Q1:多实例，进程会不会抢占？每一个事例都是单独起的。

A：除了OS层面的资源会相互影响外，其余的不会。好比某个实例消耗特别多cpu资源的话，那么其余实例也会跟着受影响，这是必然的，除非用虚拟化等方式作隔离。

Q2:SSD建议单盘仍是Raid？

A：若是不担忧丢数据，单盘呗。若是怕丢的话，那显然不能单盘了。随机io很高的话，raid5就不合适了。不过除非采用ssd，用raid5也不怕了。事实上，raid卡反而会影响（下降）ssd性能的发挥，但为了数据可靠性，没办法，还好影响不算特别大。

Q3: 能介绍一下哪些业务场景适合哪一种RAID吗？

A：一、高随机IO，用Raid10；二、须要大容量，用Raid5。基本就这两种方案，事实上，由于SSD的IOPS性能已经很不错了，不少企业会选择直接用3块盘构建Raid5。毋庸置疑，上了PCIE SSD，能够避免不少问题，或者DBA能够少干不少活，至少能够缓解。

Q4: nnodb_buffer_pool_instances应该如何设置？

A：ibp的instance通常不超过8为宜，超过8的话，可能有副作用，不过多个instance的前提是，平均到每一个instance的ibp不能小于2G，不然也没啥意义。

Q5: No text,or in compressed是指若是使用text的话，建议压缩吗？在压缩数据方面，叶老师有什么经验吗。

A：对的，建议不要在InnoDB中存储大量文本。须要的话，事先压缩好再存进去。不须要检索的文本，能够通通压缩后存进去，不是用InnoDB的压缩格式哦，是事先外部压缩后存储，文本内容在存储进去前先压缩好，不是用InnoDB的compressed这种row format，那会被坑惨的，性能损失9层，只有一半压缩比，还不如用TokuDB算了。

Q6:MariaDB和MySQL的优缺点，以及大神怎么看Maria有否取代MySQL的趋势？

A：想要取代还早呢，没那么容易，并且也不必取代，做为补充就ok。除非哪天MySQL官方版本闭源了，或者支持不好。

Q7:新的业务系统，是建议继续用MySQL5.5或以上，仍是用mariaDB？

A：建议优先Percona 5.6，其次是MySQL 5.6，最末才是MariaDB。

Q8:大家的数据库备份是用Percona的工具进行吗？每周一全备，天天一增量？用这些工具有份，会不会出现恢复不了的状况？这个有没有办法验证备份是否“正常” ？

A：工具则以xtrabackup为主，mysqldump为辅，数量不是巨大的话，天天一全备，大多有slave作热备，因此就没按期增备了。Mydumper也有些不太爽的，也比较小众就是，备份文件必定要作恢复性测试，千万别只备份不恢复测试，关键时刻会死人的。

Q9:恢复性测试怎么作 有流程方案指导一下吗？

A：简单的：数据恢复，简单查询验证数量，关键数据什么的；复杂的：搭测试环境呗。

Q10:有没有什么效率较高的验证备份有效性的工具或者方法？仍是只好把库恢复出来核对？

A：mysqldump或mydumper备份的文件，能够用grep简单快速验证；xtrabackup的话，只能看文件大小，或者作全量恢复了。