前几天，受 Oracle 所遥，在 OOW 上的 OTN Lounge 分享了一下最近一年来在利用MySQL 在高可用可扩展架构方面的一些心得，这里贴上 PPT，供大家拍砖。内容方面，前面的部分可能有不少朋友以前有看到过，可能是听我介绍过，也有可能本身自己就对这些架构很了解。无所谓，只要能对一少部分人有用，那也欣慰。不过，最后两页 PPT 的内容，我想肯定没有人在其他渠道见过，因为这两张图片是我第一次在公开场合展示。废话少说，上 PPT 吧，呵呵！高可用可扩展数据层 – MySQL架构实践View morepresentationsfromSky Jian. ...继续阅读 (24)

今天，Oracle（甲骨文）公司的 Oracle Open World / Java One / Oracle Developer 北京大会今天开幕。大会从13号到16号，共4天，今天上午主要是大会注册时间。由于参会人员众多，Oracle 安排了半天时间用于参会者注册报道。我较早就到达了现场，看到为排队准备的临时隔离绳早已准备好，还有十多个安检通道。看这阵式，等下的注册场面一定很火爆。今年的大会上，OTN 组织了一次 Oracle ACE 大聚会（OTN Lounge），并有精彩演讲安排。我在里面也安排了一个主题演讲，安排在 15 号（周三）上午。此外还有 Oracle 数据库方面的很多专家如冯春培，盖国强，楼方鑫，张乐奕等，还包括阿里巴巴公司一位经常与我协作的高级 Java 工程师 贺贤懋。OTN Lounge 的具体日程安排如下： ...继续阅读 (20)

最近一直在测试一款让我非常兴奋的存储介质：Fusion IO的 ioDrive。他在随机小IO的方面的表现，实在是让我吃惊，可以轻松达到100k左右的单一读（或者写）（注意是写也可以达到这个数据） IOPS，读写混合也可以达到 50k～60k左右的IOPS，而且这个 IOPS 数据还是在响应时间低于5ms 的情况下的数据。而实际上，当 IOPS 达到50k 的时候，响应时间仍然低于1ms。注：测试工具为 orion/fio/iometer100K 的 IOPS 是一个什么概念？假如我们使用 15k 转速的 SAS 磁盘来对比，每块磁盘的 IOPS 大概 150 左右，那么一块 ioDrive 的 IOPS 表现就相当于 100k/150=666.66 块 15k 转速的 SAS 磁盘并行的能力，而且每个 IOPS 的响应时间还得 5～7ms（机械原理决定） 。这样的 IOPS 能力，恐怕也只有 EMC ， HDS 等高端存储厂商们的顶级存储设备才能够达到如此高的 IOPS 性能了。ioDrive 为啥能达到如此之高的 IOPS 而且还能保持极小的响应时间？SSD 设备Fusion IO 的 ioDrive 产品其本质就是当前存储界炒的非常热的 SSD ，而非传统的机械磁盘。但其他厂商的 SSD 磁盘的性能和 ioDrive 相比，实在是还有一段不小的差距，这是为什么？那就要看下面这 ...继续阅读 (15)

从 InnoDB 了解到，plugin 1.0.4 开始，提供了一个新的脏数据刷新机制，被称为： innodb_adaptive_flushing 。由于之前在各种性能测试以及线上环境的性能监控中时常遇到当 InnoDB 在进行大批量 Dirty Page 的 Flush 过程中，会对系统的整体性能造成不小的影响，所以个人对这个新机制比较感兴趣，仔细分析了下这个机制到底改善了些什么内容。一般来说，InnoDB 有两种情况会触发 Flush Dirty Page 的操作。如下：日志切换的时候当 InnoDB 的 redo log 进行切换重用其他某个日志的之前，被重用日志上的所有更改都必须全部记录进入数据文件，以确保主机在异常情况下 Crash 后不会造成数据丢失。这时候的 Flush 通常被称为 Flush_List Flush。申请空闲 Buffer 空间但是没有空余当我们请求某个 block 的时候，如果该 block 不在 buffer pool 中，我们就必须先将该 block 从磁盘文件中读入到 buffer pool 中。如果这时候我们的 buffer pool 中已经没有空余空间可以使用了，那 InnoDB 就会通过 LRU 机制，将某些 Dirty Page 写入数据文件以清理出需要的空闲空间。我们通常称这种 Flush 为 LRU_List Flush。通过测试， ...继续阅读 (26)

