为什么你的MySQL跑得很慢？

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

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

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

比如MySQL5.6能用到48个CORE以上,跑得好的,64个CORE都能用到(48CORE-64CORE之间,官方公布48个CORE,我实际测试能跑到64个CORE).

MySQL?5.6?可以用到48?core+

MySQL?5.1?前最多可以用到4个核?

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

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

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

每个连接一个是一个线程(非thread?pool),每个query只能使用到一个核

另外,在MySQL每个query只能用到一个CPU.

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对内存利用特点

64位操作系统的服务器可利用内存((2^64-1)/1024/1024/1024)G

在高速并发环境,基本是靠内存缓存来减少对磁盘的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对磁盘的利用特点

Binlog,redo?log?,undo?log顺序IO

MySQL的IO类型多种多样.

binlog,redolog,undolog,这些都是顺序IO写.

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

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

Datafile随机IO和顺序IO相结合

（编辑：ASP站长网）