其实这是一个咾问题了：

为什么会觉得数据库比较慢呢

数据库优化要从哪些方面入手？

硬件我们这里主要从CPU内存，磁盘三个方面来说下还有一些洇素比如网卡，机房网络等因为文章篇幅关系就不一一介绍了,以后还有机会可以聊。

首先我们来看下MySQL对CPU的利用特点：

5.1可以利用4个核5.5可鉯利用到24个核，5.6可以利用到64个核 

现在一般的生产环境服务器都是32CORE以上。

所以我这里都推荐大家尽量得去用MySQL5.5或MySQL5.6, 除非你们公司的服务器一直鼡的很老旧的服务器只有4个核，或1个核

因为5.1以前(5.0一样)都是在内部代码里写死了，是基于innobase的存储引擎数据库对硬件的利用率较差。 后媔演进为了InnoDB引擎后好了很多。 

 Oracle里面用并行SQL并行查询，这类功能在MySQL里是不存在的

无执行计划缓存（无SQL执行计划预编译）

其次，MySQL内部没囿SQL预编译因此不存在像Oracle内存结构里的library cache(库缓存)这类结构体。所以MySQL只有硬解析，不存在什么软解析更不存在什么软软解析。

MySQL随着连接数仩升会出现性能下降

这个也是MySQL的一个硬伤但是随着MySQL的版本演进，还是出现了很多解决方法

比如：官方推出的thread pool(线程池)，简称TP就是为了解决并发连接数过高的问题，不过这属于MySQL额外的组件官方的TP是需要额外花钱购买的。

另外国内有个叫楼方鑫的，开发了一个OneSQL的中间件也是解决类似问题的。 

有Result缓存但比较鸡肋

MySQL里也有类似Oracle里的结果缓存，叫Query Cache但属于比较鸡肋的功能，很少使用

因为大部分实际的生产環境都是OLTP系统，存在频繁的更新修改操作这个Query Cache用在数据频繁更新修改的环境里，会使MySQL的性能严重下降因此，一般很少使用

现在用MySQL，基本都是用InnoDB存储引擎以前的MyISAM这些引擎也用得很少了。(什么是存储引擎这个不知道的话，你可以gg了)

 InnoDB引擎是完全没有必要去开启这个Query Cache的洇为本身就是一个事务型的存储引擎，用InnoDB就是用它的事务处理能力肯定会发生频繁的数据更新和修改嘛。

再次来看下MySQL对内存利用特点

在高速并发环境基本是靠内存缓存来减少对磁盘的IO冲击

 通常内存按实际数据的15%-20%规划，如果特别热的数据需要考虑更大的比例来缓存数据

這15%-20%的数据我们通常又叫做热数据。(这也是通常的一个经验值)

比如你评估出你这台MySQL数据总量大概在500G左右那MySQL要给到的内存可能就是75G(500*0.15)，那你可能需要一台128G左右内存的服务器

另外有些业务还会存在特别热、大量热的数据(大大超出15%-20%这个区间，也是有可能的)比如：QQ农场。

相信大家嘟玩过以前那种偷菜的游戏QQ农场，开心农场之类的(还有订票的12306网站)。

这类业务在我们业界里面都是属于关注度很高的这类业务的特點，数据热的时候基本100%都是热数据，比如：QQ农场大家玩的时候每天都上来玩的，每隔一会儿就上来偷把菜,很多人半夜起来上厕所起来嘟要偷一把菜

所以这类业务的MySQL数据库，内存配备还得加高 15-20%还不够。

总结：一般的业务15%-20%来规划热数据比如：用户中心，订单之类的常見业务另外一些特殊点的业务，具体情况具体分析

可以根据Query响应时间来做指导分配

我们在做这种大型在线架构-大型数据库规划设计的時候，

SQL查询的响应时间也是一个非常重要的指标

在这种大型系统里面，要承载数百万甚至千万级别用户同时在线进行业务SQL查询(query)的响应時间是必须去严格把控，必须把你这套系统的Query响应时间控制在多少时间以内

比如我们的核心库，我就要求Query的响应时间(平均响应)在30ms以下超过30ms，我们就认为这个数据库可能达到承载极限需要对这个数据库进行扩容了。

另外要对这个Query响应时间进行长期的指标监控。

这个是核心库如果另外一些不太重要的辅助库，比如放日志的库或者说一些性能要求本身不是太高的库，我们可以放宽点这个Query响应时间放寬到1秒或2秒内。

根据业务的重要等级程度来定这个Query响应时间的阀值

这是一个很重要的指导思想，根据Query响应时间来规划你的性能容量

容量分两种：性能容量和空间容量。 空间容量很简单就是放多少SIZE数据，几个T

性能容量是更重要的，决定能否接住你的业务压力和承载

夶家要记住：你如果要抗的业务是百万级别的活跃用户，不是几百个用户的话性能才是王道，性能上满足业务的需求才是最重要的

你功能再牛B，产品再好性能抗不了，其他都是扯淡几百W人可能在几秒钟内就把你的整个系统和项目都搞挂掉，然后你们公司就抓瞎了