其实拿到博文视点赠送的这本《软件架构师应该知道的97件事》已经有一段时间了，可一直没有时间去读。在刚刚忙完一个大项目之后，又有数据库集群的架构需要调整。想想事情永远是做不完的，再忙也不能把给自己充电的事情落下。还好，这是一本不需要有大段连续时间来读的书，只要有一点点时间，就可以翻开书页学几件“应该知道”的事儿，哈哈。这本书最大的特点就是以小主题的方式来组织每一件“软件架构师应该知道”的事情，非常方便阅读。书中的内容，至少对于我个人来说，确实还是带来了不少启发。而且有不少理论，在我的并不太长的职业生涯中就已经有非常深的体会。比如：不存在放之四海皆准的解决方案任何解决方案起始都有其适用场景的提前关注性能问题性能问题的量变到质变过程经常会让人措手不及取舍的艺术不论是软件架构的选择还是生活中的大小事情的决策，都是在做取舍的平衡不要轻易放过不起眼的问题故障往往都是有一些不起眼的小问题引起，正因为他小，所以没有得到足够的关注，留下隐患控制项目规模项目越大，风险范围也就越大，不可控因素也会越多，由于项目规模控制不当而导致项目最终失败的案例数不胜数数据是核心界面不断的改版，图片不断的更换，架构不断的调整，唯有数据还是原来的数据起码有两个解决方案或许做运维的朋友对这一点更有体会：任何时候都要留一条后路现在走捷径，将来付利息从那些伤筋动骨的重构项目就可以看出我们为曾经的捷径付出了多少… & ...继续阅读 (27)

注：原文已发表于《程序员》杂志关系型数据库60周年特刊随着信息量飞涨，信息的存储成为了这个时代至关重要的一项技术。如何来保证数据存储技术能够适应信息量的增长速度和我们对信息的高度依赖，成为一个非常重要的课题。本文将从数据库架构的层面，通过以开源的数据存储软件来构建分布式数据层的思路，期望实现一个低成本的高可用可扩展的数据层架构。传统数据库架构纵观各传统商业数据库软件，多以集中式架构为主，鲜有以分布式为设计理念的架构。这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中，依靠大型高端设备来提供高处理能力和扩展性。集中式数据库架构在扩展性方面主要依赖于主机和存放数据的存储设备的扩展能力，也就是说依赖硬件本身的纵向扩展能力，很难做到较好的横向扩展。而其可靠性也同样是以硬件设备为依托，主要通过Share Storage的方式来实现。如大家所熟知的传统商业数据库代表厂商Oracle的RAC，就是一个非常典型的Share Everything 的集中式架构。我们可以通过图1来简单地描绘一下传统数据库的典型架构：传统架构在主机端大多通过两台主机共享存储设备，平时其中一台主机使用存储通过数据库软件来管理。这样的架构只能有一台主机（RAC除外）上的数据库能够提供服务，另一台主机只能是作为热备冗余，不能启动数据库实例提供服务。所以，其处理能力就完全取决于这台主机的最大扩展能力，很难通过增加 ...继续阅读 (11)

前段时间，在有幸被多人举荐并由 Oracle 公司的 Jack 提名后，被 Oracle 公司授予了Oracle ACE (Expertise: MySQL)称号。很多朋友听闻此事后都向我道贺，也有很多朋友提出疑问： Oracle ACE 到底为何物？Oracle ACE 程序主要是 Oracle 公司为了奖励使用推广Oracle公司某个领域产品的技术专家们所做的贡献而设立的一种荣誉机制。目前，除了通过业内知名人士举荐并由 Oracle 公司的人提名最终经过 ACE 程序审核小组评审之外，无法通过认证考试或者是其他途径获得。目前国内共有 16 位技术专家获此荣誉，分别分布在6个技术领域，如下：Database Management & Performance：5人Database App Development：5人Middleware & SOA：4人Applications & Apps Technology：1人MySQL：1人其中 MySQL 领域目前国内就我一个人（希望在未来能够有越来越多的战友们能够加入这个行列），全球也只有4位。能够获此殊荣，确实非常开心，这是对我个人在这个技术领域内的认可。当然，这也离不开我所在的公司为我提供的成长平台，离不开所在Team的各位同事给我的帮助。同时，也希望国内有更多的技术专家能够获得 ACE 称号。 ...继续阅读 (12)

