又见涂抹（推荐序）
去IOE,闹着玩的？
“谁是谁的谁”，一首唯美中透着幽怨的歌，却会莫名地电到心中的累。学习太累，工作太累，生活太累，连歌名听着都那么累。
曾经的《涂抹Oracle》，从策划，到上市，到畅销，到经典，实现了一个个不敢梦的梦想。正如一句歌词唱的：你看窗外花开那么美。
但不幸的是，武林盟主阿里系带头发起了“去IOE”运动（IBM，Oracle，EMC）。为毛去IOE? 都是金钱惹的祸，用不起啊用不起。连盟主阿里都快用不起了，江湖又如何？
所以搞数据库的大牛小虾不免心有戚戚，一颗红心，两手准备吧，早做打算为妙。
谁来接班？
所以，你得清楚了解阿里去了Oracle想让谁接班。
没错，就是MySQL！
但樱桃好吃树难栽，由Oracle转战MySQl, 不是开车变换一条车道那么简单。这个你懂，我懂，天下人都懂，当然，经历了从Oracel车道往MySQL车道变换的三思更懂。
扫地僧
提起三思，真是小孩没娘，说来话长，请允许我再说一遍吧，保证长话短说。
孔老二有个观点,“知之者不如好知者，好知者不如乐知者”，意即“乐知是学习的最高境界”。我虽对老二的多数观点深恶痛绝，但对这一点却是深以为然。
某年某月某一天。
本人在ITPUB闲逛，偶然看到某标有“专家”字样的数据库类技术博客，衰名“君三思”。他的签名也引用了孔老二的这句话，觉得是个同道中人，不免在人群中多看了他几眼，却又瞥见了一句说明：我就是那个无名的扫地僧——手里的扫把。正是这句话，勾搭的我闯进了他的博客。
随便点开一篇名为《小记pub08年会三两事之三、打扑克~~~》（链接见http://space.itpub.net/ 7607759/viewspace-151194）的博文。我承认，虽未见其人，但一个洒脱、机智、幽默、才华横溢或许还有些坏坏的君三思已经活脱脱浮现于脑海。我开始浏览他的其他博文，基本都是Ｏracle学习笔记的系列博文，我带着些许的遗憾随便点阅了一篇，情不自禁的又点了一篇，又一篇……遗憾之感早已不翼而飞。他哪里只是一只扫把，其思想、其笔锋、其幽默、其技术、其功力，分明已至神光内敛返璞归真之境，他分明就是寺中的那个无名的扫地老僧。一种强烈的预感，这也许就是我要找的Oracle神灯吧。
Email，打电话，吃饭，约稿……
总之，我是死乞白赖地认识了君三思。也就有了曾经那本让读者大呼过瘾的《涂抹Oracle》。
而不久以后，三思开始玩MySQL了，到底是不是因为去IOE的运动，我就不清楚了。
涂抹
精彩就像天边的彩虹，所以，有时候形容精彩不免想用“抹”。我审阅稿子时，喜欢记录书稿中每一抹精彩。
初看到三思给我的第一本Oracle书稿时，我震惊于连“Oracle发展历史”这样的白开水内容，在三思的笔下都那么的精彩和酣畅（网上可见试读样章），更震惊于Oracle在Windows环境下和Linux环境下的安装与配置这样白开水般的内容在三思笔下竟然那么的具有深度，而三思对于RMAN、DG、FLASHBACK、SQL*LOADER、加载、备份恢复、迁移、体系结构等相关知识的研究和理解是如此的深刻，其表达又能如此的简单、风趣而幽默。书中的精彩，记下一抹又一抹，右手麻木的时候，我发现原来我基本上是在抄书稿。所以不得不放弃记录。当时，我突然想到，既然精彩已不可数，索性就把书名定为“涂抹”吧，以表达我审阅此书的心情。
所以，还是涂抹
三思从Oracle转战MySQL，转眼几年已经过去。
这本MySQL的稿子也已经交来三月有余。三思告诉我，这不是一本逐个介绍MySQL命令的书，不是讲完这个功能讲那个功能的书，更不是一本用户手册。叫个什么名好呢？
我一点都不担心为这本书起名字的问题，我最担心的，倒是三思的这本MySQL能否超越他的上一本Oralce，或者至少可以一样精彩。
但阅读完这本MySQL的稿子，才发现，我的担心是多么的多余。但我却无法为此书起一个更恰当的名字，只好还是叫《涂抹MySQL》吧，见谅，见谅。
轮扁斫轮（自序）
这些年一直坚持在博客上发表系列文章，也出版过技术方面的书，在业内积累了那么一点点知名度，就有很多朋友慕名而来跟我交流，要向我请教技术上的问题，咨询学习的技巧，让我推荐阅读的图书等。朋友们的热情让我感到很是忐忑，我虽然写过一些文章，但都是些通俗的东西，其实没什么学问，而且老实讲，有些朋友提出的问题真是不容易回答，比如有朋友上来就问我怎么优化数据库（这类问题恰恰是最多的），也有人问我看什么书能达到我现在的水平等等。
我知道这其中有些人确实是喜欢并且希望从事DBA这个职业的，他们当前只是没有经验才显得迷茫，其实我也是从这个阶段走过来的。多年以前我曾写过一篇文章《我想对初学Oracle的朋友说》（http://www.5ienet.com/note/html/stdstep/how-to-learn-in-oracle.shtml），其中的内容也是我有感而发。因为了解DBA成长道路上的艰辛，我不愿意随口敷衍他们几句，使他们走了弯路。可是因为自己的水平有限，我又难以简单几句话就说明白，有时候拉拉扯扯说了一堆，反倒是提问者自己不耐烦，甚至还有朋友直接了当地指责我不愿意分享（这个杀伤力太大，我的文章都白写了吗），整的我的心里也很受伤，对于这样的人，我当机立断大喝一声：“你是猴子搬来的救兵吗？”。不过我知道，多数人还是希望通过不断学习获得提高，看到他们就像看到曾经的我，我真心想帮助这些朋友。
说起读书和学习，国内外不少前辈先贤都有论述的文章，先我们耳熟能详的：“学而不思则罔，思而不学则殆；知之为知之，不知为不知……”等出自《论语》的至理名言就已流传千古，我一个刚及而立的后学晚辈，竟然也敢以《论》起谈，岂不是在自暴已丑，是要叫人笑掉大牙的嘛。但是我想，圣贤们的文章高瞻远瞩，高屋建瓴，高处不胜寒哪，以至于应者寥寥，我基于自身实力水平，也想借这个场合，站在稍低一层的层次，谈一谈这些年我学习过程中的一些感受。
先从一个典故开始吧。
春秋五霸之一的齐桓公，一次在堂上读书，堂下一名叫轮扁的技工师傅看到了，就放下手上的工作，走到堂上问桓公：“请问桓公在看什么书？”
齐桓公回答他说：“这是圣人的书。”
轮扁接着问：“圣人在哪呢？”
齐桓公回答：“圣人已经死了！”
轮扁说道：“那桓公所读的，不过是古人留下来的糟粕罢了。”
齐桓公闻之怒道：“寡人读书，岂是你这个做车轮的工匠可以议论的吗，今天你要是能说出道理还则罢了，要是说不出来，明年的今天就是你的忌日（好吧，我承认武侠片看多了，这台词管不住自己都往外蹦）。”
轮扁于是说道：“我是通过我平常工作观察到的情况来理解的，给车做轱辘虽然不是高级岗位，但也是个技术工种。在做车轮的时候，如果轮孔弄的太宽，那么虽然车轮能做的很光滑但用起来并不牢固，如果轮孔弄的过紧，车轮又会很粗糙难以装配；因此只有得心应手，不紧不松才能做出高端大气上档次的车轮。可是要如何做到得心应手呢，我做轮子的时候知道存在这样一种境界，但用嘴又说不清楚，我甚至都没办法将这点技巧传授给我的儿子，我的儿子也没办法从我这儿学到这一点，所以虽然我都七十多了还得在这儿做轮子。因此我想说的是，古人和他们那些不能言传的东西想必也早一起都死去了，所以桓公所读的，不过是古人留下来的糟粕而已！”
文中没有写明轮扁老师傅结局如何，但是想来老人家还是有极大的几率继续给桓公做车轮子的，轮扁（当然其实是庄子老人家借轮扁的口）讲的很有道理，找个熟练工不容易啊。
读到这里，我估摸着有些朋友已经在暗自嘀咕：看我这意思，似乎是在宣扬读书无用论了哟，出版社负责审校的同学，恐怕也已准备着把我这段序文删掉。都别着急，毛主席一直教导我们，要用辩证的眼光看待问题。古人说的不一定都对，我觉着问题的关键不在于看还是不看书，关键点首先是所阅读的图书质量，作者有没有把要表达的意思阐述清楚，其次是读者们有没有认真阅读，独立思考，真正领会作者想要表达的思想。
尽管时下写文字有种种限制，但是得益于近些年出版行业发达，现如今世面上讲经验、谈技巧、摆案例类的图书纷杂涌现，对于IT技术领域这类图书就更多了（因为IT行业本就是门实践性很强的技术）。在书中应对案例中出现的故障，作者们自己往往驾轻就熟，挥洒之间数千字，似乎也讲的透彻，但是初学者朋友可能看的云里雾里似懂非懂而不自知。仿佛学到了什么，但真正应对故障时却手忙脚乱，场景稍有变化甚至都不知道从何处着手处理。这种情况若对应到《轮扁斫轮》这则典故，说明操作者还没有达到“不徐不疾，得之于手而应于心”的境界。
读者朋友们认真看过书中的内容，可是实际工作中却不能很好的应用，这究竟是什么缘故呢，我想大概就是前面所说的两点关键因素，详细说来如下：
其一：可能作者没有（想或不想）把真正的精髓写出来。目前比较畅销的IT图书，其作者大都是来自一线的工程师，随着这些年图书出版门槛的降低，很多人有机会能将自己工作学习过程中积累的经验写出来（我认为这也是国内IT图书中少见思想类图书的原因）。优秀的IT工程师都是出色的实践者，他们技术掌握的比较扎实，接触面广，经验丰富，当遇到问题时，处理的方法往往都是下意识的选择，没有为什么，就是要这么做。在写作的时候也是下意识就将过程写了出来，而没能把思路阐释清楚。
其二：并非书写的不好，可能由于读者自身层次的原因，没能正确理解作者表达的精髓。对于读者来说，找到一本好书难，读透一本好书更难。过去有一种说法叫做：“书读百遍，其意自现”，我觉着这点在IT技术领域的局限是很大的，虽然任谁也不能否认阅读的作用是巨大的，可是，正如我前面谈到的，IT行业是一门实践性非常强的技术，按照过去的老话讲，IT工程师也是个手艺人。因为行业的特点，看的懂和做的到是两码事，尽管每读一遍都会有新的理解，但是这种理解必须要与实践相结合才能发挥最大的威力。
对此，庄子老人家其实也早已高度抽象地概括为：视而可见者，形与色也；听而可闻者，名与声也。世人以形色名声为足以得彼之情。夫形色名声，果不足以得彼之情，则知者不言，言者不知，而世岂识之哉！要想学的好，首先所读的书必须拥有比较高的质量，其次学习也必须能学到书中的精华，所以您瞧，有多种因素可能会给学习的质量造成干扰。再举这样一个案例，DB管理的系统出现响应慢的情况，通过分析发现是由于之前执行的某项操作，正是该操作占用了过多的资源才导致系统响应变慢，针对这种情况怎么处理呢。一定有些资料中提到，要杀掉占用过多资源的进程，以释放资源，提高系统的响应效率，并且有实际的案例佐证此方案的有效。于是在这个场景中，DBA为了缓解系统负载压力，利用之前看过的材料中提到的方法，手动杀掉了持有该操作的进程。
若仅把所执行的操作为独立个体来看，这当然是个很好的案例，有可能系统负载立刻就得到了明显下降，但问题有没有得到真正解决呢？深层次的根源究竟又是什么呢？如果没有弄清楚这些情况，那么所做的操作有可能不起效果（这就算好消息了），甚至有可能充满了风险。因为不是所有占用较多资源的进程都是不正常的，也不是所有进程都能随便中止，不管遇到的是什么问题，能找出造成问题的关键所在最重要。元芳，你怎么看！
不管要学习哪方面的知识，在学习过程中可参考的资料会有很多，在互联网时代更是可以用浩瀚来形容，这种现状换个角度看反倒更令读者们无所适从，不知道该选择看哪些资料好。若让我来选择，首要推荐的仍然是官方提供的技术文档，对于Oralce数据库可以到tahiti.oracle.com 浏览，对于MySQL数据库可以到dev.mysql.com/doc 浏览，官方文档始终都是内容最权威、最全面的学习资料，恒久远永流传。对于有一定经验的朋友，可能会认为官方文档的深度不够，案例也少，对于这部分朋友，可以去看一些专门的文章和图书，在选择图书时只有一个准则，就是要读有口碑的书。目前各大网络商城都有评分和评论系统，购买前先看一下其他用户的意见作为参考会很有帮助。
我读过的很多图书，文章开篇总要吹些牛皮，吸引读者的眼球，把读者的胃口调起来，希望大家能有兴趣接着往后看（欢迎对号入座）。像三思这种开篇不仅自我贬低，且一枪打击一大片的，怕着实不多见，我想这跟我的性格有关——耿直（好吧！我承认其实是情商低），也跟我所从事的职业有关——技术，来不得半点儿虚假。
好了，讲到这里，是时候跟大家介绍下本书的内容了（分明是要开始王婆卖瓜自卖自夸），这并不是一本逐个介绍MySQL 命令的书，不是一本用户帮助手册，不是这个功能讲完讲那个功能的书。在写作之初我就考虑要设定一条主线，不是依次讲特性，而是依据用户接触和学习MySQL 的脉络去把握，介绍MySQL数据库从无到有，其安装、配置、管理、优化的过程，在这个过程中再穿插数据导入导出、性能/状态监控、备份恢复和优化方面的内容，最后再谈一谈MySQL数据库服务从单台到多台，从单实例到多实例集群的部署等稍显高阶的应用方案。
说起来，这其实是一本站在初学者的视角，描述他不断学习和提高的路径的图书，在这个过程中，我当然不可能面面俱到地讲到所有的技术特性，不过在介绍某些知识点时，会有意地忽略一些细节，是希望能让读者有思考的空间，既能看到优势同时也学会看到不足，找出更适合自己的解决方案，逐渐形成自己的操作思路，窥见“不徐不疾，得之于手而应于心”的境界。
最后，我想说的是，官方文档也好，技术图书也好，这些都是外在因素，最重要的因素仍然是自己，是否真正喜欢所要学习的技术，是否确实愿意花费时间和精力去深入研究，是否能够承受枯燥的应用和测试。只要打好了基础，看多了案例，精通了技能，学好了本领，明了方方面面前因后果，用不了多久，就可以成为大拿，升职加薪，当上技术总监，出任CTO，迎娶白富美，登上人生顶峰！是不是想想都激动啊！小伙伴儿们，那就从现在开始吧，翻开第一页，MySQL 在向你招手。
