第1章：MySQL架构与历史
MySQL拥有分层的架构。上层是服务器层的服务和查询执行引擎，下层则是存储引擎。虽然有很多不同作用的插件API，但存储引擎API还是最重要的。如果能理解MySQL在存储引擎和服务层之间处理查询时如何通过API来回交互，就能抓住MySQL的核心基础架构的精髓。
MySQL最初基于ISAM构建（后来别MyISAM取代），其后陆续添加了更多的存储引擎和事务支持。MySQL有一些怪异的行为是由于历史遗留导致的。例如，在执行ALTER TABLE时，MySQL提交事务的方式是由于存储引擎的架构直接导致的，并且数据字典也保存在.frm文件中（这并不是说InnoDB会导致ALTER变成非事务型的。对于InnoDB来说，所有的操作都是事务）。
当然，存储引擎API的架构也有一些缺点。有时候选择多并非好事，而在MySQL5.0和MySQL5.1中有太多的存储引擎可以选择。InnoDB对于95%以上的用户来说都是最佳选择，所以其他存储引擎只是让事情变得复杂难搞，当然也不可夫人某些情况下某些存储引擎能更好地满足需求。
Oracel一开始收购了InnoDB，之后又收购了MySQL，在同一屋檐下对于两者都是有利的。InnoDB和MySQL服务器之间可以更快地协同发展。MySQL依然基于GPL协议开放全部源代码，社区和客户都可以获得坚固而稳定的数据库，MySQL正在变得越来越可扩展和有用。
第2章：MySQL基准测试
每个MySQL的使用者都应该了解一些基准测试的知识。基准测试不仅仅是用来解决业务问题的一种实践行动，也是一种很好的学习方法。学习如何将问题分解成可以通过基准测试来获得答案的方法，就和在数学课上从文字题目中推导出方程式一样。首先正确地描述问题，之后选择合适的基准测试来回答问题，设置基准测试的持续时间和参数，运行测试，收集数据，分析结果数据，这一系列的训练可以帮助你成为更好地MySQL用户。
如果你还没有做过基准测试，那么建议至少要熟悉sysbench。可以先学习如何使用oltp和fileio测试。oltp基准测试可以很方便地比较不同系统的性能。另一方面，文件系统和磁盘基准测试，则可以在系统出现问题时有效地诊断和隔离异常的组件。
如果经常执行基准测试，那么制定一些原则是很有必要的。选择一些合适的测试工具并深入学习。可以建立一个脚本库，用于配置基准测试，收集测试结果。
第3章：服务器性能剖析
本章给出了一些基本的思路和技术，有助于你成功地进行性能优化。正确地思维方式是开启系统的全部潜力和应用本书其他章节提供的知识的关键。下面是我们试图演示的一些基本知识点：
1）.我们认为定义性能最有效的方法时响应时间。
2）.如果无法测量就无法有效的优化，所以性能优化工作需要基于高质量、全方位及完整的响应时间测量。
3）.测量的最佳开始点是应用程序，而不是数据库。即使问题出在底层的数据库，借助良好的测量也可以容易的发现问题。
4）.大多数系统无法完整地测量，测量有时候也会有错误的结果。但也可以想办法绕过一些限制，并得到好的结果（但是要能意识到所使用的方法的缺陷和不确定性在哪里）。
5）.完整的测量会产生大量需要分析的数据，所以需要用到剖析器。这是最佳的工具，可以帮助将重要的问题冒泡到前面，这样就可以决定从哪里开始分析会比较好。
6）.剖析报告是一种汇总信息，掩盖和丢弃了太多细节。而且它不会告诉你缺少了什么，所以完全依赖剖析报告也是不明智的。
7）.有两种消耗时间的操作：工作和等待。大多数剖析器只能测量因为工作而消耗的时间，所以等待分析有时候是很有用的补充，尤其是当CPU利用率很低但工作却一直无法完成的时候。
8）.优化和提升是两回事。当继续提升的成本超过收益的时候，应当停止优化。
9）.注意你的直觉，但应该只根据直觉来指导解决问题的思路，而不是用于确定系统的问题。决策应当尽量基于数据而不是感觉。
总体来说，我们认为解决问题的方法，首先是要澄清问题，然后选择合适的技术来解答这些问题。如果你想尝试提升服务器的总体性能，那么一个比较好的起点是将所有查询记录到日志中，然后利用pt-query-digest工具生成系统级别的剖析报告。如果是要追查某些性能低下的查询，记录和剖析的方法也会有帮助。可以把精力放在寻找那些消耗时间最多的、导致了糟糕的用户体验的，或者那些高度变化的，抑或有奇怪的响应时间直方图的查询。当找到了这些“坏”查询时，要钻取pt-query-digest报告中包含的该查询的详细信息，或者使用show profile及其他诸如explain这样的工具。
如果找不到这些查询性能低下的原因，那么也可能是遇到了服务器级别的性能问题。这时，可以较高精度测量和绘制服务器状态计数器的细节信息。如果通过这样的分析重现了问题，则应该通过同样的数据来指定一个可靠的触发条件，来收集更多的诊断数据。多花费一点时间来确定可靠的触发条件，尽量避免漏检或误报。如果已经可以捕捉故障活动期间的数据，但还是无法找到其根本原因，则要么尝试捕获更多的数据，要么尝试寻求帮助。