为了对核心技术拥有更多的自主控制能力，为了解决数据库的线性扩展问题，为了尽量减少对商业软件的依赖，为了摆脱对高端硬件的依赖，为了… 基于以上多种原因，2年前，我们计划将公司某核心应用平台进行大手术：数据库平台从软件到硬件全部重构。当然，这其中应用架构的改造也不可避免的进行了大换血。这个项目无论是从技术角度还是是业务角度来说，都对我们有着非常大的价值，也必定会带来非常深远的影响。项目历时2年多，分4个阶段才完成：应用接口统一这一阶段主要是为了后面真正迁移的时候做准备工作，将该核心应用系统的所有数据访问入口统一到一起，全部以服务化的接口方式呈现给其他有需要的系统，一来方便后续变更的控制，二来也推进了服务化的进程。Oracle数据库中拆分（1拆16）这个阶段本不是必要的，但是由于项目启动稍微晚了点，数据出现了爆发性增长，导致该系统的数据表太大（单表不带索引过500GB），原 Oracle 数据库已经快撑不住了。为了安全起见，先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分，从1个表分拆成了16个。附表由于访问量稍小，而且全部是根据主键访问，暂时保留原样。当然，这样的水平拆分，必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并，数据库读写分离，数据库链接管理等功能的数据访问中间层，专门解决拆分后给应用服务器带 ...继续阅读 (5)

部门同事（MySQL DBA）一次关于 MySQL Explain 分享所使用的 PPT，写得很不错。本PPT版权所有：胡中泉MySQL ExplainView morepresentationsfromSky Jian. ...继续阅读 (20)

最近经常有人问我 MySQL Query Cache 相关的问题，就整理一点 MySQL Query Cache 的内容，以供参考。顾名思义，MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说，Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲，就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。在大部分的 MySQL 分发版本中，Query Cache 功能默认都是打开的，我们可以通过调整 MySQL Server 的参数选项打开该功能。主要由以下5个参数构成：query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cachequery_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数query_cache_type：控制 Query Cache 功能的 ...继续阅读 (10)

之前说起将参加2010 数据库技术大会，今天将这次参会使用的 PPT 贴出来，或许会对大家有点用。先大概介绍下大会的几本情况吧，满满2天的大会，共安排了 29 场演讲，内容涵盖了 Oracle，MySQL，DB2，SQL Server ，Sybase，达梦（国产数据库） 等多种数据库，演讲数量之多，主题内容之丰富，实数罕见，哈哈。演讲嘉宾的阵容也非常庞大，国内14个 ACE / ACE Director，其中9位到场演讲。各个主题内容的 PPT 可以到此处下载，这里我大概介绍下“高可用可扩展数据库架构” 这个话题吧：在主题中，我从数据库的高可用和可扩展两个方面来进行了分享探讨：高可用软/硬件高可用（热/冷备）数据高可用（共享，同/异步复制）单独的硬件高可用除了冗余之外本身没有太多可以讲的，所以一笔带过。基于共享设备的数据高可用只是大概的介绍了可能的方案，由于各方案的实施都比较昂贵，更适合于Oracle，DB2等，所以也没有深入探讨。所以，这部分重点介绍了一下利用 MySQL 的 Replication 技术和应用程序的共同配合来实现 Share Nothing 方式的高可用。可扩展向上扩展（Scale Up）硬件扩容（增加CPU数量，增加内存容量，增加磁盘数量…）硬件升级（更换更高端的主机，更换更高端的存储设备，更换更高端CPU，更换转速更快的磁盘…）向外扩 ...继续阅读 (10)

刚刚忙完了一个持续了近一年的核心数据库相关的项目，过几天将会去北京参加 IT168 举办的“2010数据库技术大会”（DTCC），并受邀有个小的主题交流分享（高可用可扩展数据层架构探讨）。这个小主题以 MySQL 数据库为主。当然，高可用可扩展的数据库架构层自然不可能离得开 Cache，所以也插入了部分 Cache 相关的内容，以及最后扩展出了少量全文检索也就是Search相关的内容，来构成 OLTP 类型应用的高可用可扩展数据库层架构。欢迎大家到时候一起探讨。当然，不便现场参加DTCC，我想在会后一段时间应该能够见到相关 PPT 吧:) ...继续阅读 (20)

