高性能MySQL

出版社:电子工业出版社
出版日期:2013-5-1
ISBN:9787121198854
作者:施瓦茨 (Baron Schwartz),扎伊采夫 (Peter Zaitsev),特卡琴科 (Vadim Tkachenko)
页数:764页

章节摘录

版权页:   插图:   第一个趋势,采用了InnoDB plugin的版本,在高并发的时候性能明显更好,可以说InnoDB plugin的扩展性更好。这是可以预期的结果,旧的版本在高并发时确实存在问题。第二个趋势,新的版本在单线程的时候性能比旧版本更差。一开始可能无法理解为什么会这样,仔细想想就能明白,这是一个非常简单的只读测试。新版本的SQL语法更复杂,针对复杂查询增加了很多特性和改进,这对于简单查询可能带来了更多的开销。旧版本的代码简单,对于简单的查询反而会更有利。原计划做一个更复杂的不同并发条件下的读写混合场景的测试(类似TPC—C),但要在不同版本间做到可比较基本是不可能的。一般来说,新版本在复杂场景时性能有更多的优化,尤其是高并发和大数据集的情况下。 那么该如何选择版本呢?这更多地取决于业务需求而不是技术需求。理想情况下当然是版本越新越好,当然也可以选择等到第一个bug修复版本以后再采用新的大版本。如果应用还没有上线,也可以采用即将发布的新版本,以尽可能地延迟应用上线后的升级操作。 1.7 MySQL的开发模式 MySQL的开发过程和发布模型在不同的阶段有很大的变化,但目前已经基本稳定下来。在Oracle定期发布的新里程碑开发版本中,会包含即将在下一个GA版本发布的新特性。这样做是为了测试和获得反馈,请不要在生产环境使用此版本,虽然Oracle宣称每个里程碑版本的质量都是可靠的,并随时可以正式发布(到目前为止也没有任何理由去推翻这个说法)。Oracle也会定期发布实验室预览版,主要包含一些特定的需要评估的特性,这些特性并不保证会在下一个正式版本中包括进去。最终,Oracle会将稳定的特性打包发布一个新的GA版本。 MySQL依然遵循GPL开源协议,全部的源代码(除了一些商业版本的插件)都会开放给社区。Oracle似乎也理解,为社区和付费用户提供不同的版本并非明智之举。MySQLAB曾经尝试过不同版本的策略,结果导致付费用户变成了“睁眼瞎”,无法从社区的测试和反馈中获得好处。不同版本的策略并不受企业用户的欢迎,所以后来被Sun废除了。现在Oracle为付费用户单独提供了一些服务器插件,而MySQL本身还是遵循开源模式。尽管对于私有的服务器插件的发布有一些抱怨,但这只是少数的声音,并且慢慢地在平息。

前言

