技术老铁们,工作累了,我们就一起来放松一下!老张我呢是个金庸迷,在金庸小说中,降龙十八掌无愧巅峰外功,它的威力之大可想而知。而今儿,老张要给大家介绍18招式,来优化我们的 MySQL 数据库,让它跑起来更快,更稳定!
之前老有学生问我,张老师该如何优化我们的 MySQL 数据库呢?这个问题太泛泛了,不是很具体!因为数据库的优化要从多个角度去考虑,通过不同的维度模型去排查问题。老师整理了下思路,大概可以从18个角度,大致四个方向去给大家一些建议。
第一掌----亢龙有悔
要想保证数据库能够高效,稳定地运行在服务器上面,我们首先要保证有充足的内存,只有内存足够大了,我们才能缓存住那些我们经常访问的热数据,一些 update 语句的操作当然也可以在内存中优先完成。但是我们要考虑内存使用黄金分割法则,由于不同业务的存在,对内存的需求当然也就不一样了。
举个列子来说,用户经常访问的热数据,对于内存的分配就要尽可能达到达到数据库内存的 70-80% 左右。众所周知,我们知道 MySQL 数据库内存主要靠 innodb_buffer_pool,redo log buffer,double write buffer,binlog cache 等组成。如果服务器上面只跑着 MySQL 一个应用,那大概 innodb_buffer_pool 可以分配到物理内存的 50-80% 左右。
TIPS:我们要根据实际物理内存的大小,具体是什么业务类型,去考虑数据库内存的分配。
第二掌----飞龙在天
要优化 MySQL 数据库,首先要很了解对手,随着版本的升级,MySQL 用到的 CPU 核数就越多,自从 MySQL 5.6 之后可以使用到 64 个核。MySQL 连接特点的是这样,每个连接对应一个线程,每个 sql/ 查询只能使用到一个 cpu 核心,所以需要越多的 CPU,并且更快的 CPU。这样才能有利于提高数据库性能,提高我们数据库的并发能力!
TIPS:使用多核 CPU。
第三掌----见龙在田
众所周知,IO 对数据库来说,一直都是瓶颈,并且有可能将来一段时间还会是。所以对存储介质的要求就非常高,对于 IO 系统比较高的情况下,建议我们要使用更快的存储设备 SSD 固态硬盘可提高上百倍的数据读写性能或者是 PCIE-SSD 固态硬盘可提高上千倍的数据读写能力。像现在的一些电商网站,在搞店庆或者促销活动的时候,都需要借助此设备,来满足大量用户的影响请求。
TIPS:建议上高转速硬件设备,SSD 或者 PCIE-SSD
第四掌----鸿渐于陆
自从 web2.0 时×××启,基本所有的,我们使用的软件都是基于 linux 平台自主研发的。我们知道,MySQL 数据库也是跑在 linux 操作系统上面的。在官方建议估计最推荐的是 Solaris,但从实际生产中的角度来看 CentOS 和 REHL 都是不错的选择,个人建议推荐使用 CentOS, 如果非要使用 REHL,建议 版本为6以后的,这里就不推荐使用在 windows 下跑 MySQL 数据库了,虽然随着 MySQL 版本提升,对 windows 有了相关的优化,但是对于高并发,高负载的环境来说,依旧不建议使用。
TIPS:推荐使用 CentOS,或者 REHL 操作系统类型
第五掌----潜龙勿用
操作系统层面的优化,我们要考虑个可能大家会比较忽略的问题,首先就是 swappiness 的问题。swappiness 的值大小对如何使用 swap 分区有着密切的联系。有两个极限值,一个为 0,另一个为 100,查看可执行 cat /proc/sys/vm/swappiness。
0 代表:最大限度地使用物理内存,然后才是 swap 分区,这种行为有可能导致系统内存溢出,从而导致mysql被意外kill掉。不建议这样去设置。
100则为:积极地使用使用 swap 分区,并且把内存上面的数据及时搬到 swap 分区里。
TIPS:这里比较建议使用默认 60 就可以。
第六掌----利涉大川
与 swappiness 对应的,另一个操作系统层面的优化,还有一个小细节点就是 IO 调度。这里有 cfq,noop 和 deadline,系统默认使用 cfq,这里老师建议使用 deadline。查看方法:
cat /sys/block/sda/queue/scheduler/
TIPS:deadline 可以调整读写时间,避免写完没有被读取的饿死场景。
第七掌----突如其来
Oracle 11g 之后多了一个 result_cache,来缓存数据结果集。MySQL 里面通过 innodb_buffer_pool 里面有个 query cache 来缓存静态结果集。我们都希望热数据都保存在内存里面,我们读取数据快速便捷,数据库的缓存率也很高!但数据库中的 query cache 里面的数据一但发生更改,此缓存区毫无意义,就会变成鸡肋。而且如果开启 Query Cache,更新与写入都要去检查 query cache 反而增加了写入的开销。
TIPS:建议关闭 query cache
第八掌----震惊百里
对于磁盘阵列,我们再熟悉不过了,但是对于阵列卡的 cache 策略,我们又该如何选择呢。首先对于qps,tps,业务高的系统,一定要配置阵列卡,配 cache 模块,和 BBU 模块(用于提供后备电量)。
cache 策略有两种,一种为:write through(WT);另一种为:write back;
个人强烈建议使用 write back(WB)。WT含义,数据直接写入磁盘,WB含义:数据先写阵列卡的cache,再由cache写入磁盘,这样对于写入的性能有所提高。并且对于加速redo log ,binlog, data file都有好处。
TIPS:强烈建议阵列卡的 cache 策略使用 write back。
第九掌----或跃在渊
前面也涉及到了,尽可能大的给 innodb_buffer_pool 分配空间,在服务器只跑数据库一个应用前提下大概为物理内存 50-80%。
TIPS:建议应用与数据库分开部署在服务器上面,后期好排查问题。
第十掌----双龙取水
MySQL 数据库的一些核心参数,我们要在心里铭记。比如双一的含义,直接影响日志的刷新机制。影响redo log buffer 的刷新机制
innodb_flush_log_at_trx_commit = 1(最安全)
innodb_flush_log_at_trx_commit = 2 (性能一般)
innodb_flush_log_at_trx_commit = 0 (性能最好)。
影响binlog cache的刷新机制~sync_binlog=0,当事务提交之后,MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache 中的信息到磁盘,而让 Filesystem 自行决定什么时候来做同步,或者 cache满了之后才同步到磁盘。sync_binlog=n,当每进行 n 次事务提交之后,MySQL 将进行一次 fsync 之类的磁盘同步指令来将 binlog_cache 中的数据强制写入磁盘。为了确保安全性,我们可以将sync_binlog=1。为了获得最佳性能我们可以将sync_binlog=0。
TIPS:对于不同业务的公司,保障的点不一样,所有我们要考虑好,是业务最重要,还是数据最重要!然后分别去设置不同的参数value
第十一掌----鱼跃于渊
MySQL 数据库区别于其他数据库最主要就是插件式存储引擎,最为著名就是 myisam 还有 innodb。它们都有各自的特点,这里强烈建议使用 innodb 存储引擎表,无论是对于事务的支持,还是在线 DDL 语句快速操作,它都是目前最优秀的存储引擎!MySQL 5.5 之后默认使用的存储引擎都是 innodb
TIPS:生产环境中,如果还有 myisam 这种存储引擎的表,建议全部做 myisam-->innodb 存储引擎的转换!不过 MySQL 5.7之后,系统表也都是 innodb 了!
第十二掌----时乘六龙
文件系统强烈推荐使用 xfs,不要再使用 ext3,ext4 之类的,因为 xfs 这种文件系统也是 B-tree 结构最接近于数据库的树状结构。
第十三掌----密云不雨
生产环境中,经常会出现对大表进行 delete,或者 update 这类的操作。数据碎片随之产生,我们要经常去整理主要业务表的碎片,让查询检索更快。可以通过 pt-ioprofile 监控与磁盘交互最为紧密的表,然后通过 alter table 或者导入导出数据的方法对表进行碎片整理。尽可能回收表空间
第十四掌----损则有孚
利用天兔(lepus)或者 zabbix 做好对数据库的监控。监控事项可以从服务器的状态,内存的使用情况,cpu的负载。数据库中每秒的增删改查信息,架构中的延迟和复制状态信息去作为监控的核心点。
第十五掌----龙战于野
配合开发人员合理地设计表结构,秉着越简单越好的原则,去选择合适字段的数据类型。对于ipv4,时间类型的字段,我们完全可以通过整型int来存取!通过函数转换就可以了!
ip涉及到两个函数:inet_aton和inet_ntoa
时间类型的两个函数:from_unixtime和unix_timestamp
第十六掌----事务隔离级别的选择
mysql数据库中,有四种事务隔离级别。它们分别是Read Uncommitted(RU),Read Committed(RC),Repeatable Read(RR),Serializable(SR)。对于交易类型系统的网站,对于事务要求比较高,我们建议使用RR这种隔离级别。
第十七掌----羝羊触藩
更改文件句柄 ulimit –n 默认1024 太小
进程数限制 ulimit –u 根据不同版本来决定
禁掉NUMA numctl –interleave=all
第十八掌----神龙摆尾
做过数据库的同学们,可以经常会遇到too many connections这样的问题,对于这样的问题,我们一定要做好配置数据库内部并发的情况。innodb_thread_concurrency 这个参数来决定innodb的并发情况。默认的大小是0。在mysql5.7版本中,增加了thread pool,连接复用的存在,可以取默认值就ok。但是5.7之前的版本,就需要考量一下取值了,个人建议mysql5.6版本中设置为36。mysql5.6之前可以8-32。
降龙十八掌已经打完,希望对于数据库爱好者,从事数据库工作中的同学来说有帮助。让我们每天学习一点点,把自己的内功练得越来越深厚,打出属于自己的武功。让我们的数据库飞起来!