很久没有在这里写点东西了，总感觉欠网友一点什么，不是不想写，实在是最近太忙了，实在没有精力顾上这里。最近做什么事情都不顺，项目的事情因为硬件的问题接连出了两次重大问题，光跟进解决这些问题就耗费了大量的时间。好几次回头审视整个项目过程中的几个主要环节，看自己是否出现过错误的选择，是否策略有误，是否设计的架构不够合理，是否…一转眼都到年底了，由于到了年终销售冲业绩的时候，系统不能有任何问题，项目也被迫只能推延至来年1月。也好，这样给我们整个项目组有了更多的时间整理问题，更多的时间准备新方案，更多的时间冷静思考过去…希望来年会有个好的开始，先祈祷了… ...继续阅读 (7)

受博文视点周筠老师所邀，为博文新书《我是一只IT小小鸟》（俗称“IT小小鸟”）写了篇从大学到现在的个人成长经历的文章。“IT小小鸟”全书由胡江堂/李成/唐雅薇/秦琴/蒋宇东/刘未鹏/居振梁/刘帅/温卫斌/张弦/张凯峰/庄表伟/宋劲杉/程露/黄小明/易晓东/林健/高昂/徐宥/辜新星/简朝阳共 21 位作者合作完成，已于上月初（2009-09-01）正式出版。“IT小小鸟”主要是介绍了各位作者的的成长学习经历，对IT从业的选择经历，在成长学习到路上所遇到的挫折，以及工作后的部分经历。希望通过各自一路走来的经历可以对各位即将进入大学或者是即将从大学毕业的学弟学妹们有那么一点点帮助。最近从周筠老师处得知，收到来不少自高校学生的反馈，反响很不错。如 东北师大的 王喆 在豆瓣上的书评：http://www.douban.com/review/2518322/，Ramiel 在个人Blog上的读后感想 http://hi.baidu.com/ramiel/blog/item/5181f638ffa7b8f8b311c7a9.html 等！甚至还有公司（兰亭集势）专门团够团购200本“IT小小鸟”，用于校园招聘。很欣慰自己的成长经历能够对各位后来者有所价值！附注：网上购买此书 请点这里 ...继续阅读 (10)

FromRyam：p26倒数第二行：原文：“逻辑层与存储引擎实现层的过度解偶”-> ：“逻辑层与存储引擎实现层的过度解耦”p82第9行：原文：“这样就省略了分页程序在分以前实时计算”-> ：“这样就省略了分页程序在分页前实时计算”p118第5行：原文：“如果系统须要有限保证”-> ：“如果系统须要优先保证”p123第1行：原文：“并不一定完全按照系数据库的元信息”-> ：“并不一定完全按照数据库的元信息”p85倒数第2行：原文：“然后再瓶装展现对象”-> ：“然后再拼装展现对象”p139第8行：原文：“那么将会存在大量记录指针信息存于同一Hash值相关联”-> ：“那么将会存在大量记录的指针信息与同一Hash值相关联”p142倒数第6行：原文：“当然，并不是存在更新的字段就适合创建索引”-> ：“当然，并不是存在更新的字段就不适合创建索引”p171第3行：原文：“但是当遇到一些自查询或较为复杂的join时”-> ：“但是当遇到一些子查询或较为复杂的join时”第11行：原文：“group_message_bad是优化前的表，优化后为group_message表），如示例代码9-1所示：…”-> ：这里的示例代码中group_message更换成group_message_badp194第3行原文：“这样不仅可以让变化频繁的Table的Query浪费Query Cache ...继续阅读 (12)

《MySQL性能调优与架构设计》从最开始网上书店上架（2009.06.11）到现在才35天时间，库存量就已经很少了。接到出版社通知，需要今天完成勘误信息的整理，马上出片进行第二次印刷了。这次印刷会订正掉目前位置已知的所有编写及出版过程中出现的错误信息，相信各方面品质都会比第一次印刷更好。非常感谢各位读者热心积极的反馈以及肯定，感谢各位朋友的支持，感谢博文视点出版社的大力帮助，谢谢大家了。 ...继续阅读 (17)

推荐序二“当年加入淘宝的毕业生成了淘宝开发 DBA 的主管,他就是本书的作者” -> “当年加入淘宝的毕业生成了淘宝开发DBA的主管，而当年加入阿里巴巴B2B的毕业生，就是本书的作者”序言“APS 编写网站应用” -> “ASP 编写网站应用”P90“假设 id 为 100″ -> “假设 id 为 1″“取出前20个” -> “取出第100至120个”“通过调用存储引擎借口来获取” -> “通过调用存储引擎接口来获取”P91代码 6-4 的解决方案一中 “LIMIT” 之前增加 “ORDER BY gmt_create desc”， 也就是在 P91 的第2行和第3行之间插入1行：ORDER BY gmt_create DESCP112最后一行的 “quuery” -> “query”P117“尽两减少大的复杂 Query” -> “尽量减少大的复杂 Query”P152“不仅 user_ ...继续阅读 (13)