我们写这本书不仅仅是为了满足MySQL 应用开发者的需求,也是为了满足MySQL 数据库管理员的需要。我们假定读者已经有了一定的MySQL 基础。我们还假定读者对于系统管理、网络和类Unix 的操作系统都有一些了解。本书的第二版为读者提供了大量的信息,但没有一本书是可以涵盖一个主题的所有方面的。在第二版和第三版之间的这段时间里,我们记录了数以千计有趣的问题,其中有些是我们解决的,也有一些是我们观察到其他人解决的。当我们在规划第三版的时候发现,如果要把这些主题完全覆盖,可能三千页到五千页的篇幅都还不够,这样本书的完成就遥遥无期了。在反思这个问题后,我们意识到第二版强调的广泛的覆盖度事实上有其自身的限制,从某种意义上来说也没有引导读者如何按照MySQL 的方式来思考问题。所以第三版和第二版的关注点有很大的不同。我们虽然还是会包含很多的信息,并且会强调同样的诸如可靠性和正确性的目标,但我们也会在本书中尝试更深入的讨论:我们会指出MySQL 为什么会这样做,而不是MySQL 做了什么。我们会使用更多的演示和案例学习来将上述原则落地。通过这样的方式,我们希望能够尝试回到下面这样的问题:“给出MySQL 的内部结构和操作,对于实际应用能带来什么帮助?为什么能有这样的帮助?如何让MySQL 适合(或者不适合)特定的需求?”最后,我们希望关于MySQL 内部原理的知识能够帮助大家解决本书没有覆盖到的一些情况。我们更希望读者能培养发现新问题的洞察力,能学习和实践合理的方式来设计、维护和诊断基于MySQL 的系统。本书是如何组织的本书涵盖了许多复杂的主题。在这里,我们将解释一下是如何将这些主题有序地组织在一起的,以便于阅读和学习。概述第1 章是非常基础的一章,在更深入地学习之前建议先熟悉一下这部分内容。在有效地使用MySQL 之前应当理解它是如何组织的。本章解释了MySQL 的架构及其存储引擎的关键设计。如果读者还不太熟悉关系数据库和事务的基础知识,本章也可以带来一点帮助。如果之前已经对其他关系数据库如Oracle 比较熟悉,本章也可以帮助读者了解MySQL 的入门知识。本章还包括了一点MySQL 的历史背景:MySQL 随着时间的演进、最近的公司所有权更替,以及我们认为比较重要的内容。打造坚实的基础本书前几章的内容在今后使用MySQL 的过程中可能会被不断地引用到,它们是非常基础的内容。第2章讨论了基准测试的基础,例如服务器可以处理的工作负载的类型、处理特定任务的速度等。基准测试是一项至关重要的技能,可用于评估服务器在不同负载下的表现,但也要明白在什么情况下基准测试不能发挥作用。第3章介绍了我们常用于故障诊断和服务器性能问题分析的一种面向响应时间的方法。该方法已经被证明可以解决我们曾碰到过的一些极为棘手的问题。当然也可以选择修改我们所使用的方法(实际上我们的方法也是从Cary Millsap 的方法修改而来的),但无论如何,至少不能没有方法胡乱猜测。从第4章到第6 章,连续介绍了三个关于良好的数据库逻辑设计和物理设计基础的话题。第4 章涵盖了不同数据类型的细节差别以及表设计的原则。第5 章则展开讨论了索引,这是数据库的物理设计。对于索引的深入理解和利用是高效使用MySQL 的基础,相信这一章会经常需要回头翻看。而第6 章则包含了分析MySQL 的查询是如何执行的,以及如何利用查询优化器的话题。该章也包含了大量常见类型查询的例子,演示了MySQL 是如何做好工作的,以及如何改写查询以利用MySQL 的特性。到此为止,已经覆盖了关于数据库的基础内容:表、索引、数据和查询。第7 章则在MySQL 基础知识之外介绍了MySQL 的高级特性是如何工作的。这章的内容包括分区、存储引擎、触发器,以及字符集。MySQL 中这些特性的实现可能不同于其他数据库,可能之前读者并不清楚这些不同,因此理解它们对于性能可能会带来新的收益。配置应用程序接下来的两章讲述的是如何让MySQL、应用程序及硬件一起很好地工作。第8 章介绍了如何配置MySQL,以便更好地利用硬件,达到更好的可靠性和鲁棒性。第9 章解释了如何让操作系统和硬件工作得更好。另外也深入讨论了固态硬盘,为高可扩展性应用发挥更好的性能提供了硬件配置的建议。上面两章都一定程度地涉及了MySQL 的内部知识。这将会是一个反复出现的主题,附录中也会有相关内容可以学习到MySQL 的内部是如何实现的,理解了这些知识将帮助读者更好地理解某些现象背后的原理。作为基础设施组件的MySQLMySQL 不是存在于真空中的,而是应用整体的一个环节,因此需要考虑整个应用架构的鲁棒性。下面的章节将告诉我们该如何做到这一点。第10 章讨论了MySQL 的杀手级特性:能够设置多个服务器从一台主服务器同步数据。不幸的是,复制可能也是MySQL 给很多用户带来困扰的一个特性。但实际上不应该发生这样的情况,本章将告诉你如何让复制运行得更好。第11章讨论了什么是可扩展性(这和性能不是一回事),应用和系统为什么会无法扩展,该怎么改善扩展性。如果能够正确地处理,MySQL 的可扩展性是足以应付任何需求的。第12章讲述的是和可扩展性相关但又完全不同的主题:如何保障MySQL 稳定而正确地持续运行。第13 章将告诉你当MySQL 在云计算环境中运行时会有什么不同的事情发生。第14章解释了什么是全方位的优化(full-stack optimization),就是从前端到后端的整体优化,从用户体验开始直到数据库。即使是世界上设计最好、最具可扩展性的架构,如果停电会导致彻底崩溃,无法抵御恶意攻击,解决不了应用的bug 和程序员的错误,以及其他一些灾难场景,那就不是什么好的架构。第15 章讨论了MySQL 数据库各种备份与恢复的场景。这些策略可以帮助读者减少在各种不可抗的硬件失效时的宕机时间,保证在各种灾难下的数据最终可恢复。其他有用的主题在本书的最后一章以及附录中,我们探讨了一些无法明确地放到前面章节的内容,以及一些被前面多个章节引用而需要特别注意的主题。第16章探索了一些可以帮助用户更有效地管理和监控MySQL 服务器的工具,有些是开源的,也有些是商业的。附录A 介绍了近年来成长迅速的三个主要的非MySQL 官方版本,其中一个是我们公司在维护的产品。知道还有其他什么是可用的选择是有价值的;很多MySQL 难以解决的棘手问题在其他的变种版本中说不定就不是问题了。这三个版本中的两个(Percona Server 和MariaDB)是MySQL 的完全可替换版本,所以尝试使用的成本相对来说是很低的。当然,在这里我们也需要补充一点,Oracle 提供的MySQL 官方版本对于大多数用户来说都能服务得很好。附录B 演示了如何检查MySQL 服务器。知道如何从服务器获取状态信息是非常重要的;而了解这些状态代表的意义则更加重要。这里将覆盖SHOW INNODB STATUS 的输出结果,因此这里包含了InnoDB 事务存储引擎的深入信息。在这个附录中讨论了很多InnoDB的内部信息。附录C 演示了如何高效地将大文件从一个地方复制到另外一个地方。如果要管理大量的数据,这种操作是经常都会碰到的。附录D 演示了如何真正地使用并理解EXPLAIN 命令。附录E 演示了如何破除不同查询所请求的锁互相干扰的问题。最后,附录F 介绍了Sphinx,一个基于MySQL 的高性能的全文索引系统。软件版本与可用性MySQL 是一个移动靶。从Jeremy 写作本书第一版到现在,MySQL 已经发布了好几个版本。当本书第一版的初稿交给出版社的时候,MySQL 4.1 和5.0 还只是alpha 版本,而如今MySQL 5.1 和5.5 已经是很多在线应用的主力版本。在我们写完这第三版的时候,MySQL 5.6 也即将发布。本书的内容并不依赖某一个具体的版本。相反,我们会利用自己在实际环境中获得的更广泛的知识。本书的核心内容主要关注MySQL 5.1 和5.5 版本,因为我们认为这是“当前”的版本。本书的大多数例子都假设运行在MySQL 5.1 的某个成熟版本上,比如MySQL 5.1.50 或者更高的版本。对于在旧版本中可能不存在,或者只在即将到来的5.6 版本中出现的特性或者功能,我们也会特别标注出来。然而,关于某个MySQL 版本的特性的权威指南还是要看官方文档。在阅读本书时,建议随时访问在线官方文档的相关内容(http://dev.mysql.com/doc/)。MySQL 的另外一个伟大特点是能够运行在现今流行的所有平台:Mac OS X,Windows,GNU/Linux, Solaris, FreeBSD,以及只要你能举出名字的其他平台。然而,本书主要基于GNU/Linux和其他类Unix 系统。Windows 的用户可能会碰到一些困难。比如说文件路径就和Windows 完全不一样。我们也会引用一些Unix 的命令行工具,我们假设读者能够知道Windows 上对应的工具是什么。在Windows 上搞MySQL 的另外一个难点是Perl。MySQL 中有很多有用的工具是用Perl 写的。在本书的一些章节中,也有一些Perl 脚本,在此基础上可以构建更加复杂的工具。Percona Toolkit 是不可多得的MySQL 管理工具,也是用Perl 写的。然而,Windows 平台默认是没有Perl 环境的。为了使用这些工具,需要从ActiveState 下载Perl的Windows 版本,以及访问MySQL 所需要的一些额外的模块(DBI 和DBD::MySQL)。本书使用的约定下面是本书中使用的一些约定。斜体(Italic)新的名字、URL、邮件地址、用户名、主机名、文件名、文件扩展名、路径名、目录,以及Unix 命令和工具都使用斜体表示。等宽字体(Constant width)包括代码元素、配置选项、数据库和表名、变量和值、函数、模块、文件内容、命令输出等,使用的是等宽字体。加粗的等宽字体(Constant width bold)命令或者其他需要用户输入的文本,命令输出中需要强调的某些内容,会使用加粗的等宽字体。斜体的等宽字体(Constant width italic)需要用户替换的文本以斜体的等宽字体表示。使用示例代码本书的目标是为了帮助读者更好地工作。一般来说,你可以在程序或者文档中使用本书中的代码。只要不是大规模地复制重要的代码,使用的时候不需要联系我们。例如,你编写的程序中如果只是使用了本书部分的代码片段则无须取得授权,而出售或者分发O’Reilly 书籍示例代码的CD-ROM 盘片则需要经过授权。引用本书的代码回答问题也无须取得授权,而大量引用本书的示例代码到产品文档中则需要获取授权。示例代码维护在http://www.highperfmysql.com 站点中,会及时保持更新。但我们无法确保代码会跟随每一个MySQL 的小版本进行更新和测试。我们欢迎大家在使用了本书代码后进行反馈,但这不是一个强制要求。反馈时请提供标题、作者、出版公司和ISBN。例如:“High Performance MySQL, Third Edition, by Baron Schwartz et al. (O’Reilly). Copyright 2012 Baron Schwartz, Peter Zaitsev, and Vadim Tkachenko, 978-1-449-31428-6”。如果你使用了本书的代码,但又不在上面描述的一些无须授权的范围之内,不确定是否需要获取授权时,请联系permissions@oreilly.com。Safari 在线书店Safari 在线书店(www.safaribooksonline.com)是一家提供定制服务的数字图书馆,提供技术和商务领域内顶级作家的高质量内容的书籍和音像制品。很多技术专家、软件开发者、Web 设计师、商务人士和创新专家都将Safari 在线书店作为他们研究、解决问题、学习和认证练习的首选资料来源。Safari 在线书店为组织、政府机构和个人提供了一系列的产品组合和定价计划。订阅者可以访问数以千计的图书、培训视频和手稿,这些存在于一个可搜索的数据库中,涵盖的出版公司有O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional,Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons,Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress,Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology,等等。如需了解更多关于Safari 在线书店的情况,请访问在线网站。如何联系我们若有关于本书的任何评论或者问题,请和出版公司联系:O’Reilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472800-998-9938 (in the United States or Canada)707-829-0515 (international or local)707-829-0104 (fax)本书有一个配套的网页,上面列出了勘误表、示例代码及其他相关信息。下面是此网页的地址:http://shop.oreilly.com/product/0636920022343.do如果有关于本书的评论和技术问题,也可以通过邮件进行沟通:bookquestions@oreilly.com如果想了解更多关于我们出版公司的书籍、会议、资源中心和O’Reilly 网络的信息,请访问网站:http://www.oreilly.com我们的Facebook :http://facebook.com/oreilly我们的Twitter :http://twitter.com/oreillymedia我们的YouTube :http://www.youtube.com/oreillymedia当然,读者也可以直接和作者取得联系,可以访问作者的公司网站http://www.percona.com。我们将乐于收到大家的反馈。本书第三版的致谢感谢以下人员给予的各种帮助:Brian Aker, Johan Andersson, Espen Braekken, Mark Callaghan, James Day, Maciej Dobrzanski, Ewen Fortune, Dave Hildebrandt, Fernando Ipar, Haidong Ji, Giuseppe Maxia, Aurimas Mikalauskas, Istvan Podor, Yves Trudeau, Matt Yonkovit, Alex Yurchenko。感谢Percona 公司的所有员工,多年来为本书提供了无数的支持。感谢很多著名博主和技术大会的演讲者,他们为本书的很多思想提供了大量的素材,尤其是Yoshinori Matsunobu。另外也要感谢本书前面两版的作者:Jeremy D.Zawodny、Derek J. Balling 和Arjen Lentz。感谢Andy Oram、Rachel Head,以及O’Reilly的整个编辑团队,你们为本书的出版和发行做了卓有成效的工作。非常感谢Oracle 的才华横溢且专注的MySQL 团队,以及所有之前的MySQL 开发者,不管你现在是在SkySQL 还是在Monty 团队。Baron 也要感谢他的妻子Lynn、他的母亲Connie,以及他的岳父母Jane 和Roger,感谢他们一如既往地支持他的工作,尤其是不断地鼓励他,并且承担了所有的家务和照顾整个家庭的重任。也要感谢Peter 和Vadim,你们是如此优秀的老师和同事。Baron 将此版本献给Alan Rimm-Kaufman,以纪念他给予的伟大的爱和鼓励,这些都将永志不忘。本书第二版的致谢Sphinx 的开发者Andrew Aksyonoff 编写了附录F。我们非常感谢他首次对此进行深入的讨论。在编写本书的时候,我们得到了很多人的无私帮助。在此无法一一列举——我们真的非常感谢MySQL 社区和MySQL AB 公司的每一个人。下面是对本书做出了直接贡献的人,如有遗漏,还请见谅。他们是:Tobias Asplund, Igor Babaev, Pascal Borghino, RolandBouman, Ronald Bradford, Mark Callaghan, Jeremy Cole, Britt Crawford 和他的HiveDB项目,Vasil Dimov, Harrison Fisk, Florian Haas, Dmitri Joukovski 和他的 Zmanda 项目(同时感谢Dmitri 为解释LVM 快照提供的配图),Alan Kasindorf, Sheeri Kritzer Cabral,Marko Makela, Giuseppe Maxia, Paul McCullagh, B. Keith Murphy, Dhiren Patel, Sergey Petrunia, Alexander Rubin, Paul Tuckfield, Heikki Tuuri, 以及 Michael“ Monty” Widenius。在这里还要特别感谢O’Reilly 的编辑Andy Oram 和助理编辑Isabel Kunkle,以及审稿人Rachel Wheeler,同时也要感谢O’Reilly 团队的其他所有成员。来自Baron我要感谢我的妻子Lynn Rainville 和小狗Carbon。如果你也曾写过一本书,我相信你就能体会到我是如何地感谢他们。我也非常感谢Alan Rimm-Kaufman 和我在Rimm-Kaufman 集团的同事,在写书的过程中,他们给了我支持和鼓励。谢谢Peter、Vadim 和Arjen,是你们给了我梦想成真的机会。最后,我要感谢Jeremy 和Derek 为我们开了个好头。来自Peter我从事MySQL 性能和可扩展性方面的演讲、培训和咨询工作已经很多年了,我一直想把它们扩展到更多的受众。因此,当Andy Oram 加入到本书的编写当中时,我感到非常兴奋。此前我没有写过书,所以我对所需要的时间和精力都毫无把握。一开始我们谈到只对第一版做一些更新,以跟上MySQL 最新的版本升级,但我们想把更多新素材加入到书中,结果几乎相当于重写了整本书。这本书是真正的团队合作的结晶。因为我忙于Percona 公司的事情——这是我和Vadim的咨询公司,而且英语并非我的第一语言,所以我们有着不同的角色分工。我负责提供大纲和技术性内容,评审所有的材料,在写作的时候再进行修订和扩展。当Arjen(MySQL文档团队的前负责人)加入之后,我们就开始勾画出整个提纲。在Baron 加入后,一切才开始真正行动起来,他能够以不可思议的速度编写出高质量的内容。Vadim 则在深入检查MySQL 源代码和提供基准测试及其他研究来巩固我们的论点时提供了巨大的帮助。当我们编写本书时,我们发现有越来越多的领域需要刨根问底。本书的大部分主题,如复制、查询优化、InnoDB、架构和设计都足以单独成书。因此,有时候我们不得不在某个点停止深入,把余下的材料用在将来可能出版的新版本中,或者我们的博客、演讲和技术文章中。本书的评审者给了我们非常大的帮助,无论是来自MySQL AB 公司内部的人员,还是外部的人员,他们都是MySQL 领域最优秀的世界级专家。其中包括MySQL 的创建者Michael Widenius、InnoDB 的创建者Heikki Tuuri、MySQL 优化器团队的负责人Igor Babaev,以及其他人。我还要感谢我的妻子Katya Zaytseva,我的孩子Ivan 和Nadezhda,他们允许我把家庭时间花在了本书的写作上。我也要感谢Percona 的员工,当我在公司里“人间蒸发”去写书时,他们承担了日常事务的处理工作。当然,我也要感谢O’Reilly 和Andy Oram 让这一切成为可能。来自Vadim我要感谢Peter,能够在本书中和他合作,我感到十分开心,期望在其他项目中能继续共事。我也要感谢Baron,他在本书的写作过程中起了很大的作用。还有Arjen,跟他一起工作非常好玩。我还要感谢我们的编辑Andy Oram,他抱着十二万分的耐心和我们一起工作。此外,还要感谢MySQL 团队,是他们创造了这个伟大的软件。我还要感谢我们的客户给予我调优MySQL 的机会。最后,我要特别感谢我的妻子Valerie,以及我们的孩子Myroslav 和Timur,他们一直支持我,帮助我一步步前进。来自Arjen我要感谢Andy 的睿智、指导和耐心,感谢Baron 中途加入到我们当中来、感谢Peter 和Vadim 坚实的背景信息和基准测试。也要感谢Jeremy 和Derek 在第一版中打下的基础。在我的书上,Derak 题写着:“要诚实——这就是我的所有要求”。我也要感谢我在MySQL AB 公司时的所有同事,在那里我获得了关于本书主题的大多数知识。在此,我还要特别提到Monty,我一直认为他是令人自豪的MySQL 之父,尽管他的公司如今已经成为Sun 公司的一部分。我要感谢全球MySQL 社区里的每一个人。最后同样重要的是,我要感谢我的女儿Phoebe,在她尚年少的生活舞台上,不用关心什么是MySQL,也不用考虑Wiggles 指的是什么东西。从某些方面来讲,无知就是福。它能给予我们一个全新的视角来看清生命中真正重要的是什么。对于读者,祝愿你们的书架上又增添了一本有用的书,还有,不要忘记你的生活。本书第一版的致谢要完成这样一本书的写作,离不开许许多多人的帮助。没有他们的无私援助,你手上的这本书就可能仍然是我们显示器屏幕四周的那一堆贴纸。这是本书的一部分,在这里,我们可以感谢每一个曾经帮助我们脱离困境的人,而无须担心突然奏响的背景音乐催促我们闭上嘴巴赶紧走掉——如同你在电视里看到的颁奖晚会那样。如果没有编辑Andy Oram 坚决的督促、请求、央求和支持,我们就无法完成本书。如果要找对于本书最负责的一个人,那就是Andy。我们真的非常感谢每周一次的唠唠叨叨的会议。然而,Andy 不是一个人在战斗。在O’Reilly,还有一批人都参与了将那些小贴纸变成你正在看的这本书的工作。所以我们也要感谢那些在生产、插画和销售环节的人们,感谢你们把这本书变成实体。当然,也要感谢Tim O’Reilly,是他持久不变地承诺为广大开源软件出版一批业内最好的图书。最后,我们要把感谢给予那些同意审阅本书不同版本草稿,并告诉我们哪里有错误的人们:我们的评审者。他们把2003 年假期的一部分时间用在了审阅这些格式粗糙,充满了打字符号、误导性的语句和彻底的数学错误的文本上。我们要感谢(排名不分先后):Brian“ Krow” Aker, Mark“ JDBC” Matthews, Jeremy“ the other Jeremy” Cole, Mike“VBMySQL.com (http://vbmysql.com)” Hillyer, Raymond “Rainman” De Roo, Jeffrey“Regex Master” Friedl, Jason DeHaan, Dan Nelson, Steve“ Unix Wiz” Friedl, Kasia“ Unix Girl” Trapszo。来自Jeremy我要在此感谢Andy,是他同意接纳这个项目,并持续不断地鞭策我们加入新的章节内容。Derek 的帮助也非常关键,本书最后的20% ~ 30% 内容由他一手完成,这使得我们没有错过下一个目标日期。感谢他同意中途加入进来,代替我只能偶尔爆发一下的零星生产力,完成了关于XML 的烦琐工作、第10 章、附录F,以及我丢给他的那些活儿。我也要感谢我的父母,在多年以前他们就给我买了Commodore 64 电脑,他们不仅在前10 年里容忍了我就像要以身相许般的对电子和计算机技术的痴迷,并在之后还成为我不懈学习和探索的支持者。接下来,我要感谢在过去几年里在Yahoo !布道推广MySQL 时遇到的那一群人。跟他们共事,我感到非常愉快。在本书的筹备阶段,Jeffrey Friedl 和Ray Goldberger 给了我鼓励和反馈意见。在他们之后还有Steve Morris、James Harvey 和Sergey Kolychev 容忍了我在Yahoo! Finance MySQL 服务器上做着看似固定不变的实验,即使这打扰了他们的重要工作。我也要感谢Yahoo! 的其他成员,是他们帮我发现了MySQL 上的那些有趣的问题和解决方法。还有,最重要的是要感谢他们对我有足够的信任和信念,让我把MySQL 用在Yahoo! 重要和可见的部分业务上。Adam Goodman,一位出版家和Linux Magazine 的拥有者,他帮助我轻装上阵为技术受众撰写文章,并在2001 年下半年第一次出版了我的MySQL 相关的长篇文章。自那以后,他教授给我更多他所能认识到的关于编辑和出版的技能,还鼓励我通过在杂志上开设月度专栏在这条路上继续走下去。谢谢你,Adam。我要感谢Monty 和David,感谢你们与这个世界分享了MySQL。说到MySQL AB,也要感谢在那里的其他“牛”人,是他们鼓励我写成本书:Kerry, Larry, Joe, Marten,Brian, Paul, Jeremy, Mark, Harrison, Matt,以及团队中的其他人。他们真的非常棒。最后,我要感谢我博客的读者,是他们鼓励我撰写基于日常工作的非正式的MySQL 及其他技术文章。最后同样重要的是,感谢Goon Squad。来自Derek就像Jeremy 一样,有太多同样的原因,我也要感谢我的家庭。我要感谢我的父母,是他们不停地鼓励我去写一本书,哪怕他们头脑中都没有任何和它相关的东西。我的祖父母给我上了两堂很有价值的课:美元的含义,以及我跟电脑相爱有多深,他们还借钱给我去购买了我平生第一台电脑:Commodore VIC-20。我万分感谢Jeremy 邀请我加入他那旋风般的写作“过山车”中来。这是一个很棒的体验,我希望将来还能跟他一起工作。我要特别感谢Raymond De Roo, Brian Wohlgemuth, David Calafrancesco, Tera Doty, Jay Rubin, Bill Catlan, Anthony Howe, Mark O’Neal, George Montgomery, George Barber,以及其他无数耐心听我抱怨的人,我从他们那里了解到我所讲述的内容是否能让门外汉也能理解,或者仅仅得到一个我所希望的笑脸。没有他们,这本书可能也能写出来,但我几乎可以肯定我会在这个过程中疯掉。

媒体关注与评论

每一章均别具匠心,力求理论与实践的精确平衡,且布满无价之宝,有时甚至超越MySQL舞台,完全适用于任一数据库。其中第二章“MySQL基准测试”及第3章“服务器性能剖析”是非常必要的基础,推荐提前阅读。纵观全书,作者推荐的工具、实战案例及经验过的诊断技术,可大大提高你的性能急救技能,以及加深对MySQL本质的理解。然而,本书最值得推崇的,还是其在探讨性能的同时,将数据库结构的客观方面纳入思考,这是其他书里难以看到的。此外,增补的MySQL高可用性及云特性,也让人更加欣喜。相信不少人会因为找不到某些书中引用的资料或工具而苦恼,但从本书中按图索骥,会发现这些东西正是作者对MySQL社区的杰出贡献,也就是说,你可以直接用这些工具!很多年前我就是这本书的“粉丝”了,这是一本伟大的书,第三版尤其如此。这些世界级的专家不仅仅分享他们的专业知识,也花了很多时间来更新和添加新的章节,且都是高品质的内容。本书有大量关于如何获得MySQL 高性能的细节信息,并且关注的是提升性能的过程,而不仅仅是描述事实结果和琐碎的细枝末节。这本书将告诉读者如何将事情做得更好,不管MySQL 在不同版本中的行为有多么大的改变。毫无疑问,本书的作者是唯一有资格来写这么一本书的人,他们经验丰富,有合理的方法,关注效率,并且精益求精。说到经验丰富,本书的作者已经在MySQL 性能领域工作多年,从MySQL 还没有什么可扩展性和可测量性的时代,直到现在这些方面已经有了长足的进步。而说到合理的方法,他们简直把这件事情当成了科学,首先定义需要解决的问题,然后通过合理的猜测和精确的测量来解决问题。我对作者在效率方面的关注尤其印象深刻。作为顾问,他们时间宝贵。客户是按照他们的时间付费的,所以都希望能更快地解决问题。所以本书作者定义了一整套的流程,开发了很多的工具,让事情变得正确和高效。在本书中,作者详细描述了这些流程,并且发布了工具的源代码。最后,本书作者在工作上一直精益求精。比如从吞吐量到响应时间的关注,致力于了解MySQL 在新硬件上的性能表现,追求新的技能如排队理论对性能的影响,等等。我相信本书预示了MySQL 的光明前景。MySQL 已经支持高要求的工作负载,本书作者也在努力提升MySQL 社区内对性能的认识。同时,他们还直接为性能提升做出了贡献,包括XtraDB 和XtraBackup。一直以来我从他们身上学到了不少东西,也希望读者多花点时间读读本书,一定会同样有所收益。——Mark Callaghan,Facebook 软件工程师

内容概要

关于作者
Baron Schwartz 是一位软件工程师,居住在弗吉尼亚州的Charlottesville,网络常用名是Xaprb,这是按照QWERTY 键盘的顺序在Dvorak 键盘上打出来的名字。在不忙于解决有趣的编程挑战时,Baron 会和他的妻子Lynn 以及小狗Carbon 一起享受闲暇的时光。他有一个软件工程方面的博客,地址是http://www.xaprb.com/blog/
Peter Zaitsev 曾经是MySQL AB 公司高性能组的经理,目前在运作mysqlperformance
blog.com 网站。他擅长于帮助那些每天有数以百万计访问量的网站的管理员解决问题,这些网站通常需要几百台机器来处理TB 级的数据。他常常为了解决一个问题而不停地升级硬件和软件(比如查询优化)。Peter 还经常在各种会议上演讲。
Vadim Tkachenko 曾经是MySQL AB 公司的性能工程师。作为一名在多线程编程和同步方面的专家,他的主要工作是基准测试、性能剖析,以及找出系统的性能瓶颈。他还在性能监控和调优方面做了一些工作,使得MySQL 在多核机器上有更好的可扩展性。
================================================================
译者简介
宁海元 有超过十年的数据库管理经验,从最初到SQL Server 2000到Oracle到MySQL,擅长数据库高可用架构,性能优化和故障诊断。2007年加入淘宝,带领淘宝DBA团队支撑了淘宝业务的快速增长,完成了数据库的垂直拆分、水平拆分,迁移到MySQL体系等主要工作。目前专注于无线数据领域。网络常用名NinGoo,个人博客:http://www.ningoo.net
周振兴 毕业于北京师范大学数学系,09年加入淘宝数据库团队负责MySQL运维管理工作,有丰富的MySQL性能优化、Troubleshooting经验,对MySQL主要模块的实现和原理有深入的研究,经历淘宝MySQL实例从30到3000的发展,对系统架构、高可用环境规划都有深入理解。个人博客:http://orczhou.com
彭立勋 2010年大学毕业后加入阿里巴巴运维部。作为一名MySQL DBA,在运维MySQL的过程中,对MySQL和InnoDB的一些功能和缺陷就进行了补充,编写了多主复制和数据闪回等补丁。目前在阿里集团核心系统研发部数据库组,专注于MySQL数据库相关的开发工作。后来一些补丁被MySQL之父Mony看中,成为MariaDB提交组(Maria-captains)成员,并且把多主复制,线程内存监控等补丁合并到了MariaDB 10.0版本。
翟卫祥 毕业于武汉大学,研究生阶段从事数据库相关研究。毕业后就职于阿里巴巴集团数据库技术团队至今,主要负责阿里内部MySQL代码分支维护,包括MySQL Bug Fix及新特性开发。对MySQL内核有一定的研究。
刘辉 2008年毕业于西安电子科技大学计算机系,硕士学位。2011年加入阿里巴巴集团数据库技术团队,花名希羽,MySQL内核开发工程师。

书籍目录

推荐序 xxiii
前言 xxv
第1 章 mysql 架构与历史 1
1.1 mysql 逻辑架构 1
1.1.1 连接管理与安全性2
1.1.2 优化与执行 3
1.2 并发控制 3
1.2.1 读写锁 4
1.2.2 锁粒度 4
1.3 事务6
1.3.1 隔离级别 8
1.3.2 死锁 9
1.3.3 事务日志 10
1.3.4 mysql 中的事务 10
1.4 多版本并发控制 12
1.5 mysql 的存储引擎 13
1.5.1 innodb 存储引擎 16
1.5.2 myisam 存储引擎 17
1.5.3 mysql 内建的其他存储引擎 19
.1.5.4 第三方存储引擎 22
1.5.5 选择合适的引擎 24
1.5.6 转换表的引擎 27
1.6 mysql 时间线(timeline) 29
1.7 mysql 的开发模式 32
1.8 总结 33
第2 章 mysql 基准测试 35
2.1 为什么需要基准测试 35
2.2 基准测试的策略 37
2.2.1 测试何种指标 38
2.3 基准测试方法 40
2.3.1 设计和规划基准测试 41
2.3.2 基准测试应该运行多长时间 42
2.3.3 获取系统性能和状态 43
2.3.4 获得准确的测试结果 44
2.3.5 运行基准测试并分析结果 46
2.3.6 绘图的重要性 47
2.4 基准测试工具 49
2.4.1 集成式测试工具 49
2.4.2 单组件式测试工具 50
2.5 基准测试案例 52
2.5.1 http_load 53
2.5.2 mysql 基准测试套件 54
2.5.3 sysbench 55
2.5.4 数据库测试套件中的dbt2 tpc-c 测试 60
2.5.5 percona 的tpcc-mysql 测试工具 63
2.6 总结 65
第3 章 服务器性能剖析 67
3.1 性能优化简介 67
3.1.1 通过性能剖析进行优化 69
3.1.2 理解性能剖析 71
3.2 对应用程序进行性能剖析 72
3.2.1 测量php 应用程序 74
3.3 剖析mysql 查询 77
3.3.1 剖析服务器负载 77
3.3.2 剖析单条查询 81
3.3.3 使用性能剖析 87
3.4 诊断间歇性问题 88
3.4.1 单条查询问题还是服务器问题 89
3.4.2 捕获诊断数据 93
3.4.3 一个诊断案例 98
3.5 其他剖析工具 106
3.5.1 使用user_statistics 表 106
3.5.2 使用strace 107
3.6 总结 108
第4 章 schema 与数据类型优化 111
4.1 选择优化的数据类型 111
4.1.1 整数类型 113
4.1.2 实数类型 113
4.1.3 字符串类型 114
4.1.4 日期和时间类型 121
4.1.5 位数据类型 123
4.1.6 选择标识符(identifier) 125
4.1.7 特殊类型数据 127
4.2 mysql schema 设计中的陷阱 127
4.3 范式和反范式 129
4.3.1 范式的优点和缺点 130
4.3.2 反范式的优点和缺点 130
4.3.3 混用范式化和反范式化 131
4.4 缓存表和汇总表 132
4.4.1 物化视图 134
4.4.2 计数器表 135
4.5 加快alter table 操作的速度 136
4.5.1 只修改.frm 文件 137
4.5.2 快速创建myisam 索引 139
4.6 总结 140
第5 章 创建高性能的索引 141
5.1 索引基础 141
5.1.1 索引的类型 142
5.2 索引的优点 152
5.3 高性能的索引策略 153
5.3.1 独立的列 153
5.3.2 前缀索引和索引选择性 153
5.3.3 多列索引 157
5.3.4 选择合适的索引列顺序 159
5.3.5 聚簇索引 162
5.3.6 覆盖索引 171
5.3.7 使用索引扫描来做排序 175
5.3.8 压缩(前缀压缩)索引 177
5.3.9 冗余和重复索引 178
5.3.10 未使用的索引 181
5.3.11 索引和锁 181
5.4 索引案例学习 183
5.4.1 支持多种过滤条件 183
5.4.2 避免多个范围条件 185
5.4.3 优化排序 186
5.5 维护索引和表 187
5.5.1 找到并修复损坏的表 187
5.5.2 更新索引统计信息 188
5.5.3 减少索引和数据的碎片 190
5.6 总结 192
第6 章 查询性能优化 195
6.1 为什么查询速度会慢 195
6.2 慢查询基础:优化数据访问 196
6.2.1 是否向数据库请求了不需要的数据 196
6.2.2 mysql 是否在扫描额外的记录 198
6.3 重构查询的方式 201
6.3.1 一个复杂查询还是多个简单查询 201
6.3.2 切分查询 202
6.3.3 分解关联查询 203
6.4 查询执行的基础 204
6.4.1 mysql 客户端/ 服务器通信协议 205
6.4.2 查询缓存 208
6.4.3 查询优化处理 208
6.4.4 查询执行引擎 222
6.4.5 返回结果给客户端 223
6.5 mysql 查询优化器的局限性 223
6.5.1 关联子查询 223
6.5.2 union 的限制 228
6.5.3 索引合并优化 228
6.5.4 等值传递 229
6.5.5 并行执行 229
6.5.6 哈希关联 229
6.5.7 松散索引扫描 229
6.5.8 最大值和最小值优化 231
6.5.9 在同一个表上查询和更新 232
6.6 查询优化器的提示(hint) 232
6.7 优化特定类型的查询 236
6.7.1 优化count() 查询 236
6.7.2 优化关联查询 239
6.7.3 优化子查询 239
6.7.4 优化group by 和distinct 239
6.7.5 优化limit 分页 241
6.7.6 优化sql_calc_found_rows 243
6.7.7 优化union 查询 243
6.7.8 静态查询分析 244
6.7.9 使用用户自定义变量 244
6.8 案例学习 251
6.8.1 使用mysql 构建一个队列表 251
6.8.2 计算两点之间的距离 254
6.8.3 使用用户自定义函数 257
6.9 总结 258
第7 章 mysql 高级特性 259
7.1 分区表 259
7.1.1 分区表的原理 260
7.1.2 分区表的类型 261
7.1.3 如何使用分区表 262
7.1.4 什么情况下会出问题 263
7.1.5 查询优化 266
7.1.6 合并表 267
7.2 视图 270
7.2.1 可更新视图 272
7.2.2 视图对性能的影响 273
7.2.3 视图的限制 274
7.3 外键约束 275
7.4 在mysql 内部存储代码 276
7.4.1 存储过程和函数 278
7.4.2 触发器 279
7.4.3 事件 281
7.4.4 在存储程序中保留注释 283
7.5 游标 283
7.6 绑定变量 284
7.6.1 绑定变量的优化 286
7.6.2 sql 接口的绑定变量 286
7.6.3 绑定变量的限制 288
7.7 用户自定义函数 289
7.8 插件 290
7.9 字符集和校对 291
7.9.1 mysql 如何使用字符集 292
7.9.2 选择字符集和校对规则 295
7.9.3 字符集和校对规则如何影响查询 296
7.10 全文索引 299
7.10.1 自然语言的全文索引 300
7.10.2 布尔全文索引 302
7.10.3 mysql5.1 中全文索引的变化 303
7.10.4 全文索引的限制和替代方案 304
7.10.5 全文索引的配置和优化 306
7.11 分布式(xa)事务 307
7.11.1 内部xa 事务 307
7.11.2 外部xa 事务 308
7.12 查询缓存 309
7.12.1 mysql 如何判断缓存命中 309
7.12.2 查询缓存如何使用内存 311
7.12.3 什么情况下查询缓存能发挥作用 313
7.12.4 如何配置和维护查询缓存 316
7.12.5 innodb 和查询缓存 319
7.12.6 通用查询缓存优化 320
7.12.7 查询缓存的替代方案 321
7.13 总结 321
第8 章 优化服务器设置 325
8.1 mysql 配置的工作原理 326
8.1.1 语法、作用域和动态性 327
8.1.2 设置变量的副作用 328
8.1.3 入门 331
8.1.4 通过基准测试迭代优化 332
8.2 什么不该做 333
8.3 创建mysql 配置文件 335
8.3.1 检查mysql 服务器状态变量 339
8.4 配置内存使用 340
8.4.1 mysql 可以使用多少内存? 340
8.4.2 每个连接需要的内存 341
8.4.3 为操作系统保留内存 341
8.4.4 为缓存分配内存 342
8.4.5 innodb 缓冲池(buffer pool) 342
8.4.6 myisam 键缓存(key caches) 344
8.4.7 线程缓存 346
8.4.8 表缓存(table cache) 347
8.4.9 innodb 数据字典(data dictionary) 348
8.5 配置mysql 的i/o 行为 349
8.5.1 innodb i/o 配置 349
8.5.2 myisam 的i/o 配置 361
8.6 配置mysql 并发 363
8.6.1 innodb 并发配置 364
8.6.2 myisam 并发配置 365
8.7 基于工作负载的配置 366
8.7.1 优化blob 和text 的场景 367
8.7.2 优化排序(filesorts) 368
8.8 完成基本配置 369
8.9 安全和稳定的设置 371
8.10 高级innodb 设置 374
8.11 总结 376
第9 章 操作系统和硬件优化 377
9.1 什么限制了mysql 的性能 377
9.2 如何为mysql 选择cpu 378
9.2.1 哪个更好:更快的cpu 还是更多的cpu 378
9.2.2 cpu 架构 380
9.2.3 扩展到多个cpu 和核心 381
9.3 平衡内存和磁盘资源 382
9.3.1 随机i/o 和顺序i/o 383
9.3.2 缓存,读和写 384
9.3.3 工作集是什么 385
9.3.4 找到有效的内存/ 磁盘比例 386
9.3.5 选择硬盘 387
9.4 固态存储 389
9.4.1 闪存概述 390
9.4.2 闪存技术 391
9.4.3 闪存的基准测试 392
9.4.4 固态硬盘驱动器(ssd) 393
9.4.5 pcie 存储设备 395
9.4.6 其他类型的固态存储 396
9.4.7 什么时候应该使用闪存 396
9.4.8 使用flashcache 397
9.4.9 优化固态存储上的mysql 399
9.5 为备库选择硬件 402
9.6 raid 性能优化 403
9.6.1 raid 的故障转移、恢复和镜像 405
9.6.2 平衡硬件raid 和软件raid 406
9.6.3 raid 配置和缓存 407
9.7 san 和nas 410
9.7.1 san 基准测试 411
9.7.2 使用基于nfs 或smb 的san 412
9.7.3 mysql 在san 上的性能 412
9.7.4 应该用san 吗 413
9.8 使用多磁盘卷 414
9.9 网络配置 416
9.10 选择操作系统 418
9.11 选择文件系统 419
9.12 选择磁盘队列调度策略 421
9.13 线程 422
9.14 内存交换区 422
9.15 操作系统状态 424
9.15.1 如何阅读vmstat 的输出 425
9.15.2 如何阅读iostat 的输出 426
9.15.3 其他有用的工具 428
9.15.4 cpu 密集型的机器 428
9.15.5 i/o 密集型的机器 429
9.15.6 发生内存交换的机器 430
9.15.7 空闲的机器 430
9.16 总结 431
第10 章 复制 433
10.1 复制概述 433
10.1.1 复制解决的问题 434
10.1.2 复制如何工作 435
10.2 配置复制 436
10.2.1 创建复制账号 437
10.2.2 配置主库和备库 437
10.2.3 启动复制 439
10.2.4 从另一个服务器开始复制 441
10.2.5 推荐的复制配置 443
10.3 复制的原理 445
10.3.1 基于语句的复制 445
10.3.2 基于行的复制 446
10.3.3 基于行或基于语句:哪种更优 446
10.3.4 复制文件 448
10.3.5 发送复制事件到其他备库 449
10.3.6 复制过滤器 450
10.4 复制拓扑 452
10.4.1 一主库多备库 452
10.4.2 主动- 主动模式下的主- 主复制 453
10.4.3 主动- 被动模式下的主- 主复制 455
10.4.4 拥有备库的主- 主结构 456
10.4.5 环形复制 457
10.4.6 主库、分发主库以及备库 458
10.4.7 树或金字塔形 460
10.4.8 定制的复制方案 460
10.5 复制和容量规划 465
10.5.1 为什么复制无法扩展写操作 466
10.5.2 备库什么时候开始延迟 466
10.5.3 规划冗余容量 467
10.6 复制管理和维护 468
10.6.1 监控复制 468
10.6.2 测量备库延迟 469
10.6.3 确定主备是否一致 469
10.6.4 从主库重新同步备库 470
10.6.5 改变主库 471
10.6.6 在一个主- 主配置中交换角色 476
10.7 复制的问题和解决方案 477
10.7.1 数据损坏或丢失的错误 477
10.7.2 使用非事务型表 480
10.7.3 混合事务型和非事务型表 480
10.7.4 不确定语句 481
10.7.5 主库和备库使用不同的存储引擎 481
10.7.6 备库发生数据改变 481
10.7.7 不唯一的服务器id 482
10.7.8 未定义的服务器id 482
10.7.9 对未复制数据的依赖性 482
10.7.10 丢失的临时表 483
10.7.11 不复制所有的更新 484
10.7.12 innodb 加锁读引起的锁争用 484
10.7.13 在主- 主复制结构中写入两台主库 486
10.7.14 过大的复制延迟 488
10.7.15 来自主库的过大的包 491
10.7.16 受限制的复制带宽 491
10.7.17 磁盘空间不足 492
10.7.18 复制的局限性 492
10.8 复制有多快 492
10.9 mysql 复制的高级特性 494
10.10 其他复制技术 496
10.11 总结 498
第11 章 可扩展的mysql 501
11.1 什么是可扩展性 501
11.1.1 正式的可扩展性定义 503
11.2 扩展mysql 507
11.2.1 规划可扩展性 507
11.2.2 为扩展赢得时间 508
11.2.3 向上扩展 509
11.2.4 向外扩展 510
11.2.5 通过多实例扩展 525
11.2.6 通过集群扩展 526
11.2.7 向内扩展 530
11.3 负载均衡 532
11.3.1 直接连接 534
11.3.2 引入中间件 537
11.3.3 一主多备间的负载均衡 540
11.4 总结 541
第12 章 高可用性 543
12.1 什么是高可用性 543
12.2 导致宕机的原因 544
12.3 如何实现高可用性 545
12.3.1 提升平均失效时间(mtbf) 545
12.3.2 降低平均恢复时间(mttr) 547
12.4 避免单点失效 548
12.4.1 共享存储或磁盘复制 549
12.4.2 mysql 同步复制 551
12.4.3 基于复制的冗余 555
12.5 故障转移和故障恢复 556
12.5.1 提升备库或切换角色 558
12.5.2 虚拟ip 地址或ip 接管 558
12.5.3 中间件解决方案 559
12.5.4 在应用中处理故障转移 560
12.6 总结 560
第13 章 云端的mysql 563
13.1 云的优点、缺点和相关误解 564
13.2 mysql 在云端的经济价值 566
13.3 云中的mysql 的可扩展性和高可用性 567
13.4 四种基础资源 568
13.5 mysql 在云主机上的性能 569
13.5.1 在云端的mysql 基准测试 571
13.6 mysql 数据库即服务(dbaas) 573
13.6.1 amazon rds 573
13.6.2 其他dbaas 解决方案 574
13.7 总结 575
第14 章 应用层优化 577
14.1 常见问题 577
14.2 web 服务器问题 579
14.2.1 寻找最优并发度 581
14.3 缓存 582
14.3.1 应用层以下的缓存 583
14.3.2 应用层缓存 584
14.3.3 缓存控制策略 586
14.3.4 缓存对象分层 587
14.3.5 预生成内容 588
14.3.6 作为基础组件的缓存 589
14.3.7 使用handlersocket 和memcached 589
14.4 拓展mysql 590
14.5 mysql 的替代品 590
14.6 总结 591
第15 章 备份与恢复 593
15.1 为什么要备份 594
15.2 定义恢复需求 595
15.3 设计mysql 备份方案 596
15.3.1 在线备份还是离线备份 597
15.3.2 逻辑备份还是物理备份 598
15.3.3 备份什么 601
15.3.4 存储引擎和一致性 603
15.4 管理和备份二进制日志 605
15.4.1 二进制日志格式 606
15.4.2 安全地清除老的二进制日志 607
15.5 备份数据 607
15.5.1 生成逻辑备份 607
15.5.2 文件系统快照 610
15.6 从备份中恢复 617
15.6.1 恢复物理备份 618
15.6.2 还原逻辑备份 619
15.6.3 基于时间点的恢复 622
15.6.4 更高级的恢复技术 624
15.6.5 innodb 崩溃恢复 625
15.7 备份和恢复工具 628
15.7.1 mysql enterprise backup 628
15.7.2 percona xtrabackup 628
15.7.3 mylvmbackup 629
15.7.4 zmanda recovery manager 629
15.7.5 mydumper 629
15.7.6 mysqldump 629
15.8 备份脚本化 631
15.9 总结 633
第16 章 mysql 用户工具 635
16.1 接口工具 635
16.2 命令行工具集 636
16.3 sql 实用集 637
16.4 监测工具 637
16.4.1 开源的监控工具 638
16.4.2 商业监控系统 640
16.4.3 innotop 的命令行监控 642
16.5 总结 646
附录a mysql 分支与变种 649
附录b mysql 服务器状态 655
附录c 大文件传输 683
附录d explain 687
附录e 锁的调试 703
附录f 在mysql 上使用sphinx 713
索引 739

编辑推荐

《高性能MySQL(第3版)》编辑推荐:“只要你不敢以MySQL专家自诩,又岂敢错过这本神书?”“一言以蔽之,写得好,编排得好,需要参考时容易到爆!”“我可是从头到尾看了一遍上一版,可还是毫不犹豫拿起了这本书,而且看完后一点都不后悔……”

作者简介

《高性能mysql(第3版)》是mysql 领域的经典之作,拥有广泛的影响力。第3 版更新了大量的内容,不但涵盖了最新mysql 5.5版本的新特性,也讲述了关于固态盘、高可扩展性设计和云计算环境下的数据库相关的新内容,原有的基准测试和性能优化部分也做了大量的扩展和补充。全书共分为16 章和6 个附录,内容涵盖mysql 架构和历史,基准测试和性能剖析,数据库软硬件性能优化,复制、备份和恢复,高可用与高可扩展性,以及云端的mysql 和mysql相关工具等方面的内容。每一章都是相对独立的主题,读者可以有选择性地单独阅读。
《高性能mysql(第3版)》不但适合数据库管理员(dba)阅读,也适合开发人员参考学习。不管是数据库新手还是专家,相信都能从本书有所收获。


 高性能MySQL下载 精选章节试读 更多精彩书评



发布书评

 
 


精彩书评 (总计3条)

  •     “只要你不敢以MySQL专家自诩,又岂敢错过这本神书?”“一言以蔽之,写得好,编排得好,需要参考时容易到爆!”每一章均别具匠心,力求理论与实践的精确平衡,且布满无价之宝,有时甚至超越MySQL舞台,完全适用于任一数据库。
  •     大家吐槽的是第二版的翻译,这个是第三版,翻译人员都是淘宝的大师,质量已经有了很大的提高,这个中文版还是很值得一看的。附上其中之一翻译人员的blog,看看blog就知道大师的水平http://www.orczhou.com/index.php/2013/04/high-performance-mysql-3rd-trans/
  •     在知乎上发过一次,这里也发一遍吧--------正文开始--------草草翻完了《高性能MySQL》,印象最深的地方就是:这确实不适合初学者去看。花了三个月的时间慢慢看完了这本,看的一头雾水。第一章概论讲了不少新奇的概念,比如隔离级别,比如多版本并发控制(MVVC)。但是从第二章起,所讲的内容基本就和日常应用没什么太大关系了。如果要简单概括一下的话就是1. 储存引擎务必使用InnoDB2. 创建新数据库时要用最新的MySQL版本(当然是GA版)3. 轻易不要升级MySQL然后就没了。对于其他的内容,不管是服务器性能优化还是MySQL主从备份,这些其实都和一名普通的技术人员没有关系。相较于书中提到的通过修改frm文件实现快速新增列这种神奇方法,技术人员最好的做法还是:尽可能的避免使用alter语句或者说在项目一开始时就要想好数据表的用途。如果你是想改进自己的SQL水平的话,那应该去看 SQL快速优化300例 ,至少,不是这本书。写一下收获吧(SQL相关,不仅仅是MySQL),毕竟翻完了不是。1. 尽量避免在线上使用alter在使用alter新增列时,会引发一个全表锁,数据库会暂停响应直到新列添加完成(在已有数据中添加新列,在数据库表结构中添加列定义)。锁定的时间随表内数据量的大小线性增长。如果是在线上环境的话,即使很短的时间,也够阻塞不少请求了←_←2. 可以通过冗余数据来提升SQL查询的性能在标准的数据库教科书中,数据表结构按说是要符合范式要求的(1NF~5NF)。比如,通过把用户信息和订单内容独立开,这样就可以设计出来没有冗余数据的数据库表结构——俗称学院派数据库表结构。但是,学院派依托的环境是银行系统这样的大型工程,查询带来的性能损耗远小于冗余数据带来的损耗。但在真实应用中,表里的数据很少能达到1000万行以上的,在这时,大部分的性能全浪费在多次查询上了。这时候,学院派的做法就不如直接在数据表中添加冗余数据(例如把用户手机号和订单一起存取),这样在展示的时候一条SQL就可以搞定。> 『PHP绝大部分的性能都浪费在和MySQL服务器通讯上了』3. 使用tinyint或者varchar作为枚举类型,而不是使用enum理由很简单: enum在新增类型的时候需要使用alter语句进行全表新增,线上数据库时不时的来上一回全表锁谁受的了。。。一般来说,使用 tinyint + 代码中利用常量进行定义 是最好的方案,如果要增强可读性的话可以使用varchar, 因为常量一共也不超过10个字母,从性能上来说varchar也可以接受4. 可视化工具客户端的话个人建议使用adminer,有ngnix之后配上一个index.php文件就能用。非要使用客户端的话用MySQL Workbench也可以,MySQL自己出的。这两个都在《高性能MySQL》的推荐之列,可以考虑5. 使用调试语句查看性能常用的调试语句如EXPLAIN, SHOW这种,现用现查即可6. 索引数据一般都在内存里结论:排序时直接使用索引排序是最快的,索引不要太多,太多之后跟把整个表放内存里就等效了(还不如使用Redis)补充:排序时EXPLAIN发现不是index,而是filesort也不用太担心,因为只有这两种状态,不是index就是filesort,性能只要不是太坑直接上就行7. 分表分库,历史数据独立建表MySQL处理1000万行以下的数据时性能是非常好的——那1000万行以上时怎么办呢?直接分表啊。比如,可以按时间分,自增id在500万之前的,独立分到一个表里,在程序代码里写死,用到的时候再去读或者,按一个数取模,根据余数选择对应的表。8. 对于重要数据,一定要开启二进制日志手滑删过全表的同学都懂。。。然后,解释下两个概念:1. 隔离级别每执行一次SQL称为一件事务,如果事务所涉及到的内容在事务进行中发生了改变,对应于事务所能读取到的实际内容,就产生了四种标准情况,这四种标准情况被称为四种隔离级别(仅就MySQL而言,对于其他数据库实现可能会有不同的区分标准)1. READ UNCOMMIT(未提交读)在READ UNCOMMIT级别中,即使没有提交,每个事务的操作对于其他事务也都是可见的。在这种情况下,事务可以读取未提交的数据,又称脏读(DIRTY READ)。从性能上来说,脏读并不比其他模式优秀多少,但是会引发各种严重的问题(比如说银行存款数据写入到一半来了一个读操作。。。)。一般情况下,不建议使用2. READ COMMIT(未提交读)大部分数据库系统默认的隔离级别都是READ COMMIT(但MySQL不是)。在READ COMMIT这一级别中,事务所修改的数据只有提交了之后才会被其他事务读取到。换句话说,一个事物从开始之后到结束之前,所做的任何修改对其他事物都是不可见的。这个级别实际上已经比较符合我们读取数据的预期了。但是,如果执行两次同样的查询,可能会出现两遍结果不一致的情况(查询执行过程中有其他事务提交完成),所以,这一级别又叫不可重复读(nonrepeatable read)3. REPEATABLE READ(可重复读)REPEATABLE READ解决了脏读的问题,同时也是MySQL的默认事务隔离级别。这一级别保证了在同一个事务中多次读取同样的记录结果是一致的。但是理论上,可重复读还是没法解决幻读(Phantom Read)的问题。幻读是指:在某个事务读取某个范围内的的记录时(id>1 && id < 100),另外一个事物又再该范围内插入了新纪录,当之前的事务再次读取该范围的记录时,就会产生幻行(Phantom Row)。不过InnoDB通过多版本并发控制(MVVC, Multiversion Concurrency Control)解决了这个问题4. SERIALIZABLE(可串行话)SERIALIZABLE是最高的隔离级别。它通过强制让事务串行执行,可以避免前面所说的全部问题。本质上说,SERIALIZABLE会在读取的每一行数据上都加上锁, 对性能影响非常严重。只有在非常需要确保数据一致性,且可以接受没有并发的情况下,才可以考虑使用此级别2. 多版本并发控制这是个很玄乎的词,但说白了就是:通过保存数据在某个时间点的快照,来确保对于不同开始时间的事务,他们对于同一张表,在同一时刻看到的数据都是一样的。对于InnoDB来说就是:通过在每行记录后边保存两个隐藏列,一列记录创建时间,一列记录过期时间(实际上存储的是系统版本号),每开始一个事务,系统版本号都会自动递增。在事务开始时刻的系统版本号就会作为事务的版本号,用来作为数据库查询的依据,以此实现:多版本并发控制大致就这些。看起来很高大上的一本书,实际上看了跟没看差不多(DBA除外)。不推荐阅读/购买

精彩短评 (总计68条)

  •     非常不错的一本书,推荐给大家
  •     看的挺爽得,很系统全面
  •     不光介绍了数据库,还介绍了一些架构知识
  •     不管是dba还是开发人员都应该读读这本书,只要你会用到mysql就应该读一读。虽然有那么一点点老,大部分内容还是不过时的,主要是写的太好了。
  •     很好,就是书太厚了。
  •     索引,表结构,查询,各种高可用,高性能方案挺实用的。
  •     比较全面的一本书,值得参考。看的是电子书,需要收藏本纸质书,不过内容是针对5.1到5.5的,希望能出新版,更新5.6/5.7的内容。
  •     好牛逼!
  •     看了前几章和执行计划
  •     深入MySQL必看之书
  •     内容非常细,对比很多,很多东西不适合互联网应用,作者也都有提示。
  •     很不错的一本书,内容很详细,翻译的也很不错。
  •     真尼玛厚……
  •     讲述mysql较深层技术。四五六这三章分别涉及数据类型声明、索引类型与存储引擎分析、查询优化。就光着三章就绝对值回书费!
  •     不错
  •     今天刚收到货,刚翻了几页,印刷不怎么好,纸质有点黄薄。
  •     只适合dba去读,不推荐
  •     全面深入。
  •     一本随时都要复习的Mysql书籍
  •     不错,值得看,翻译来自阿里
  •     感觉思路清晰了很多,其实主要是介绍方法论
  •     书那动手还没则么看内容,大概翻了下感觉质量太差劲,有点盗版的感觉! 纸挺薄的 ,胶装的感觉不牢固,觉着不值那个价钱!
  •     怎么说呢,这本书还是相当不错的
  •     翻译一般,可惜现在水平不够,等对Mysql有个整体认识后再看英文的
  •     对于想要了解MySQL性能提升的人来说,这是一本不可多得的书。书中没有各种提升性能的秘籍,而是深入问题的核心,详细的解释了每种提升性能的原理,从而可以使你四两拨千斤。授之于鱼不如授之于渔,这本书做到了。
  •     性价比的意思就是说我买不起好的那就退而求其次吧。
  •     这玩意儿光看记不住
  •     这本书非常好,对有一定数据库基础的读者非常有帮助。
  •     一本后悔没有早点看的书
  •     本来要给五星的,因为是一本好书,可惜被国内的某些自认为很牛逼的人翻译垃圾了,看了半天,我不知道他想说什么(可能是我水平不够吧)。后来,我找了一份英语原版的图书看了一下,发现这帮人翻译软件用的太好了,不仅语句读起来怪怪的,而且你不知道他想说啥,最重要的是,有些他不会翻译的,居然直接跳过去了。总之,一句话,如果你真的想翻译的话,并且想从中挣钱,那么请对读者负责~
  •     一星不是代表书的内容很烂,而是翻译的真的很烂。第一遍读的时候感觉很好,因为那时不懂,再读的时候好多地方翻译的都不通。建议有能力的人不要买中文版,因为翻译实在太烂太烂!
  •     MySQL的中高级教程
  •     好书,推荐,就是内容太多,一遍不够
  •     比较啰嗦,大部分内容可以不看
  •     索引和查询性能优化写得真心详细,但是索引的建立顺序感觉还是不是很直观,可能我的问题,读的次数不够,但是对索引的底层实现有一定的剖析,bTree的实现据说很简洁。复制那章,我也喜欢,挺好理解的,还有第十一章第三节的那个负载均衡图,画得实在太好了,直观得令人发指,深得我心
  •     这是一本学习MySQL的好书,值得研究学习。
  •     刚看了2章,前几章翻译是宁海元翻译的,有些脱离原文,信达雅,第一层次都没有达到,不知道后面翻译如何。有些地方,需要借助原版,原版看得很明白, 但是读翻译,有时候就是云里雾里。我认为翻译作品,是有责任的,你领了版税了,就有义务把东西翻译好。总而言之,原书非常好,能翻译也很好,如何不认真翻译,糟蹋了可惜。
  •     这本书看完了,就知道mysql 怎么用了,基本上用的层面就不会碰上问题了。强烈推荐。。
  •     这书好厚呀。举个例子就会说,如果有几十个CPU几百G内存的服务器,该怎么样怎么样,让我们用普通机子的怎么活
  •     感觉到了作者的深厚功力,我觉得翻译的不错。优化服务器设置,操作系统和硬件优化,云端的mysql章节没有读。
  •     适合DBA阅读
  •     封面是雀鹰,也叫鹞。讲了很多数据库的通用基础知识,终于分清楚了innoDB和MyISAM的区别啦
  •     寄过来的时候书的一脚被压得翘起来了,快递要注意了,内容涵盖很多,今后要好好读。
  •     就是太细了。
  •     好东东,你值得用用!!!
  •     非常有用的一本书,但是需要有些基础
  •     看完这本书,数据库方面的功力会大增。
  •     看着评论来购买的,而且实惠,学习大牛们的经验
  •     快速过了一遍,了解一些概念
  •     关键就是3-6和9-11章,表结构设计,索引,分库分表,EXPLAIN+执行计划。挺全的,不过很多东西都是假设你有清晰的概念,还是配合搜索看最合适
  •     非常好的一本书,喜欢研究mysql的值得一读
  •     有性能优化的部分
  •     暂时只看了需要用的几章,很不错,有实战,有理论,结合的很好
  •     书比较不错,内容挺好
  •     一直想买这本书,终于买了!
  •     对于mysql的原理介绍相当清晰. 非DBA工作人员可以着重阅读4-7章. 遇到问题可以作为工具书查阅
  •     大神的书,出到了第三版,已经不需要我多说什么了吧!好
  •     查询优化没看
  •     有一定的实践基础后,再读这本书会受益匪浅
  •     三天扫完
  •     翻译的有点次...
  •     2017:12。
  •     基础比较好就挨着看吧,也可以跳着看。总之,你得翻来覆去的看,边做边看,非常好,是我最喜欢的几本书之一.....
  •     书不错,包装也好,顶
  •     不错,准备购买
  •     除了Mysql本身,也能获得许多构建高负载应用的其他知识。对非DBA,许多章节也极具实践指导意义
  •     索引、性能优化、Schema部分细读了一下,受益匪浅。
  •     放办公室的,已翻烂。
 

外国儿童文学,篆刻,百科,生物科学,科普,初中通用,育儿亲子,美容护肤PDF图书下载,。 零度图书网 

零度图书网 @ 2024