设为首页 收藏本站
查看: 526|回复: 0

[经验分享] MySQL优化核心理论与实践

[复制链接]

尚未签到

发表于 2018-9-27 07:58:41 | 显示全部楼层 |阅读模式
  背景描述:朋友单位OA系统前不久完成升级大改造,后端用的MySQL存储数据,上线跑了个把月,抱怨电话开始接二连三打来,不是这里打不开,就是那里无响应,有人比喻升级后变成老爷车,越来越慢,问题迫在眉睫,必须马上想对策呀。由于部署采用了规范文档,上线前也做了各种测试,于是乎,在线排查,未果,翻出实施文档,逐条阅读,未果,于是想起曾经一个业务系统,也碰到类似情况,后来通过各种优化得以缓解,遂有下文,《MySQL优化核心理论与实践》。
  说明:本文理论部分来源叶老师的博文,实践部分来源工作积累和众多热爱MySQL技术分享的网友,整理初衷是为了更加深入地理解MySQL优化,掌握更多MySQL优化方面的技术,提升自己,回馈热爱技术分享的所有网友。

硬件层的优化
  新采购的服务器默认跑在节能模式下,在并发访问量很大的业务场景,会导致数据库性能跟不上,造成大量延迟,最终将拖垮业务系统。与此同时,磁盘选择与阵列卡设置不当也会使数据库性能成为整个业务系统的瓶颈。

目标一:全面关闭节能模式,让MySQL跑在高性能模式下
  1.关闭CPU节能模式
  

找到OPI Link Speed Select选项,选择Max Performance  

  2.关闭内存节能模式
  

找到Memory Speed选项,选择Max Performance  
找到Power C-States选项,选择Disable
  
找到C1 Enhanced Mode选项,选择Disable
  

目标二:关闭NUMA,让CPU能始终高效地使用内存
  关闭NUMA
  

找到Socket Interleave选项,选择Non-NUMA  

目标三:全面提升IOPS性能,让磁盘I/O不再拖后退
  1.资金充足时,采购SSD甚至PCIe-SSD
  

SSD和PCIe-SSD带来的不只是惊喜,更有踏实,从此磁盘I/O不再是恶魔  

  2.机械盘搭配阵列卡,Cache策略,BBU电池,RAID-10,15KRPM
  

阵列卡从容面对多块机械盘,BBU电池保障高性能模式下的Cache策略不丢数据  
Cache策略选择Write Back甚至Always Write Back
  
阵列预读的Read Policy选项,选择Normal
  
使用RAID-10,性能高于RAID-5
  
使用15KRPM高速磁盘,性能高于7.2KRPM磁盘
  

  备注:服务器硬件设置的参数来源于IBM X3650M3

系统层的优化
  操作系统方面也存在多处值得优化的地方,同样能明显提升IOPS性能。另外,SWAP要少用,不但不能救命,反而会让业务系统处于崩溃边缘。

目标一:全面提升IOPS性能,让数据库不再背锅
  1.配置合理的I/O调度器
  

机械盘配deadline,执行命令echo deadline >/sys/block/sda/queue/scheduler  
固态盘配noop,执行命令echo noop >/sys/block/sda/queue/scheduler
  
注意sda是数据文件所在分区
  

  2.文件系统尽量使用XFS,假如还在使用ext4,希望只是过度阶段
  3.mount参数增加noatime,nodiratime,nobarrier
  

vi /etc/fstab  
/dev/sda1 /data xfs defaults,noatime,nodiratime,nobarrier 0 0
  
/dev/sda2 / xfs defaults,noatime,nodiratime,nobarrier 0 0
  
/dev/sda3 swap swap defaults,noatime,nodiratime,nobarrier 0 0
  
mount -o remount /data
  
mount
  

目标二:减少SWAP使用倾向甚至禁掉,稳定磁盘I/O和网络减少等待时间,让MySQL表现更加稳定
  1.vm.swappiness设为5甚至0,假如不关心发生OOM
  

echo 'vm.swappiness = 5' >>/etc/sysctl.conf  
/sbin/sysctl -p
  

  2.vm.dirty_background_ratio设为5,vm.dirty_ratio设为10,让脏页持续刷入磁盘,避免磁盘I/O瞬间写产生TIME_WAIT
  

echo 'vm.dirty_background_ration = 5' >>/etc/sysctl.conf  
echo 'vm.dirty_ratio = 10' >>/etc/sysctl.conf
  
/sbin/sysctl -p
  

  3.net.ipv4.tcp_tw_recycle和net.ipv4.tcp_tw_reuse设为双1,减少网络等待时间,提高效率
  

echo 'net.ipv4.tcp_tw_recycle = 1' >>/etc/sysctl.conf  
echo 'net.ipv4.tcp_tw_reuse = 1' >>/etc/sysctl.conf
  