有网友建议将原书“附录A”中的示例库结构脚本在网上贴出来，方便大家做实验的时候不用一个字母一个字母的敲，挺好的建议，以下就是示例库结构脚本的所有创建语句：--创建数据库CREATEDATABASEexample;--创建表--索引是根据应用中使用的Query的情况而决定，所有表开始都仅仅只有主键，没有其他的索引--各表没有特定存储引擎和字符集，各位读者朋友可根据自己的环境决定CREATETABLEevent(idint(11)NOTNULLAUTO_INCREMENT,gmt_createdatetimeNOTNULL,user_idint(11)NOTNULL,event_typevarchar(8)NOTNULL,event_msgvarchar(255)DEFAULTNULL,PRIMARYKEY(id));--组内讨论信息summaryCREATETABLEgroup_message(idint(11)NOTNULLAUTO_INCREMENT,gmt_createdatetimeNOTNULL,gmt_modifieddatetimeNOTNULL,group_idint(11)NOTNULL,user_idint(11)NOTNULL,authorvarchar(32)NOTNULL,subjectvarchar(128)NOTNULL,PRIMARYKEY(id)); ...继续阅读 (22)

今天，公元2009年06月11日，本人第一本独立完成的原创技术书籍《MySQL性能调优与架构设计》开始在China-Pub上正式首发了，卓越购买地址：《MySQL性能调优与架构设计》。很多朋友问我写书的感觉是怎样的，说实话，只需要一个字就可以形容：“累”。从开始写这本书到现在，已经将近一年没有看过电视，每天下班后就开始写，每天晚上都要到12点之后，周六周日都是如此。从那时候开始，我就再也没有看过电视了。当然，写完之后，还是有较大的成就感的。不管最后各位读者朋友的评价如何，都是倾注了自己这段时间来所有的心血。而且在整个过程中，对自己的知识技能也有很大的提高，包括知识体系的整合，细节的进一步理解。第一次写书，没有任何经验，又是一个人独自完成，由于实在太辛苦，中途甚至有一次差点决定放弃，幸好自己毅力还算坚定，最后总算坚持下来了。现在回头想想，不禁有点佩服自己的毅力。一个人的能力毕竟有限，书中肯定会存在不少问题，还请读者朋友们能够指出，万分感谢！ ...继续阅读 (16)

即使Oracle收购SUN，将MySQL这只小海豚归于麾下，也未必是件很糟糕的事情，MySQL和Oracle面对的客户群体不同，一个偏重中低端、互联网数据库市场，一个偏重高端、大型企业级数据库市场，有太多的理由相信这一收购不会是MySQL的终点，相反MySQL将会是Oracle产品线的良好补充，也许不久即成为埃里森手中的另一张王牌。目前MySQL装机量接近1200万，占有全球数据库25%市场份额，互联网公司80%的市场份额，特别近几年的Web 2.0兴起，更是引爆了MySQL的应用。但这些MySQL数据库大部分由开发工程师或系统工程师兼职维护着，国内专职MySQL DBA屈指可数，更别说是MySQL DBA团队。随着MySQL应用的逐步成熟，国内一些重量级互联网公司早已看到其潜力并进行大规模使用，更有一些公司磨刀霍霍却苦于该领域技术人才难求，百度、淘宝等知名的互联网公司都有大半年招不到一名合适MySQL DBA的经历。而系统介绍MySQL的中文书籍非常之少，值得一读的MySQL中文书籍更是少之又少。现在MySQL技术领域确实需要一批从理论与实践中锤炼出来的著作来造就更多更优秀的MySQL技术大师。从作者撰写此书开始，我就一直关注着，时而与其深夜相遇于MSN，呼之，答曰：写书ing。白天在工作中实践，夜里在灯光下沉淀。当时我就迫不急待地想提前一睹，现有幸如愿，阅后颇有感慨，字里行间可 ...继续阅读 (13)

