1、有读者问，文中所说的MySQL 5.1是目前最流行的版本……，认为不确切。
答：包括我在内的许多DBA偏保守，我个人认为一个新版本至少要等2～3年才能趋向于成熟，因为新版本没有经历过大规模的生产环境验证，刚开始发布后的一两年内往往需要修复大量的bug，可能要等到5.x.2x以后才能试用。写书的时候我认为MySQL 5.5是成熟的，但是我认为MySQL 5.5只是一个过渡的版本。对于读者来说，可以直接从MySQL 5.6开始学习，书中的思路、方法一般适用于所有版本。
2、我对书的质量问题也没有办法，虽然希望每本书印刷出来都是完美的。也许书的批量印刷难免存在质量问题，JD上已经看到几个评论说书的质量问题，谢谢读者朋友们仍然给予好评 🙂 。
本书主要讲述MySQL DBA的必备技能，包括MySQL的安装部署、开发、测试、监控和运维，此外，读者还可从中学习到系统架构的一些知识。[……]
书名是《MySQL DBA修炼之道》，京东、天猫都有预售。2月底到货。
身心两累，杂事太多，回到长沙后，老是和时间作斗争，时间的利用效率也是个问题，这是我所料未及的。比较欣慰的是，还是咬牙完成了书的初稿和校阅。
微信很久没开，从邮件中老同事口中，得知自己的书出版了，还是有一些小惊喜。
1、书写的时间跨度很长，3、4年吧。当然花的时间远远没有那么多，初稿部分完成于广州大学城的一些教室内，那里真的是一个写书的好地方。长沙期间，主要后面一些章节以及校阅。搜了下，有位同学写的《MySQL DBA管理之道》应该是同期写的，14年就出书了，16年出第二版了，惭愧。
2、写书的时候，没有去参考其他人写过的书，刚才去大概搜了下其他人写的书，看来我写的是难度大的一种，我认为没有什么用的或者我不常用内容，我一般都不写，每个人的侧重点不同，也许有的读者喜欢大而全的，我更多是当作一种传道授业、同行交流，有些内容确实没有太大兴趣去叙述。但为了内容完整，还是想面面俱到介绍一些知识，比如开发的一些内容，函数、存储过程啥的，我是硬着头皮写，只能摘录官方文档了，可是悲剧的是，官方中文文档的翻译质量太差了，我自己看得都不满意，死了好多脑细胞，对照英文调整了一些，还是不太满意，标点符号也头痛，不过我相信这部分内容，读者可以自己多看看官方英文文档，反而更好。对于新特性，新版本，我相信一个求知欲旺盛的DBA会很主动的去尝试，测试验证各种新特性的，也许我都没有他们熟悉，我还是不写的好。初学习的人，往往是很看重新版本的，听说是MySQL 5.1，也许掉头就走也说不定，就和我以前学习编程一样，可是现实的情况是，你掌握好了基本的架构和理念，新版本的学习没有多大难度，而且市面上也有足够的资料、书供参考。
3、既然难度大，所以我尽量使用很简单的语言，可是，编辑第一次让我校阅，很吃惊，太多内容要修改了，做了许多年技术工作，语文退化了。读者可能有时看不懂一些章节，这也是正常的，因为确实里面包含了自己许多年的经验，不是一下子可以说透，我也没有这个能力，我已经尽力去分享了，我相信5年以上经验的人，会有更多的体会。这本书是一本入门的书，也不太像一本入门的书，因为许多内容远远超过了市面上的一些“从入门到精通”的书，部分内容又过于简单，希望读者能够从中找到自己想要的东西；
4、以前写的东西，随着时间增长，会觉得需要补充完善一些内容，可是自己又没有足够心力去好好修改，所以我还是有一些愧疚，希望读者不要介意。这本书的目的是引人入行，让人少走弯路，但其实许多技术细节并没有写，所以读者是需要在阅读书的过程中，尽量把官方文档看一遍的，我更多是点一些要点或者需要的知识而已；
5、写书更多是为了交流，自己写书，就知道写书有多难，如果没有一颗交流的心，一种信念支持，是很难坚持下去的，以后我再看翻译的书，估计不会对翻译太过苛责了。国内各大互联网公司有一批高素质的MySQL DBA的，可是因为很简单的 投入产出比的考量， 很难有人愿意好好写一本书，这个现状可能长期保持下去，希望后续有更多的DBA，特别是BAT的DBA们，多写写MySQL的书。因为时间精力，也许以后多人共同写作一本书会是一种趋势，我刚买了一本《失控》 就是在线协作的方式出版的。
6、书中摘录了些其他书（人）的作品， 主要是阿里同学胡中泉的EXPLAIN的PPT。本来我的正文有说明，也许编辑觉得正文里很突兀，校订的时候并没有通知我做了改动，在这里表示歉意。
7、以前以为编辑也是用word，现在才知道，他们是看纸稿的，编辑校对的工作量也很大的，所以一个人如果要写书，一定要把编辑的辛苦考虑周到，自己尽量精益求精，编辑和作者的沟通对于书的出版很重要。
8、希望尽快补上一些代码的下载。 不过，我即使不提供源码的下载，也不影响书的阅读，书里面大部分是一些很简单的SQL。 相信看书的人自己就可以 克服。 唯一需要给的一个参考，应该是MySQL的测试脚本。
元宵佳节，草草写完上述话，希望早日看到自己的书。
1、现在很难抽出时间来写博客，db110已经写了许多年，数据库的技术也已经很成熟了，也不需要我在博客里一直强调。也许是时间，慢慢放弃博客写作，或者减少更新的频率了。
2、最近几年，已经很少研究新的技术了，一方面是旧有的技术已经够用，一方面是自己的研究方向也有变化了。
3、未来会花更多时间在其他的领域，人应该不断接受新的挑战才是。
4、知乎里，facebook，linkedin，google+里都发了一些文章，其实都可以集中到自己的博客上来。简单更好。
1、这本书值得推荐看，也许因为作者行文还不够有趣，我只看了一遍，但知识含量是足的，Kindle上我也做了不少笔记。
2、今天把它加入了参考书目，毕竟我摘录了一些内容。
3、到网上搜了下，竟然2015年10月就有人翻译出来了。这样的书，一个人是很难以翻译出来的，毕竟都是些有工作的人。Amazon上的评论大概看了下，说有部分错误，但是翻译这么一本书，错误还真难免。你说要用心把，说句实话，作者/译者得到的回报可能很难以让人有毅力花费大量时间仔细校对。这个世界上，对于读者和作者都不要太苛求，无论在哪里，写书或者翻译书，更多是交流的手段而不是赚钱的方式，，错误是难免的，理解对了就好。
MySQL DBA的职责
我列举一些DBA的工作职责，
维护线上数据库，保障安全、可靠、高性能。
部署上线新的业务的数据库
性能调优以及扩容计划
培训研发、测试团队
故障处理以及恢复数据
协助日常业务升级，升级数据库
升级MySQL版本
研究新技术、产品，评估新技术、产品
审核研发人员的数据库表设计，必要的时候参与数据库表设计
建设数据库的运维平台，自动化或者半自动化工作
我们推荐在Linux下使用XFS文件系统，它是一种高性能的日志文件系统，特别擅长处理大文件，对比ext3、ext4，MySQL在XFS上一般有更好的性能，更高的吞吐。Red Hat Enterprise Linux 7默认使用XFS文件系统。Red Hat Enterprise Linux 5、6的内核完整支持XFS，但未包含创建和使用XFS的命令行工具，你需要自行安装。
如下是一个安装示例
下载xfsprogs包，并解压
./configure
make
make instal
which mkfs.xfs 确认已经安装好了创建xfs文件系统的命令。
安装了xfs后，我们就可以使用mkfs.xfs创建xfs文件系统,如下面的命令在/dev/sdb1上创建xfs文件系统
mkfs.xfs -f -d agcount=6 -l size=64m -i size=512 -L /home1 /dev/sdb1
部分参数解释：
-f 强制创建文件系统,即使已经存在旧的文件系统
-d选项。主要用于数据部份的参数指定。例如在一个raid设备中如何进行分配。
agcount 分配组的数量，XFS文件系统内部被分为多个“分配组”。 每个分配组各自管理自己的inode和剩余空间。可以设置为4、6、8等较小的值。
如果在raid阵列上创建xfs文件系统，你需要留意su、sw这两个参数的设置。你要根据RAID配置来设置这两个参数，su=value 可设置为raid的条带大小，sw=value 设置为独立的设备大小, 比如对于raid1+0 独立的设备为总的磁盘数量除以2 , 对于raid5，独立设备数为总的磁盘数量减1。如，-d su=128k,sw=3 。
pt-query-digest是最应该掌握的一个工具。它可以分析MySQL的各种日志，如慢查询日志、generel日志，也可以分析show processlist的输出。配合tcpdump我们还可以对线上数据库流量进行采样，实时监控数据库流量，及时发现性能问题。
基本用法如下，
pt-query-digest /path/to/slow.log > /path/to/keep/report_file
如果你有大量的数据库节点，可以考虑把pt-query-digest的分析报告写入数据库，方便检索和绘图。
输出的报表类似如下，以下截取了报告的部分内容，
# Overall: 565 total, 22 unique, 0.00 QPS, 0.00x concurrency _____________
# Time range: 2012-09-22 18:33:43 to 2012-10-16 10:45:31
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 1233s 503ms 15s 2s 7s 2s 1s
# Lock time 53ms 31us 145us 94us 119us 17us 93us
# Rows sent 1.67k 0 20 3.02 9.83 4.12 0.99
# Rows examine 616.77M 72.90k 12.03M 1.09M 6.61M 2.02M 245.21k
# Query size 139.49k 25 381 252.81 346.17 70.94 234.30
# Profile
# Rank Query ID Response time Calls R/Call Apdx V/M Item
# ==== ================== ============== ===== ======= ==== ===== ========
# 1 0xBE5D289C750F172A 308.6929 25.0% 40 7.7173 0.00 0.08 SELECT ccc tbl_eee tbl_ddd bbb
# 2 0x5C898C5E065DD204 149.4144 12.1% 105 1.4230 0.50 0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd
# 3 0x6F05415421300718 136.7381 11.1% 97 1.4097 0.50 0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd
# 4 0x2E9AE41A4D2149A1 123.0681 10.0% 22 5.5940 0.00 0.02 SELECT ccc tbl_eee tbl_ddd bbb
# 5 0xAFF556BC27138443 121.9603 9.9% 73 1.6707 0.50 0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd
# 6 0xD07F224EF598BD9A 105.0456 8.5% 16 6.5653 0.00 0.23 SELECT ccc tbl_eee tbl_ddd bbb
# 7 0xC22F9709F846BB4E 99.1936 8.0% 73 1.3588 0.50 0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd
# 8 0x4CAD792BF4A54CE9 53.7477 4.4% 4 13.4369 0.00 0.17 SELECT tbl_fff tbl_eee tbl_ddd
# 9 0x347319A37AC29893 39.1390 3.2% 69 0.5672 1.00 0.00 SELECT tbl_fff pt_game_base_score
# 10 0x7EF77B274F1C37D3 27.2826 2.2% 4 6.8207 0.00 0.00 SELECT ccc tbl_eee tbl_ddd bbb
# 11 0x8383B2CB219358F3 16.7553 1.4% 18 0.9308 0.97 0.00 SELECT tbl_iii tbl_hhh tbl_eee
# MISC 0xMISC 51.5793 4.2% 44 1.1723 NS 0.0 <11 ITEMS>
# Query 1: 0.00 QPS, 0.00x concurrency, ID 0xBE5D289C750F172A at byte 120071
# This item is included in the report because it matches –limit.
# Scores: Apdex = 0.00 [1.0]*, V/M = 0.08
# Query_time sparkline: | ^_|
# Time range: 2012-09-25 11:01:09 to 2012-10-16 10:14:31
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 7 40
# Exec time 25 309s 7s 10s 8s 9s 802ms 7s
# Lock time 6 4ms 59us 110us 89us 103us [……]
阿姆达尔定律是一个计算机科学界的经验法则，因IBM公司计算机架构师吉恩·阿姆达尔而得名。吉恩·阿姆达尔在1967年发表的论文中提出了这个重要定律。
阿姆达尔定律主要用于发现仅仅系统的部分得到改进，整体系统可以得到的最大期望改进。它经常用于并行计算领域，用来预测适用多个处理器时理论上的最大加速比。在我们的性能调优领域，我们利用此定律有助于我们解决或者缓解性能瓶颈问题。
阿姆达尔定律的模型阐释了我们现实生产中串行资源争用时候的现象。如下图模型，一个系统中，不可避免有一些资源必须串行访问，这限制了我们的加速比，即使我们增加了并发数（横轴），但取得效果并不理想，难以获得线性扩展能力(图中直线)。
以下介绍中、系统、算法、程序可以认为都是优化的对象，我不加以区分，它们都有串行的部分和可以并行的部分。
在并行计算中，使用多个处理器的程序的加速比受限制于程序串行部分的执行时间。例如，如果一个程序使用一个CPU核执行需要20小时，其中部分代码只能串行，需要执行1个小时，其他19小时的代码执行可以并行，那么，不考虑有多少CPU可用来并行执行程序，最小执行时间不会小于1小时（串行工作的部分），因此加速比被限制为最多20倍（20/1）。
加速比越高，证明优化效果越明显。
阿姆达尔定律可以用如下公式表示：
s( n ) 固定负载下，理论上的加速比。
B 串行工作部分所占比例，取值0～1，
n 并行线程数、并行处理节点个数
以上公式说明：
加速比=没有改进前的算法耗时/改进后的算法耗时。
如果我们假定算法没有改进之前，执行总时间是1（假定为1个单元）。那么改进后的算法，其时间应该是串行工作部分的耗时（B）加上并行部分的耗时(1-B)/n，由于并行部分可以在多个cpu核上执行，所以并行部分实际的执行时间是(1-B)/n
根据这个公式，如果并行线程数（我们可以理解为CPU处理器数量）趋于无穷，那么加速比与系统的串行工作部分的比例成反比，如果系统中有50%的代码串行执行，那么系统的最大加速比为2。也就是说，为了提高系统的速度，仅增加CPU处理器的数量不一定能起到有效的作用，需要提高系统内可并行化的模块比重，在此基础上合理增加并行处理器数量，才能以最小的投入得到最大的加速比。
我们对阿姆达尔定律做进一步说明。阿姆达尔这个模型 定义了固定负载下，某个算法的并行实现相对串行实现的加速比。例如，某个算法有12%的操作是可以并行执行的，而剩下的88%的操作不能并行，那么阿姆达尔定律声明，最大加速比是1（1-0.12）=1.136。如上公式n趋向于无穷大，那么加速比S=1/B=1/（1-0.12）。
再例如，对于某个算法，可以并行的比例是P，这部分并行的代码能够加速s倍（s可以理解是CPU核的个数，即新代码的执行时间为原来执行时间的1/s）。此算法30%的代码可以被并行加速，那么P等于0.3，这部分代码可以被加速2倍，s等于2。那么，使用阿姆达尔定律计算其整个算法的加速比：
以上公式和前一个公式类似，只是前一个公式的分母用串行比例B来表示。
再例如，某项任务，我们可以分解为4个步骤，P1、P2、P3、P4，执行耗时占总耗时百分比分别是11%、18%、23%、48%。我们对它进行优化，P1不能优化，P2可以加速5倍，P3可以加速20倍，P4可以加速1.6倍。那么改进后的执行时间是：
总的加速比是 1 / 0.4575 = 2.186 。我们可以看到，虽然有些部分加速比有20倍，5倍，但总的加速比并不高，略大于2，因为占时间比例最大的P4部分仅仅加速了1.6倍。
对于如下的图，我们可以观察到，加速比受限制于串行工作部分的比例，当95%的代码都可以进行并行优化时，理论的最大大加速比会更高，但最高不会超过20倍。
阿姆达尔定律也用于指导CPU的可扩展设计。CPU的发展有两个方向，更快的CPU或者更多的核。目前看来发展的重心偏向了CPU的核数，随着技术的不断发展，CPU的核数不断增加，目前我们的数据库服务器四核、六核已经比较常见，但有时我们会发现虽然拥有更多的核，当我们同时运行几个程序时，只有少数几个线程处于工作中，其它的并未做什么工作，实践当中，并行运行多个线程往往并不能显著提升性能，程序往往并不能有效的利用多核。在多核处理器中加速比是衡量并行程序性能的一个重要参数，能否有效降低串行计算部分的比例和降低交互开销决定了能否充分发挥多核的性能，其中的关键在于：合理划分任务、减少核间通信。
如果你有.ibd文件的一个干净的备份，你可以按如下操作从被起源的地方恢复它到MySQL安装中：
2. ALTER TABLE tbl_name DISCARD TABLESPACE;
警告：这个语句删除当前.ibd文件。
5. ALTER TABLE tbl_name IMPORT TABLESPACE;
在上下文中，一个.ibd文件干净的备份意为：
ibd文件里没有尚未提交的事务做的修改。
.ibd文件里无未合并的插入混充条目。
净化已经从.ibd文件移除所有已标注删除的索引记录。
mysqld已经把.ibd文件的所有已修改页面从缓冲池刷新到文件。
你可以用下列方法生成一个.ibd文件的干净备份：
生成一个.ibd文件的干净复制的另一个方法是使用商业的InnoDB热备份工具：