苦心经营的用户也会大量流失，损失就惨重了

性能是基础。性能能抗住整个架构才有意义。性能抗不住后面去考虑什么高可用，这些都没用

MySQL对磁盘的利用特点

MySQL的IO类型多种多样。

这一类东西没太多必要放到SSD上顺序写在传统机械盘上也是很快的，放到SSD上有点暴殄天物而且SSD存在写损耗和写寿命的问题，没必要放到SSD上放到传统的SAS盘上就够用了。没必要放SSD

 SSD用来放datafile。因为datafile上发生的IO大部分是随机IOSSD跑随机IO昰非常有优势的。SSD固态盘+传统盘SAS盘一起混合存储另外，备份盘也不要用SSD

顺序IO永远是更快的。在数据库设计里决定你是不是牛B的DBA或牛B嘚架构师，就是看你能否把一个业务尽可能设计为顺序IO同时减少随机IO。举个例子：一个好友关系的业务设计的时候希望一个query以顺序IO把恏友关系就拿出来，那么怎么设计呢

利用这个特性，可以让用户的好友数据尽可能的聚集在一个page里或多个相邻的page里那读的时候一个顺序读IO就能搞定了，性能大大提高

好友关系表结构如下(前提表是InnoDB引擎)：

上面这样的两个字段做一个主键，InnoDB的主键就是聚集索引那读取这兩个字段肯定顺序IO就能搞定。

以前有什么数据库设计的书上总说到，每个表上必须添加一个自增的主键的规范其实规范死的，应对是活的我上面举例的好友关系 就没有用自增的主键，而是具有业务属性读取又频繁的两个业务字段作主键反而性能更好。

因此大家学習，不要去死记这些书上的什么规范和章程而是应该真正学懂一个东西的原理，比如学好InnoDB的内部原理然后在实际工作中，有原理的支撐用原理去举一反三。

InnoDB的原理是很大的一块知识需要日积月累的学习。大家可以多留意我的公众号陆续会有InnoDB的一些文章推出来。

OLTP业務更多的需要随机IO

可以利用内存做缓存从而减少随机IO

OLAP业务更多需要顺序IO

对OLAP系统来说，更大的page对性能的提升会有所帮助，因为OLAP系统都是仳较大的查询扫描的数据很多。

2第二点：数据库设计不好

比如用了很多的数据库特性像Trigger, 分区，非常多的存储过程、函数等等

我们经瑺说什么，小而美意思就是简单才是最好的。你把数据库的所有功能都用上了数据库的性能自然就会被拖慢，可能碰到的BUG底层故障嘚几率也就增加了。

所以大家要明白一个好的数据库项目设计，是小而美精而简的。另外数据库也只是整体项目的一部分，像Trigger存儲过程这些能实现的，在整体项目里面肯定也可以用应用程序代码来完成

所以，我们用MySQL就是用它厉害的地方，比如：表、索引、事务這些而不是要它所有的功能都得用上。

另外有一点在MySQL5.6之前，生产环境的主库里面是不允许使用子查询的

MySQL5.6之前子查询的性能特别差。(語法上是支持的但SQL性能非常差)。

比如大家现在如果是用Oracle想把Oracle迁移到MySQL上的话，建议大家用MySQL5.6版本MySQL5.6对子查询的支持和性能上都做了较大的妀善。

MySQL5.6跑子查询的性能会大大提高

这个估计当过DBA的同学应该都是有体会的，中小型的公司程序员水平参差不齐。

特别是碰到很多刚入荇的程序员(刚毕业的)更有可能，这些刚入行的程序员手里还接了一些进度非常赶的需求 那这种环境下开发出来的程序，想不烂都很难叻

当然，这也不怪我们的程序员不能怪罪他们。

造成我上述现象的原因主要还是国内的开发环境，也没办法开发需求迫切(产品天忝催活)，程序员忙于赶工(长期加班)只能忙与实现业务程序，根本没时间去优化程序

当然，这种环境下对于我们DBA来说就是机会了。程序员写出来的烂SQL复杂SQL，造成系统缓慢甚至崩溃然后我们DBA出马，对这些烂SQL慢SQL进行优化改造后，系统恢复正常并日趋稳定。 这也是很囿成就并且也会受到同事和领导尊重的一件事。

同时DBA们也可以加强对程序员的培训，加强他们快速写出好SQL的能力让他们花较少的时間，也能写出性能比较好更得顺畅的SQL语句。 这样也可以给DBA减轻负担。

我本人就比较喜欢跟程序员讲培训一来大家交流技术，都有收獲二来搞好关系，工作上有什么事以后需要协商的也好聊这比请他们吃饭强。

我们针对程序写的太烂主要有下面几个解决方向：

要讓应用使用数据库连接池，特别是像基于JAVA开发的大型高并发应用里一定要使用连接池。

使用连接池的好处：就是可以限制应用的连接数另外，不用再额外地去创建每个连接MySQL创建连接的开销也是较大的，因为创建一个新连接相当于MySQL创建了一个thread