1995年5月23日，这是一个普通的日子，但对MySQL来说，这是初生的时刻；自此，这个世界上多了一个数据库系统，这就是一开始被人们嘲笑为“玩具”数据库的MySQL。我是在2000年开始接触Linux和MySQL的，那时候国内网络仍然很不发达，想要找到MySQL的学习资料太不容易了，唯一可用的就是MySQL手册，而且还是英文的。就这样懵懵懂懂直到工作，这种情况仍未得到太大改善。这时候，我就在想，有朝一日我也要学习开源社区的精神，为开源社区做出一定的努力。此后，我利用业余时间翻译了不少MySQL的英文手册，以及不少优秀的技术材料，期间也有出版社联系我商谈出书事宜，虽未出过书，但深知写书的艰辛，因此也没敢答应下来，至今仍为一大遗憾。2008年2月26日，Sun收购了MySQL，可爱的小海豚差点就此走上了封闭的道路，幸好有开源社区各知名人士的奔走，才使得它仍然活跃在开源社区里，这让我们对MySQL的未来充满了信心。2009年4月20日，Oracle收购Sun后，我们却已不再担心MySQL的未来，因为我们坚信有开源社区的努力，即使Oracle想要扼杀它，也不会得逞的。随着互联网的发展，电子商务、Web 2.0等的崛起，一大批以LAMP技术为依托的企业如雨后春笋，这也大大刺激了MySQL DBA这个职位的需求。从前大家都把MySQL不当回事，认为普通的PHP程序员或系统管理员就可以搞定，但随 ...继续阅读 (19)

四年前，当我第一次接触MySQL时，版本还是4.1。当时的感觉这个数据库怎么这么“小”：安装文件小，只有不到20M；支持功能少，连基本的视图、过程、分区等功能都不支持；入门简单，几乎一天就可以熟练使用。不仅如此，而且使用起来感觉比较“怪异”，创建表时还要指定“MyISAM”、“InnoDB”这样奇怪的“存储引擎”，表名还要分大小写。这对当时已经习惯ORACLE这样“大型”数据库的自己来说，简直就像退回到了旧石器时代，心想虽然免费，但这样的数据库能用吗？随着工作的需要，慢慢的对MySQL的了解多了起来，原来的一些观念也逐渐发生了改变：虽然功能少，但占用磁盘空间小，而且对于开发使用来说，主要的功能基本都有，尤其是在MySQL5.0发布之后，一些常用功能更加完善，而对于功能庞大的ORACLE来说，近一个G的安装文件中，可能真正经常使用到的功能最多也就20%；虽然使用时要指定各种各样的“存储引擎”，但这些存储引擎却是八仙过海，各有各的”神通“，在不同的使用场景中，我们可以灵活的按需进行选择，使得我们的数据库性能尽可能的优化；尤其是对于MySQL的开源策略，越来越觉得是MySQL能够普及的一个最大特点。首先，在满足GPL协议下，MySQL可以任意下载并可以商用，这使得企业信息化建设的成本大大降低，这也是近几年互联网行业发展极快的原因之一；其次，开源的特性使得大家都可以对数据库源码进行一些个性 ...继续阅读 (15)

在我们这个时代，互联网上的资讯、交友、交易、Blog、游戏……已经融入了我们的生活。很难想象，一下子没了互联网我们会如何的不习惯，恐怕堪比互联网出现前突然让所有家庭没了电视。大量互联网上人的活动，产生大量有价值信息，这些信息被存放于数据库中。互联网也对数据库的技术传播功不可没。2000年的时候，要在网络上寻找有关数据库的技术资讯是那样地艰难，大量技术问题都需要自己去摸索。2002年oracle数据库讨论和学习氛围的兴起，成就了那一代数据库技术爱好者。他们对数据库技术的热爱，以及乐于分享的精神，促进了DBA这个行业的蓬勃发展。随着时代的进步，大中型机的没落，Intel CPU技术的发展引领着PC Server的更新换代，与小型机的性能差距越来越小，到今天价格几万人民币的PC Server已经可以超越部分厂家的价格百万的小型机处理能力。PC Server 的低成本和高性能是LAMP发展的基础，成本的巨大差异是用户选择pc server的原动力。数据的爆发增长对于数据库的渴求，让人们自然地将目光投向了MySQL，MySQL作为开源数据库的领军人物，向以投入成本大的Oracle数据库发起了挑战。其实在中国这么多年来MySQL数据库的应用和管理人才非常少，基本停留在非常初级的阶段。如今的状况看起来就跟2001年左右的Oracle数据库状况一样。这意味着MySQL数据库领域可能迎来高速的发展 ...继续阅读 (12)

