找出瓶颈:

存储容量

Network(IOPS/吞吐量)

DRAM

CPU

IO(IOPS/吞吐量)【oltp:iops

olap:吞吐量

>60% 瓶颈在IO

】

以前DB大多性能在IO层面,现在CPU也可能会成为瓶颈,因是

排序和重复读取过多导致;

方法及误区：

DISK:【

oltp:小容量高转速

olap：大容量低转速

磁盘数量尽可能多

】

Raid Card：

【

Cache只供写使用，Direct读取

oltp Raid10 参考DB

olap Raid5

关注Raid卡重放点带来的Cache失效

预读只对连续读有效，oltp关闭预读

】

CPU：

【

提高CPU运算能力

缩短CPU访问数据路径(缓村?)

】

优化目标:

减少IO次数，

IO最容易瓶颈地方,同时>90%的时间是IO操作所占用,

减少IO次数是SQL优先考虑；

减低CPU计算：

除IO瓶颈之外,SQL优化中就是CPU运算量，order by,

group by,distinct 都是消耗CPU大户

优化方法：

改变SQL执行计划

让他少走弯路，尽量通过各种 "捷径" 来找到我们需要数据，

以达到 "减少IO次数" 和 "减低CPU计算"的目标

解释：

count(column) 和 count(*) 是一样的

count(column)是结果集中有多少个不为空记录的column字段;

count(*) 是表示整个结果集有多少条记录

select a,b from xx 比 select a,b,c from .. 可以让数据库访问

更少的数据量

数据库的存储原理：

关系型DB是按照行(row)的方式"存储"，而数据"存取"操作是以一个固定

大小的IO单元(block 或 page)为单位，一般4KB,8KB ...,每个IO单元存储多行,每行是存储了该行的所有字段。

所以,我们提取一个字段还是多个字段,实际上DB在表中访问数据量其实是一样的；

例外，我们这个查询在index中就可以完成，也就是说只取a,b两个字段，

不需要回表，而c这个字段不在使用index中,需要回表取其数据，在此情况下，二者IO量有较大差异.

order by 一定需要排序操作

index数据实际是有序的，如果我们需要数据和某个index的顺序一致，

而且我们的查询又通过这个index来执行，那么DB一般会省去排序操作，而直接将数据返回，因为DB知道数据已经满足我们的排序需求啦；

基本原则:

尽量少join，

尽量少排序，排序操作会消耗较多CPU资源，所以减少排序可以缓存命中率高等IO能力，对SQL响应时间也有较大影响;

尽量避免select *

多数不会影响IO量,但是我们存在order by 网络传输数据时

select子句中字段多少会再很大程度上影响排序效率

尽量用union all(union)替代 or

union 和 union all差异主要是前者将2个或更多结果集合并后再进行唯一性过滤，会涉及排序，增加大量CPU运算，资源消耗及延迟，所以，

多用union all 而不是union

尽量早过滤

可能多的减少必要IO操作，大大节省IO操作所消耗时间。

摘自网络

ITPub博客

MySQL性能调优"经验"

最新文章