刚才我也提到，MySQL随着连接數上升会出现性能下降

有写过程序代码的同学，应该也知道在我们一般的PC笔记本上(一般4CORE)，你创建400个thread每个thread就干1+1+1+1+..简单活，再sleep下你看看伱的PC电脑卡还是不卡。你会发现你PC电脑的CPU都快跑满了你要敢创建600个thread，那你的机器就快等着重启吧这就是因为thread的开销，把CPU已经占满了

這个刚才也说了，程序员写的SQL一般都问题多多，他们毕竟太忙了不会去考虑这个SQL的性能和运行情况。在一些情况下程序员拼接的SQL，矗接可以把整个系统干跨掉

我举个简单例子：我们一个应用对数据库创建了10个连接(最大连接数=10)，这10个连接 每个连接都同时跑相同的一条複杂SQL执行这个复杂SQL至少要10分钟，那这10个连接 在10分钟以内都只能执行这个复杂 SQL其他后面的SQL全得堵着。 

造成10分钟大部分应用不可用了对吧。而且有可能引起雪崩造成系统崩溃。

复杂SQL的优化也是DBA很重要的一个活，需要通过监控的手段找出这些复杂SQL、慢SQL、烂SQL然后给出优囮建议到程序员(DBA要进行性能对比测试)，让程序员改造下代码跑得慢才能跑得远让系统真正畅快并行地跑起来，像不堵车的高速公路一样

那有人会问了，我们公司的程序员就是牛B打死不改SQL代码，弄死了也不去优化无法沟通。那我们该怎么办呢

我们还是有办法的，我們还可以构建一个专用的从库(Slave库)来处理你换个库查询，总可以了吧

比如举我们公司的例子，我们的后台出报表的系统就是连的从库查询，不给连主库

以你要想你的系统能支撑百万级别的用户在线，那还得加入SQL审核系统(SQL Review)杜绝无效逻辑的SQL，和这类全表扫描的SQL

SQL经过DBA审核通过后，跑得慢才能跑得远发布上线

另外，这种大的update SQL应该分批更新把大的SQL任务拆成小的任务来跑。在MySQL里面来说这是要特别注意的。

 为什么要分批更新呢

 原因1. 上面说的，MySQL的一个query只能用到一个CORESQL事务太大，复杂度太高需要很久跑得慢才能跑得远运行出来容易造成拥堵。

 原因2. 线上环境MySQL一般都是Master/Slave架构，如果Master发生100W行的大更新事务很可能造成SLAVE卡在那里，因为SLAVE是单线程结构造成同步延迟。

 MySQL写SQL干成小事務SQL，快速执行快速提交。让每个query完成得更快让连接更快地释放出来。

最后回到我们的标题，为什么你会觉得MySQL跑得很慢相信你应该哆少有了点答案。

作者介绍 黄稚禹

常用网名：彪彪现任新浪爱彩票DBA总监，主要工作包括Oracle、MySQL运维以及GreenPlum数据仓库的建设

Oracle OCM，知名线上培训机構老方块培训的合作伙伴以及资深讲师

擅长大型项目的关系型数据库运维和管理，颤长互联网维度数据分析和数据挖掘目前的主要精仂在MySQL相关工作上。

　　【财新网·Enjoy】“纯粹”的走路(完全不跑步)可使你的身体作出微小嘚调整从而对双脚、膝盖和臀部更有利。轻快的长距离散步有助于提高耐力而将散步作为交叉训练，则使跑步所要用到的肌肉得到充汾的休息这有助于减少或消除跑步引起的疼痛。
　　以下是如何(以及何时)将散步加入你的日常训练当中使你成为更健壮跑者的建议。
　　注意跑姿 多数跑者感觉直立的姿势是最自然、最舒服的花费短短的几个步骤，就可以避免步伐过大从而避免步伐过大引起的腿部、双脚和臀部的疼痛。脚不要抬得过高步子要轻。
　　跑步日的散步 当你用散步来代替跑步时那么将跑步时间乘以2，作为散步的时间举例来说，如果你要跑30分钟那么就走60分钟。你不必一次就完成全部训练过程可以将其分为两部分，比如上午散步一次然后晚上再來一次。
　　将散步融入交叉训练中 在不跑步的日子里散步是燃烧脂肪增加血流量从而促进恢复的一种有效方式。它也是打破日常训练避免伤病，并且与(或许还未开始跑步的)家人和朋友团聚的不错方式在进行交叉训练的日子里，如果时间允许的话可以连续走30至60分钟戓者一天之内做五到十分钟的分段练习。步子要快但是可以进行谈话
　　改换地形 同跑步一样，你散步的路线越多样你所能收到的训練效果越好。如果天气允许可以散步时爬几座小山(或者爬几次同一座山)，或者在体育场、校园或公园的台阶上做几次重复练习如果天氣太冷或者路面太滑的时候，楼梯也是锻炼的不错场所一天爬几段楼梯(如果可能的话，一天进行几次)可以锻炼腿部力量。■

　　（本攵来自跑者世界）