2006年，阿里巴巴B2B与淘宝DBA团队第一次引入了校园招聘的毕业生，2年半的时间过去了，当年加入淘宝的毕业生成了淘宝开发DBA的主管，而当年加入阿里巴巴B2B的毕业生，就是本书的作者。第一次听别人说起作者的时候，有2点给我的印象是比较深的，一是有误传该学生毕业于军校，以至于后来，又误传他曾经加入过海军陆战队；二是该学生目标非常清晰，就是一定要做DBA，对于其它职位不予考虑。至于更后来，又知道他是我老乡，甚至春节一起回家，那就是后话了。作者刚毕业的时候其实学的是Oracle，后来，一是因为工作本身的需要，二来在我的建议下，改走了MySQL这条路。我很高兴作者能做出这个选择，并能在MySQL这条路上持之以恒的坚持下来。在当时，做MySQL DBA，其实是一个非常好的机会，也是一个新的切入点。Oracle从2001年在国内开始起步，2005年左右达到鼎盛的辉煌时期，同时造就了一大批大师级别的Oracle DBA，也成为后来者难以逾越的一道高墙。MySQL则不一样，这1-2年刚起步，未来2年左右如果能达到鼎盛时代的话，同样应当能成就一批大师，作者有可能就能成为其中的一员。在这么一个浮躁的年代，一个物质欲横流的时代，作者能持续保持学习的动力，并且不断进步提升，是非常不容易的。这本书，既是作者这几年来DBA成长之路的一个总结，更是非常好的一个经验借鉴，特别是对于那些刚走出校园的毕业生，这本 ...继续阅读 (12)

《MySQL性能调优与架构设计》一书很快就会在各书店上架了，这里帖出几位好友为此书所写的推荐序，分别是：冯大辉，陈吉平，冯春培，翟振兴，叶金荣，吴诗展，再次在此感谢几位了。（按照出版社要求以各位的年龄为序排列）第一篇先列出冯大辉（Fenng）的推荐序，如下：拥抱MySQL数据库技术时至今日，恐怕已经没有人再把 MySQL 当成一个玩具性质的软件产品，即使是数据库市场执牛耳者如Oracle公司也不得不正式面对来自MySQL的冲击。如果说几年前，还有人对使用MySQL有所疑虑么? 经过几年来互联网的高速发展，无数大型网站用其成功案例证明，以MySQL为基础的数据层解决方案已经成为互联网应用不可或缺的一个重要组成部分。当下也是数据库技术应用处于激烈变革的时期。这并不是说传统的关系数据库技术在这两年有了多大的新突破，而是用户的需求在迅速变化。更多时候，用户不再需要单一的软件产品，而是灵活、高效、可靠、可控、低廉的解决方案。很多大型站点甚至根据自己的需求来改进 MySQL，进而回馈给开源社区，这也是开放的魅力所在，对于传统的商业数据库软件商来说，这是不可想象的事情。MySQL早已不再是单一的数据库软件，以其为基础发展起来的各种开源组件令人目不暇接，而用这些组件构成的解决方案也是层出不穷。如何能够把以MySQL为核心的这一系列软件充分运用，构建大型可扩展性网站，正是不少LAMP架构体系的网站开 ...继续阅读 (15)

从去年开始计划写这本书到现在前前后后已经10个月了，现在书稿已经出片，在印刷厂印刷中了，按照出版社的计划，只要后面出版社不出现异常状况，在月底之前肯定会上架面市。在此感谢大家一直以来的给我的帮助与支持，感谢大家的关注。在这里先放出最终的目录结构：第1篇 基础篇第1章 MySQL基本介绍1.0 引言1.1 MySQL Server简介1.2 MySQL与其他数据库的简单比较1.3 MySQL 的主要适用场景1.4 小结第2章 MySQL架构组成2.0 引言2.1 MySQL物理文件组成2.2 MySQL Server系统架构2.3 MySQL 自带工具使用介绍2.4 小结第3章 MySQL存储引擎简介3.0 引言3.1 MySQL存储引擎概述3.2 MyISAM存储引擎简介3.3 InnoDB存储引擎简介3.4 NDB Cluster 存储引擎简介3.5 其他存储引擎介绍3.6 小结第4章 MySQL安全管理4.0 引言4.1 数据库系统安全相关因素4.2 MySQL 权限系统介绍4.3 MySQL 访问授权策略4.4 安全设置注意事项4.5 小结第5章 MySQL备份与恢复5.0 引言5.1 数据库备份使用场景5.2 逻辑备份与恢复测试5.3 物理备份与恢复测试5.4 备份策略的设计思路5.5 小结第2篇 性能 ...继续阅读 (13)

