经常用mysql,也都是自己设计表结构,写sql,但是由于业务规模小,对sql性能要求不高,所以很少注意到这一块,但是最近DBA出了一个慢sql报表,才发现自己写的都是慢sql,因此通过读书、查资料对这一块做了一些了解,整理一下。
影响数据库性能的相关因素
1. 系统架构对数据库性能的影响
数据库中存放的数据是否真正适合在数据库中存放？一般情况下有三种数据不适合存放在数据库中,二 进制多媒体数据，超大文本数据，流水队列数据(需要频繁的insert,update,delete)。
是否合理的利用了cache?尤其是对于访问频繁但变更少的数据应当有chache缓解数据库压力。
2. 表结构对数据库性能的影响
- 在表结构设计时就应该结合业务考虑到避免昂贵操作和性能优化。
3. query语句对数据库的影响
- 对于同一份数据,当以不同方式去寻找其中某一部分内容的时候,须要读取 的数据量可能会有天壤之别,所消耗的资源自然也是区别甚大。
其中第一点需要在整个系统的架构设计时考虑合适的技术选型和性能优化点, 此处不进行详叙, 下面主要对表结构设计和query语句优化需要注意的点做简单的梳理。
表结构设计优化策略
1. 适度冗余, 减少频繁查询的join操作
join操作本身就比较耗时,而且mysql对于复杂的join操作容易出现不合理的执行计划,因此对于更新不频繁但是查询频繁的其他表中的数据可以适当冗余存储在查询主表中,比如大多数查询博客的时候都同时需要其作者名, 而一片博客的作者名几乎很少会修改, 因此博客表中可以冗余存储作者名, 避免每次都需要和用户表作join操作, 提高博客的查询性能。
2. 大字段垂直拆分
大多数情况下大字段的访问都不是很频繁, 但由于其大, 往往带来较大的IO开销, 因此通过将其拆分出去, 可以在访问其他字段时大大降低IO访问, 从而提高性能。比如博客表, 其中博客内容就属于大字段,而且相对于博客标题,摘要,作者,发布时间,类型等字段来说, 访问频率也相对低许多(只有当用户看到前面这些字段并且对这篇博客产生兴趣的时候才会查看博客内容),因此就可以单独拆分出去。其实不止是大字段,所有访问不频繁的字段都可以和大字段一起拆分出去。
3. 大表基于类型进行分拆
一个表中存储的数据虽然都属于同一类, 但是很多情况下也有细分类型, 有时候不同类型的读写比例,访问频率可能都有很大差别, 因此将这些差别较大的类型单独拆分出一个表, 不仅不同类型的数据查询相互不受拖累,而且也更有利用cache。
4. 选择合适的数据类型
选择更小的数据类型, 可以使查询相同数据需要的IO资源降低,如果是索引字段,也能更好的利用索引。
对于数字的存储,尽可能使用整数存储,可以使数据的处理更为高效。
对于时间类型, 如果不需要存储1970年之前的数据, 尽可能采用TIMESTAMP类型(只能存储1970年以后的时间,但是仅需要4字节,其他类型均需要8字节)。
query语句优化
1. 基本原则
重点优化高并发的查询, 对于高并发的查询每次节省一点资源,对整个系统来说也会带来很大的收益
使用EXPLAIN 和 PROFILING, 使用EXPLAIN可以看到一条sql语句在当前状态的数据库中的执行计划, 而PROFILING则可以看到一条sql语句具体耗费的资源情况,从而找到性能瓶颈。
只取出自己需要的column, 尤其是在需要排序的query中, 取出的column越少传输数据量就越小,从而也就有更好的性能,在mysql4.1之后,排序时会将所需的所有column取出,在排序区排好以后返回给客户端,因此如果将不需要的column也取出,就是对内存的浪费。
永远用小结果集驱动大结果集, mysql的join都是通过嵌套循环来实现的。驱动结果集越大,所需要循环 就越多, 那么被驱动表的访问次数自然也就越多, 而每次访问被驱动表,即使需要的IO很少,循环次数多了, 总量也不可能小, 而且每次循环都不能避免消耗CPU, 所以CPU运算量也会增加。
尽可能在索引中完成排序, 利用索引进行排序操作, 主要是利用了索引的有序性。在通过索引进行检索 的过程中，就已经得到了有序的数据访问顺序, 依次读取结果数据后就不须要进行排序操作,进而避免了此操作。
仅仅使用最有效的查询条件,避免mysql作出不理想的执行计划。
尽可能避免复杂join和子查询, 当并发量比较高的时候, 容易发生锁争用和死锁。
2. 关于索引
主要针对InnoDB引擎的B-Tree索引做一些探究, B-Tree索引通过B+树(一种Balance Tree结构),所有实际需要的数据都存放于Leaf Node, 而索引则存放在Branch Node。对于主键索引而言,其Leaf Node中存储的就是表的实际数据(不仅包括主键,而且包括其他数据), 这个表的数据按照主键有序排列。而普通索引的Leaf Node中则存放的是索引键和主键值, 因此在InnoDB中通过主键访问数据效率是非常高的, 而如果通过 普通索引来访的话, InnoDB首先通过普通索引的相关信息及相应的索引键检索到Leaf Node, 再通过Leaf Node中存放的主键值和主键索引来获取相应的数据行。索引可以节省IO次数, 但是也会增加数据量和修改操作的复杂度, 可以根据一下几个原则判断是否为一个字段创建索引:
较为频繁的作为查询条件的字段应当建索引
唯一性太差的字段不适合单独创建建索引
更新非常频繁字段不适合创建索引
不会出现在where子句中的字段不适合创建索引
join操作内驱表使用的字段应该建索引, join语句会根据内驱表的join字段进行循环查询,因此在改字段上加索引可以有效提高join语句的性能
需要用来做排序(ORDER BY)、分组(GROUP BY)、 去重(DISTINCT)的字段可以考虑建索引,排序操作创建索引的原理在基本原则中已经说明, mysql的分组操作也可以利用索引,而且分组操作默认会进行排序(如果对顺序不关心,可以通过在整个语句后面添加一个以null排序的[ORDER BY null]子句来显式禁止排序提高性能)
