本书一共分为3篇:基础篇、案例篇和工具篇。“基础篇”从理论基础和基本原理层面介绍了MySQL的安装与配置、升级和体系结构,information_schema、sys_schema、performance_schema和mysql_schema,MySQL复制,MySQL事务,SQL语句优化及架构设计基础知识。“案例篇”从硬件和系统、MySQL架构等方面给出了性能优化的十几个案例,包括:性能测试的基本优化思路和最需要关注的性能指标解释、对日常SQL语句执行慢的基本定位、避免x86可用性的一般性方法、节能模式会怎样影响性能、I/O存储作为数据库最重要的依赖是如何影响数据库性能的、主备复制不一致可能有哪些原因、字符集不一致会造成哪些性能问题、在实际场景中锁的争用是怎样的。“工具篇”介绍了在MySQL性能优化过程中需要用到的各种工具,包括:dmidecode、top、dstat等硬件和系统排查工具;FIO、sysbench、HammerDB等压力测试工具;mysqldump、XtraBackup等备份工具;Percona、innotop、Prometheus等监控工具。
通过本书,读者可以掌握MySQL 5.7中的新特性,熟练地使用各种性能测试、排查、监控工具与方法,通过性能基准测试篇的学习,可帮助读者对生产系统的性能、瓶颈了然于心,通过性能基础优化的学习,可以让读者在现有硬件、架构下尽可能地低成本提高数据库的性能。通过架构优化的学习,可以让读者在碰到业务量增长时,能从容地选择如何进行架构升级等。通过大量丰富的实战案例,读者可以熟练掌握数据库自底层硬件到操作系统,再到数据库层的整体性能排查与调优的方法论,在无法通过调优解决问题时如何做架构选型与升级改造(例如:分布式改造、准实时同步改善OLAP场景等)。
李春:原阿里巴巴MySQL DBA团队技术Leader,全程参与阿里数据库架构从Oracle迁移到MySQL的过程,参与分布式中间件Cobar设计。现为沃趣科技联合创始人&首席架构师,负责MySQL、基础软件及部分关键组件的技术选型、风险评估等。
罗小波:沃趣科技高级数据库工程师,主要负责MySQL产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写,熟悉MySQL体系结构,Innodb存储引擎,喜好专研开源技术,多次在公开场合做过线下线上数据库专题分享,发表过多篇与数据库相关的研究文章。
董红禹:沃趣科技MySQL DBA , 为过多家大型企业进行过故障解决、架构设计、性能优化,例如中信证券、浙江农信、陕西农信、邮储银行等。规划并实施了浙江农信互联网核心金融平台。
性能问题
这个世界是由问题组成的,理想的状态和实际状态之间的差异造成了问题。国家领导解决人民生活幸福的大问题,公司的总经理解决盈利的问题,而本书只想解决MySQL数据库性能这么一个“小问题”。
从某种程度来说,MySQL数据库性能优化的问题是一个并行的问题,归根结底是锁和资源争用的问题。举个例子:假设你要开一个餐饮店,你需要取好店名,到工商局领取开业登记注册证书,到卫生防疫站申请卫生许可,到物价局进行物价审核,如果要卖酒,则需要到工商部门办理酒类经营许可证,到税务局办理税务登记,到银行开户,还需要找厨师、找洗碗工、找采购人员、找门面、协调店面转让、进行店面装修、做广告牌,等等。
如果想尽快把餐饮店开起来,就需要同时做更多的事情,就像计算机一样,并行地去做更多的事情。但是当你真正去做这些事情的时候,会发现:
• 总有一两件事情耗费的时间特别长,会最大程度地影响餐饮店什么时候能开起来。比如找到合适的店面或者合适的厨师。
• 有些事情是相互依赖的,一件事情必须依赖于另一件事情的完成。比如工商登记就取决于你要准备好店名,店面装修依赖于门面已经租好了,等等。
• 有些事情特别重要,它决定了这个餐饮店是否能长期经营下去。例如厨师做的菜是否足够好、足够快,运营的成本是否足够低而能产生足够的利润支撑餐饮店继续运营。
其实性能优化要做的就是以下事情:
• 了解基本原理。找到事情的因果关系和依赖关系,让尽量不相关的事情能并行做起来。
• 要事第一。找到当前最重要、最需要优化的地方,投入时间和精力,不断去改进它、优化它。
• 切中要害。找到耗费时间最长的地方,想方设法缩短它的时间。
本书的作者尝试通过上述方法论来找到MySQL性能优化的办法并呈现给读者。
数据库的性能提升
从计算机出现的第一天起,性能作为鞭策者就不断地促进计算机及系统的演进。从最开始的人工输入命令等待计算机执行,到利用批处理任务提升利用率,再到通过多进程和多线程并发来进一步提升效率,性能其实一直是计算机工程师想要努力去解决和改善的重要难题。
上面说的都是对已有系统的性能优化,数据库的性能优化其实可以在做设计之前就开始。
数据库的性能优化首先是计算机系统的优化。数据库程序是运行在计算机系统上的应用程序,需要先优化的就是计算机系统。也就是说,让硬件尽量均衡,操作系统充分发挥硬件的全部性能,而数据库充分利用操作系统和文件系统提供的便利发挥全部性能,而且避免资源的相互竞争。
数据库的性能优化其次是SQL语句的优化。上层应用都通过SQL语句与数据库打交道,一条SQL语句为了获取数据可以有几十甚至上百种执行计划,数据库会通过优化器选择更优的SQL执行计划,但是MySQL在执行计划上远远落后于商业数据库,甚至在一些方面相比PostgreSQL也差很多,那么怎么写出正确的SQL语句,避免MySQL选择错误的执行计划,以及怎样通过增加索引、设置参数让MySQL的执行计划更优,这就是优化SQL语句需要关心的事情。
最后,数据库的性能优化最有效的是架构的优化。对于读多写少的应用程序,可以设计为读写分离,把允许延迟的读请求主动分发到备库;对于秒杀型的业务,可以先在内存型key-value存储系统筛选再发往数据库持久化,避免对数据库的冲击;对于汇总、聚合类的应用,可以采用列式存储引擎或者专门的大数据平台;对于监控类的应用,可以采用时序数据库,等等。
以上三种优化思路贯穿本书,这也是本书名为《千金良方:MySQL性能优化金字塔法则》的缘由。
机械思维和大数据思维
看过吴军博士《智能时代:大数据与智能革命重新定义未来》的人可能会对本书嗤之以鼻,本书的性能优化方法论还是工业革命时代的机械思维,简而言之,就是寻找因果关系,大胆假设,小心求证。“现在都是信息时代了,了解过信息论没有?知道香农第一定律和第二定律吗?解决问题需要用大数据思维!”
笔者有两点理由使用机械思维来介绍数据库性能优化:
(1)大数据时代需要的数据量大、多纬度和完备性,目前对数据库的性能优化和性能诊断,笔者掌握的案例和相关信息远远达不到大数据的要求。我们可以期待亚马逊、阿里云或者腾讯云等厂商或者专业的数据库公司(如Oracle、MariaDB等)来有针对性地做一些大数据数据库性能优化的尝试。
(2)大数据的成本很高。目前我们遇到的大部分性能问题其实用因果关系和假设→推导→再假设→再推导的方法就可以解决,不需要用到大数据、人工智能这样的“大杀器”。
内容介绍
MySQL的火热程度有目共睹,如果需要了解MySQL的安装、启动、配置等基础知识,市面上相关的书籍已是汗牛充栋。本书则尽量深入细致地介绍MySQL的基本原理,以及性能优化的实际案例。
基本原理很枯燥,就像课堂上老师介绍数学定理和公式推导一样,有人可能会质疑,小学都在进行素质教育了,你这本书里怎么还有那么多基本原理的介绍?对于工作了两三年的技术人员来说,在实践上已经有了比较多的积累,解决过很多问题——可能通过sys schema查询事务锁等待解决了系统的并发问题,通过设置ulimit -n 扩大进程文件句柄数解决了MySQL的进程限制问题,通过设计读写分离架构扩展了应用的读性能线性扩展问题。但是作为求知欲强的技术人员,我们急切地希望知其所以然,了解MySQL到底是怎么设计的,以及为什么这样设计,sys schema到底还有哪些可以帮助我们分析解决问题的存储过程,Linux系统的资源限制除了ulimit还有哪些,读写分离架构适应的场景有哪些,什么时候建议用分库分表,等等。如果你也跟我们一样,你应该阅读本书。
本书一共分为3篇:基础篇、案例篇和工具篇。
信息论认为消除一件事情的不确定性就是获取足够多的信息。我们认为任何优化都可以从了解它的基本原理和设计思路开始。“基础篇”从理论基础和基本原理层面介绍了MySQL的安装与配置、升级和体系结构,information_schema、sys_schema、performance_schema和mysql_schema,MySQL复制,MySQL事务,SQL语句优化及架构设计基础知识。希望读者通过对这些内容的学习,能够深入细致地了解MySQL各方面的基础知识。
计算机是一种实验的科学,性能优化是实战的艺术。“案例篇”从硬件和系统、MySQL架构等方面给出了性能优化的十几个案例,包括:性能测试的基本优化思路和最需要关注的性能指标解释、对日常SQL语句执行慢的基本定位、避免x86可用性的一般性方法、节能模式会怎样影响性能、I/O存储作为数据库最重要的依赖是如何影响数据库性能的、主备复制不一致可能有哪些原因、字符集不一致会造成哪些性能问题、在实际场景中锁的争用是怎样的。希望读者通过这些案例,可以深入细致地理解“基础篇”中的各种概念,融会贯通,对MySQL有一个全面的、系统的掌握。
“工欲善其事,必先利其器。”我们日常需要借助一些工具来做性能优化。“工具篇”介绍了在MySQL性能优化过程中需要用到的各种工具,包括:dmidecode、top、dstat等硬件和系统排查工具;FIO、sysbench、HammerDB等压力测试工具;mysqldump、XtraBackup等备份工具;Percona、innotop、Prometheus等监控工具。希望读者可以借助更多自动化的方式去验证和评估性能优化解决方案,提升性能。
读者对象
(1)MySQL初学者。建议按照顺序从本书的“基础篇”开始阅读。“基础篇”介绍了从安装部署、基础配置到性能诊断等日常工作需要了解的内容。在熟悉了MySQL的基本概念和大致原理以后,在阅读“案例篇”时,对问题的定义和解决方案才能理解得更加透彻。最后在阅读“工具篇”时,也可以学习到MySQL DBA日常工作所需要工具的使用方法和应用场景。
(2)专门从事MySQL工作1~3年的开发人员和运维人员。对于有一些MySQL开发和运维经验的人员,建议先跳过“基础篇”,直接从“案例篇”开始阅读。在“案例篇”中了解了具体的问题现象、故障处理的过程和方法以后,联系案例中对应的“基础篇”和“工具篇”知识进行阅读,这样能帮助你把很多知识点串联起来,由点到面形成更为全面的MySQL知识体系。
(3)资深的MySQL DBA。本书可以作为案头书,在解决问题时,如果记不清某些概念或者细节比较模糊,则可以拿来参考。
致谢
首先,感谢我的叔叔李巍,从一个贫家子弟到自己创业成立公司,到成为上市公司CEO,再到成立基金公司,他让我看到一个人的能力可以改变环境,让更多的人发挥自己的价值,也是他的经历激励着我继续努力。
其次,感谢阿里巴巴平台,在实际的工作中,这些之前一起奋斗过和现在正在一起奋斗的战友都给了我极大的帮助,他们是简朝阳、彭立勋、胡中泉、陈良允、陈栋、张瑞、熊中哲、何登成、梅庆、童家旺、李建辉、罗春、胜通、天羽、苏普等(排名不分先后)。
再次,感谢沃趣科技技术中心的负责人魏兴华,因为他的鼓励才有了这本书,感谢产品团队的负责人张文件、MySQL团队的同事刘云和沈刚帮助校稿,感谢市场部的同事杨雄飞、钱怡晨协调出版相关事宜。还要感谢其他在沃趣团队工作中一起成长的同学们,人数太多,这里就不一一提及了。
最后,感谢电子工业出版社的符隆美编辑大力配合我们推动图书的出版事宜。
本书作者
本书由李春、罗小波、董红禹共同编写,其中,李春负责编写第23~33章、第42~44章,罗小波负责编写第1~18章、第40~41章、第45~51章,董红禹负责编写第19~22章、第34~39章。
读者服务
轻松注册成为博文视点社区用户(www.broadview.com.cn),扫码直达本书页面。
• 下载资源:本书提供资源文件,均可在 下载资源 处下载。
• 提交勘误:您对书中内容的修改意见可在 提交勘误 处提交,若被采纳,将获赠博文视点社区积分(在您购买电子书时,积分可用来抵扣相应金额)。
• 交流互动:在页面下方 读者评论 处留下您的疑问或观点,与我们和其他读者一同学习交流。
页面入口:http://www.broadview.com.cn/37520
编者
76页,UPDATE setupconsumers SET ENABLED =’NO’ WHERE NAME =’events waits_current’;语句中的”NO”修改为”YES”
正文第4行,
tcpdump -s 0 -w /tmp/client_3306.pcap —host 10.10.30.161 and port 3306应该修改为
tcpdump -s 0 -w /tmp/client_3306.pcap — host 10.10.30.161 and port 3306
—和host之间应该有一个空格,—表示该字符后面没有参数了,host 后面跟IP地址表示监听发往或者从该IP发出的package。
这里用8个线程对/data2/test1文件做持续时间为60s、队列深度为1、块大小为4k的direct异步顺序读(libaio)压力测试,该测试命名为bw_read。输出结果不按4个job分别展示,而是按照 group 汇总。这样就可以得到在该压力下该文件系统的顺序读带宽
应该修改为
这里用8个线程对/data2/test1文件做持续时间为60s、队列深度为1、块大小为1m的direct异步顺序读(libaio)压力测试,该测试命名为bw_read。输出结果不按8个job分别展示,而是按照 group 汇总。这样就可以得到在该压力下该文件系统的顺序读带宽
这里用8个线程对/data2/test1文件做持续时间为60s、队列深度为1、块大小为16k的direct异步混合随机读写(libaio)压力测试,读写比为7∶3,该测试命名为iops_randrw。输出结果不按4个job分别展示,而是按照 group 汇总。这样就可以得到在该压力下该文件系统的混合随机读写IOPS。
修改成
这里用8个线程对/data2/test1文件做持续时间为60s、队列深度为1、块大小为16k的direct异步混合随机读写(libaio)压力测试,读写比为7∶3,该测试命名为iops_randrw。输出结果不按8个job分别展示,而是按照 group 汇总。这样就可以得到在该压力下该文件系统的混合随机读写IOPS。