接着之前的一篇“MySQL 内存使用-线程独享”，再写一篇 MySQL 全局共享内存的使用介绍。全局共享内则主要是 MySQL Instance（mysqld进程）以及底层存储引擎用来暂存各种全局运算及可共享的暂存信息，如存储查询缓存的 Query Cache，缓存连接线程的 Thread Cache，缓存表文件句柄信息的 Table Cache，缓存二进制日志的 BinLog Buffer， 缓存 MyISAM 存储引擎索引键的 Key Buffer以及存储 InnoDB 数据和索引的 InnoDB Buffer Pool 等等。下面针对 MySQL 主要的共享内存进行一个简单的分析。查询缓存（Query Cache）：查询缓存是 MySQL 比较独特的一个缓存区域，用来缓存特定 Query 的结果集（Result Set）信息，且共享给所有客户端。通过对 Query 语句进行特定的 Hash 计算之后与结果集对应存放在 Query Cache 中，以提高完全相同的 Query 语句的相应速度。当我们打开 MySQL 的 Query Cache 之后，MySQL 接收到每一个 SELECT 类型的 Query 之后都会首先通过固定的 Hash 算法得到该 Query 的 Hash 值，然后到 Query Cache 中查找是否有对应的 Query Cache。如果有，则直接将 C ...继续阅读 (19)

对于任何一个数据库管理系统来说，内存的分配使用绝对可以算的上是其核心之一了，所以很多希望更为深入了解某数据库管理系统的人，都会希望一窥究竟，我也不例外。从内存的使用方式MySQL 数据库的内存使用主要分为以下两类线程独享内存全局共享内存今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。在 MySQL 中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。线程栈信息使用内存(thread_stack)：主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。排序使用内存(sort_buffer_size)：MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，所以sort_buffer_size参数对排序操作的性能影响绝对不可小视。排序操作的实现原理请参考：MySQL Order By 的实现分析。Join操作使用内存(join_buffer_size)：应用程序经常会出现一些两表（或多表 ...继续阅读 (23)

前段时间看了mysqlperformance blog上一篇关于 filesort 的文章，看到 Percona 公司在招聘面试的时候常问应聘者“Explain 命令输出中的 filesort 的含义是什么”这个问题，而且基本上都得不到正确的答案，甚感奇怪。按理这是非常基础的内容了，既然敢于去 Percona 这样高手如云的公司应聘，不应该不清楚这个问题吧。所以我也试探性的问了 MySQL圈子 中的几位朋友这个问题，结果和 Percona 所遇到的情况基本一样，仅有 1/10 的朋友真正明白 filesort 的含义，而且给出的错误答案也都和 Percona应聘者的答案差不多：是 mysql 在进行排序的时候，临时表太大，超出 MySQL 限制，需要将数据写出到磁盘文件中进行排序，所以称之为filesort。这个“貌似正确”的答案，大部分都是因为 “filesort” 这个词的字面含义所误导猜测出来的。看来并不仅仅只有中国人喜欢“望文生义”，老外也是一样嘛！那 Explain 命令输出信息中的 filesort 到底是什么意思呢？其实很简单，就是告诉你 MySQL 需要进行实际的排序操作而不能通过索引获得已排序数据。个人觉得上面的错误答案其实至少错了以下两点：filesort（其实就是排序） 可不一定会产生临时表哦filesort 与临时表数据写入磁盘是没有任何直接联系的上面两点错 ...继续阅读 (9)

今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug：在 5.1 版本中，Innodb 存储引擎如果使用autocommit=0的情况下，单条SQL在执行过程中如果异常中断的话，事务完整性可能无法保证，不论是STATEMENT还是MIXED的binlog_format，都存在相同的问题，可以重现，屡试不爽。测试环境如下：OS：SunOS 5.10 Generic_137138-09DB：MySQL 5.1.31/32-log Source distributionbinlog_format:MIXED/STATEMENTtx_isolation:REPEATABLE-READ测试脚本如下：[root@dc-5 /tmp]#cat deletetest.sh#/bin/shmysql -uadmin -h127.0.0.1 -pxxx -e"set autocommit=0;delete from test.test;"[root@dc-5 /tmp]#cat killtest.sh#/bin/shmysqladmin -uroot processlist |grep "admin"|awk '{print $2}'|xargs mysqladmin -uroot kill将删除的脚本放到后台执行，然后执行kill脚本：[root@dc-5 ...继续阅读 (10)