/sbin/sysctl -p
  

MySQL层的优化
  选对MySQL版本尤为重要,找到适合业务系统的版本,才能发挥出更大性能。运行参数亦是如此,需要反复斟酌与调校。规范schema设计与sql编写,还有规范上线后的运维管理流程,同样也会带不小的收益。

目标一:选对版本,让MySQL起跑底气十足
  1.优先推荐Oracle MySQL,越来越多的新上系统在拥抱官方5.7.x版本
  2.其次推荐Percona分支版本,在这里能享受免费的thread pool和audit plugin
  3.最后是MariaDB分支版本,除了线程池和审计插件,在这里能享受免费的黑科技

目标二:调校合适的参数,让MySQL的性能更加稳定
  1.如果选择使用Percona或MariaDB分支版本,强烈推荐开启thread pool
  2.设置default-storage-engine=innodb,innodb可以满足99%以上的业务场景
  3.设置合适的innodb_buffer_pool_size大小,单实例多数是innodb表,建议设置物理内存的50%-70%
  4.设置合适的innodb_flush_log_at_trx_commit和sync_binlog值
  

设置双1,不丢数据,性能较低  
设置2和10,丢失一点数据,性能一般
  
设置双0,数据不×××全,性能最高
  

  5.设置innodb_file_per_table = 1,使用独立表空间
  6.设置innodb_data_file_path = ibdata1:1G:autoextend,在高并发事务时获得良好性能
  7.设置innodb_log_file_size=256M,innodb_log_files_in_group=2
  8.设置long_query_time = 0.05,记录超过50毫秒的慢SQL
  9.适当调大max_connection,建议设置max_connection_error为10万以上,设置open_files_limit、innodb_open_files、table_open_cache、table_definition_cache约10倍于max_connection
  10.不宜设置过大的参数tmp_table_size、max_heap_table_size、sort_buffer_size、join_buffer_size、read_buffer_size、read_rnd_buffer_size
  11.设置key_buffer_size = 32M,关闭query cache功能
  

关闭QC需要在启动MySQL前配置  
query_cache_type = 0
  
query_cache_size = 0
  

目标三:Schema设计和SQL编写根据参考规范设定,有助于提高MySQL效率
  1.所有innodb表都设计一个无业务用途的自增列做主键
  2.字段类型在满足够用时,尽量选长度小的;字段属性尽量都加上NOT NULL约束
  3.尽量不用TEXT和BLOB字段类型,一定需要时拆分至子表
  4.查询时,尽量填写需要的列,不要查询所有列,避免严重随机读问题
  5.一般varchar(n)列建索引是,取前50%长度即可
  6.子查询处理时性能低,建议改使用JOIN改写SQL
  7.多表连接查询时,关键字类型尽量一致,且都要有索引
  8.多表连接查询时,把过滤后的结果集小的表作为驱动表
  

优势:不需要的数据不会出现,SQL查询范围小,执行效率高  

  9.多表连接查询并且有排序时,排序字段必须是驱动表里的,否则排序列不走索引
  10.多用复合索引,少用多个独立索引,尤其是基数太小的列则不建议创建索引
  11.使用分页功能的SQL时,选把关键字与主键做符合索引,再来执行,效率会高很多

目标四:管理维护的优化,让运维更高效
  1.online DDL代价太高,机器性能足够时,建议单表物理不超过10G,单表行数不超过1亿,行平均长度不超过8KB
  2.不出现OOM KILL和大量使用SWAP,不必担心MySQL进程占用过多内存
  3.单实例运行中硬件资源还是比较紧张时,不要跑多实例
  4.定期用pt-duplicate-key-checker检查和删除重复索引,定期用pt-index-usage检查和删除不太用的索引
  5.定期采集slow query log,用pt-query-digest工具进行分析,再结合Anemometer等系统进行slow query管理,以便于分析和优化
  6.可以使用pt-kill杀掉超长时间的SQL请求,Percona版本中有个选项 innodb_kill_idle_transaction也能实现该功能
  7.可以使用pt-online-schema-change来完成大表的ONLINE DDL需求
  8.定期使用pt-table-checksum、pt-table-sync来检查并修复mysql主从复制的数据差异

  核心纲领:在上线之前,变更任何一个参数,都要做压力测试,避免漏网之鱼导致MySQL出现各种CRASH。
  写在结尾:计划后期再对每个细节进行理论分析和压力测试,首次整理写作,可能有不完善之处,欢迎留言和交流。
  强烈推荐两位实力派老师:叶金荣 和 吴炳锡
  原文链接:
  比较全面的MySQL优化参考(上篇)
  比较全面的MySQL优化参考(下篇)

  发表时间:2018年3月8日17时



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-602535-1-1.html 上篇帖子: 实现MySQL半同步架构 下篇帖子: mysql-atlas安装及使用教程
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表