现在通过数据的水平切分（sharding）来实现数据库 Scale Out 的解决方案受到了越来越多人的青睐，但是在切分过程中可能遇到的问题也肯定不在少数，如切分规则的设计，切分后的访问路由，切分后的主键的全局唯一等等。这里我主要列举几个可以使用在 MySQL 数据库主键全局唯一方案及其优劣，供大家参考：通过应用程序生成一个GUID，然后和数据一起插入切分后的集群。优点是维护简单，实现也容易。缺点是应用的计算成本较大，且GUID比较常，占用数据库存储空间较大，涉及到应用的开发。通过独立的应用程序事先在数据库中生成一系列唯一的 ID，各应用程序通过接口或者自己去读取再和数据一起插入到切分后的集群中。优点是全局唯一主键简单，维护相对容易。缺点是实现复杂，需要应用开发。通过中心数据库服务器利用数据库自身的自增类型（如 MySQL的 auto_increment 字段），或者自增对象（如 Oracle 的 Sequence）等先生成一个唯一 ID 再和数据一起插入切分后的集群。优点是？好像没有特别明显的优点。缺点是实现较为复杂，且整体可用性维系在这个中心数据库服务器上，一旦这里crash了，所有的集群都无法进行插入操作，涉及到应用开发。通过集群编号加集群内的自增（auto_increment类型）两个字段共同组成唯一主键。优点是实现简单，维护也比较简单，对应用透明。缺点是引用关联操作相对比 ...继续阅读 (11)

在 IT 行业很多工程师（尤其是很多 DBA）的心目中，都把小型机视为解决性能问题的终极武器，认为小型机的处理能力要远大于 PC Server。在几年前，可能也确实是这样。但随着近几年 X86 架构芯片技术的飞速发展，PC Server 的处理能力已经越来越强悍，不断的给我们带来惊喜。最近几年的小型机市场，基本上被 IBM 吃掉了大部分。虽然可能并不完全是因为其 Power 芯片处理能力与其他厂商的芯片相比有优势，但其处理能力方面的优异表现确实是一个很重要的因素。所以最近几年我们一直关注着 IBM 小型机与其他主机的处理能力比较，当然比较是基于 Oracle 数据库所做的一些测试。测试基本模型如下：在待测主机上安装好 Oracle 数据库，配置足够装载下所有数据的 SGA，将 Oracle 的 Redo 日志放在内存文件系统上。然后在我们技术能力范围内对 Oracle 进行相应的调优。使用我们真实的线上数据抽样（约10GB），Import 进入待测试主机上的 Oracle 数据库中。通过 PL/SQL 编写出模拟我们在线业务中最为典型的事务逻辑，然后使用C++编写多线程程序作为压力测试客户端。通过多台主机运行压力测试程序，平缓的给待测主机增加压力，待测主机的 CPU 利用率基本用完为止。测试数据的收集主要通过恒定时间段的 Oracle 数据库自身性能数据采样（statspack）， ...继续阅读 (17)

今天在网上搜索资料，在百度中搜索了一个MySQL Order By，居然发现我的一篇分析 MySQL Order By 实现原理的文章“MySQL Order By 的实现分析”居然排名第一，有点惊喜加意外啊，如图：后来又尝试了一下MySQL Group By，居然又是我的一篇分i析 MySQL Group By 实现原理的文章“MySQL 中 GROUP BY 基本实现原理”，有点兴奋啊，如图：再来一个MySQL Replication，这次带来的不是兴奋了，而是很不爽。为啥？因为排名第一的仍然是我的一篇文章“MySQL Replication(复制)基本原理”，但是其他人转载，点开来一看，居然没有任何原作者信息和原文链接地址，如图：自己写的文章能被大家认可并转载，本是一件值得开心让人欣慰的事情，可看到没有任何说明及链接信息，心里还是很不是滋味。 ...继续阅读 (5)

这几天和出版社一起讨论了以下 《MySQL 性能调优与架构设计》封面以及所属系列的事情，前后沟通调整5次，目前基本已经出来封面的初稿了，暂定为 LAMP 系列。封面初稿如下(点击可看大图): ...继续阅读 (15)

上个周末，也就是情人节晚上，同事Fenng在dreamhost空间上打造了一个一个山寨版的 51job 网站JobsDigg.com，很快就引起了轰动效应。仅仅两三天时间，注册用户就过百了，日 PV 过万，网友发布的招聘信息也已经好几十条了。由于 Fenng 本人在 IT 圈内的影响力，以及对 JobsDigg 定位的特殊性（用山寨自助招聘站点革掉商业招聘站点和猎头们的命），JobsDigg 在短时间内聚集了大量资深 IT 人士的关注，同时也吸引了不少业内有名的 IT 企业来发布相关职位的招聘信息。当然，吸引到大量求职者的关注就更不用说了。这不，短短三天时间，我发布一条阿里巴巴招聘MySQL & Oracle DBA的信息后就收到了3封求职简历。强烈建议各公司的招聘 HR 去 JobsDigg.com 发布自己的招聘职位信息，同时也建议各位正在或者打算寻找新的出路的所有需要一个新职位的朋友们去 JobsDigg.com 发布求职信息或者寻找适合自己的职位注： JobsDigg.com 目前处于 Beta1 版本阶段最新消息，JobsDigg.com 目前已经更新至 Beta2版本了（Last Update : 2009.02.17 10:21:00 AM） ...继续阅读 (9)

MySQL 从去年11月底发布了 5.1 的 GA 版本（5.1.30）之后，业内对其产品质量出现了大量的质疑声。估计 SUN 为此也头疼了不少时日吧，对产品质量的改进肯定也是加紧进行了。这不，才过去两个来月的时间，又发布了新的一版 5.1.31。在刚刚发布的 5.1.31 版本中主要做了以下的改进：功能增加或改进：新增状态变量 Queries ，和原 Questions 的区别在于除了包含 Questions 已经包含的所有计数之外，还增加了存储过程中所执行的 Query。select * from information_schema.column 语句的性能改进全文索引增加 Hint 支持（如：ignore index(ft_index_name) 等）Bug fixed：(bug 40116)，解决了当一个 定义在 Innodb 上面的 Trigger 更新非事务表数据的时候，可能出现事务未提交前就已经被 Replicated 到Slave 端并且能够被访问的问题。(bug 39084)，在复制 Innodb 的分区表的时候，如果更改事务隔离级别，可能出现基于语句（Statement）的二进制日志记录失败的现象。(bug 40972)，当一个非法日期类型数据（date或者datetime）出现在 WHERE 条件中查询分区表的时候，可能造成 mysqld crash。(bu ...继续阅读 (12)

春节后回杭州路图中在南昌停留了半天，看了一眼由 叶剑英 题词的“八一南昌起义纪念塔”，逛了一圈“八一广场”，也算是见识了南昌城市的窗口。说这是窗口是因为四面是通往城市四方的直通大道，不论你来自何方，都要到这个必须之地入到城中。这里也是南昌市民活动的中心，每年在这个广场上会举办各种各样的政务和商务活动，广场上的装饰更是千变万化隔日不同。在广场上拍了几张纪念塔和光擦和嗯音乐喷泉的照片 ...继续阅读 (11)

回家过了春节，昨晚十点多才到杭州。初二就从家里出来了，先到大姑姑家拜年，并在那睡了一晚，第初三天前往大姨妈家，初四早上到舅舅家吃了早饭再回大姨妈家，因为初五要坐表哥的车（部分顺道）到江西新余。从家回杭州的路途也算有点折腾的，初五早上9点从桃源出发，在长沙绕城告诉上面走错了路，多绕了大概半小时路程才找对前往江西方向的高速。到萍乡的服务站吃了午饭，稍加休息后继续往前，在宜春与吉安途中新余高速路口下车步行出高速收费站，然后打车到新余长途汽车站。高速路口四周非常荒凉，还以为距离市区的长途汽车站很远，在将黑心的出租车司机提出的30块砍到20后的我还洋洋得意，没想到5分钟不到就到了车站，只能后悔出收费站的时候没有问一下“交警叔叔”。在车站买了17:45前往南昌的汽车票（当时时间13:30左右），到南昌已经是近21:00了。幸运的是南昌长途汽车站晚上售票时间到22:30，马上排队买最近时间到杭州的汽车票（火车票我是完全没有指望过）。大约半小时之后，总算是买到了第二天（初六）13:15 的汽车票（加班车），然后住在了离车站较近的新华宾馆。第二天早上9点起床，没多少时间，就到附近的八一广场（也算是南昌的标志性场所了）逛了一圈，随便拍了几张纪念碑和广场音乐喷泉的照片，时间也就差不多了。下午回杭州的车司机第一次跑这条路，居然在到杭州上绕城告诉后找不到从哪里下高速，晕倒。本来是到西站的，结果在沟庄下了高速 ...继续阅读 (13)

从开始撰写这本关于 MySQL 数据库系统性能调优及架构设计的图书到现在已经5个月时间了，从最初到现在，即使连初稿都没有完成，就已经修改过多次。包括提纲内容，章节调整删减等等。期间收到过很多朋友的建议与意见，都对我有很大的帮助，在此表示真诚的感谢！明天就要回家休假了，到时候可能会有一段时间不会上网，不过大家放心，仍然会坚持写作。在回家之前将目前的进度大体说一下：第一篇基础篇基本完成，但有一幅非常重要的图暂时还没有画；第二篇维护篇完成70%，暂停写作；第三篇优化篇完成95%，待整合修整；第四篇架构篇完成50%，正在进行中；注：以上所有内容目前还处于比较粗糙的初稿阶段考虑到受众对象对内容的期望以及网友相关建议，经过和出版社商量，有可能会对第一篇和第二篇做一些调整，合为一篇，但目前还并没有确定，如果各位朋友有任何建议和意见，随时可以 Mail 反馈给我 sky000 [AT] gmail.com。再次感谢各位朋友给我提出的很多宝贵建议以及对我的支持，谢谢！ ...继续阅读 (22)

同事郑隐（也是同一个学院的校友）今天在 Team 内部做了一次关于 Oracle Data Buffer 相关的 Internal 信息的分享，觉得非常不错，特此共享出来:Oracle Data Buffer Cache Internal此PPT版权所有：郑隐 ...继续阅读 (22)

说实话，在读 Peter Morville 与 Louis Rosenfeld 合著的这本《Web 信息架构 – 设计大型网站》之前，我甚至都不知道还专门有 “Web信息架构师” 这一类职业，只不过一直以为这只是某些产品经理们所需要兼顾考虑的事情。自从看了此书之后，方才知道，原来还有这样一个职业（或者说是职位）。全书从信息架构的原理，到流程方法，再到实践以及相关的案例分析，对 Web 信息架构所涉及到的各方面内容描述的清晰透彻，连我这个对“信息架构”完全属于门外汉的人都轻松理解了，可见内容还是非常易懂的，哈哈。书中有一个观点尤其让我引起共鸣，那就是在现在这样爆炸式的信息时代，我们已经不能仅仅通过传统的网站可用性（如网站能够访问，用户能够正常操作）来衡量一个网站的可用性，还需要将易用性也归纳入可用性范畴。虽然我的第一职业就是做运维，尽可能保障传统可用性，但也非常认可这样的观点。像现在这样一个信息高速时代，人们在获取信息的时候，更希望能够在最短的时间内以最简单的方式获取自己需要的内容。 而如今的互联网时代，几乎每一种应用都基本上可以找到替代者，而且呈越来越多的趋势。如果我们所提供的海量信息不能够以一个非常合理的组织结构来呈现，就很可能给用户在使用过程中带来烦恼，进而离开换用其他更为易用的替代品。除非你是一个完全的垄断者，才会迫使用户不得不继续适应你，可在变换如此之快的互联网 ...继续阅读 (23)

昨天在好友姚明（ 此姚明非彼姚明） 家吃火锅晚餐，回家已经快12点了，然后又在电脑上看了部下载的电影，睡得很晚，今天起床也就很自然是中午12点之后了。刚起床就接到同事电话：今日天气不错，出去骑一趟？虽然原计划元旦三天在家专心写书，可想想之前我们俩已经约过好几次了都没有去成，不管了，落下的内容就晚上熬夜写吧，去！匆匆忙忙洗嗽之后到小区门口随便吃了点东西就准备出发了。两个人从文二路学院路口开始码表归零，计程出发。路线大概如下：文二路学院路口 -> 天目山路 -> 玉古路 -> 林隐路 -> 龙井路 -> 三台山路 -> 虎跑路 -> 钱江一桥 -> 江南大道 -> 时代大道 -> 公司滨江新大楼工地 -> 时代大道 -> 钱江四桥 -> 复兴路（走错路了） -> 美政路 -> 之江路 -> 中河南路 -> 延安路 -> 庆春路 -> 环城西路 -> 体育场路 -> 天目山路 -> 学院路文二路口回头一看，还确实经历了不少路，途中刚下四桥的时候还走错了方向，差点被迫沿江而上再次回到一桥原路返回。后来一想，走原路没啥意思，还是回去四桥头重新找路。中途两次休息，一次是在公司新大楼工地旁，另外一次就是走错路后在江边看了会儿江景，两次休息时间加起来大约45分钟。整个过程不是太累，只有去的时候因为有不少上坡路，出了一些汗。回程因为是市区，而且经过了繁华的延安路，路上人多车多，速度就慢下来了。等下次 ...继续阅读 (20)

08年的最后一天，怎么的也该在自己的 Blog 上留个印吧。这一年，有些累，自己也说不明白因为啥（难道是自己老了？我坚持不这样认为，哈哈）不想在这里对这一年做太多总结，也不想对09年做太多的展望；过去的，就让他过去吧，未来的打算暂留脑中；自己也没想清楚是想说啥，还是算了吧，留个印就好了；祝愿所有的亲人朋友在09年 身体健康，一切如意！ ...继续阅读 (7)

前几天收到博文视点（电子工业出版社）赠送的两本书：《构建可扩展的Web站点》（Building Scalable Websites）和《Web信息架构：设计大型网站》（Information Architecture for the World Wide Web：Designing Large-Scale Web Sites），这几天忙里偷闲大概读了一下第一本，确实如网上很多朋友所说是一本不可多得值得多次回味的经典图书，在同事Fenng 的博文中也曾有提到。虽然全书页数不多，只有300多页（其实这是我认为一本书最合适的厚度了），但是涉及到的内容非常全面。可能有些人会认为内容有广而泛的嫌疑，但这可能更多的是一些仅仅只是喜欢了解学习一些小技巧的人的看法。全书从应用程序的开发环境到应用程序的扩展设计，从数据的国际化到一致性及安全有效性，从系统性能瓶颈的定位方法到优化思路，从应用层的扩展到数据库层的架构，甚至连网络协议的合理选择以及 API 的合理利用都有较多的涉及和较深的认识。而且，不仅涉及到上面这些软件方面的内容，还有部分硬件架构方面的内容对于当前很多 Web 站点，尤其是很多 Web 2.0 应用的架构师来说，是非常有价值的。当然，如果你仅仅只是希望能从书中找到一个具体的解决你当前所遇到的问题的方法，那我建议你“出手”之前可以再考虑了解一下该书的内容定位。而如果你是希望取得构建可扩展 ...继续阅读 (26)

为本人所在 Team（Alibaba DBA Team）发个招聘的小广告，详细信息如下：MySQL DBA职位描述：管理MySQL数据库开发项目支持与优化MySQL数据库性能优化MySQL数据库高级特性测试，优化与实践岗位要求：精通SQL熟悉SQL Tuning熟悉MySQL数据库架构与管理熟悉MySQL Replication与NDB cluster的原理熟悉LINUX操作系统熟悉shell,perl(掌握一门)良好的沟通技能、团队合作能力熟悉unix环境下C语言编程者优先注：不要太聪明的，只要做事踏实的Oracle 开发 DBA职位描述：评估，跟踪，支持开发项目数据库变更管理Schema设计与审核数据库开发性能优化开发、测试环境管理与维护岗位要求：精通SQL,PL/SQL精通SQL Tuning精通数据库建模熟悉Oracle基本管理有开发经验者优先良好的沟通技能、团队合作能力注：此招聘广告长期有效有意者请将简历 Mail 至本人邮箱： sky000 [AT] gmail.com ...继续阅读 (9)

时间过得还真是快啊，一转眼，到阿里巴巴就快三年了。想想当年初进阿里巴巴的时候，我们的DBA Team（包括支付宝的 DBA）也才8个人，在短短不到三年时间之内，不包括支付宝的 DBA Team（已经分开成两个独立的 Team 了）就已经扩展到13个人了。当然，也有一两位当年的战友已经不在现在的 DBA Team，包括被大家称为 传说中的鲁道夫（Rudolf，去公司其他 Team 承担更为重要的责任）和 阿里 SQL 第一人（号称只有想不到没有写不出的SQL）的文学兄（出去自己创业了）。最近在本本中“闲逛”，找到了几张当年一起游黄山的老照片，贴出来大家看看：先来两张我自己的：和 fenng 在山顶歇脚：大家在台阶上休息：在花山迷窟内的合影(缺了两位留守值班的战友)： ...继续阅读 (11)

接上一篇：MySQL 中 GROUP BY 基本实现原理DISTINCT 实际上和 GROUP BY 操作的实现非常相似，只不过是在 GROUP BY 之后的每组中只取出一条记录而已。所以，DISTINCT 的实现和 GROUP BY 的实现也基本差不多，没有太大的区别。同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成 DISTINCT 的时候，MySQL 只能通过临时表来完成。但是，和 GROUP BY 有一点差别的是，DISTINCT 并不需要进行排序。也就是说，在仅仅只是 DISTINCT 操作的 Query 如果无法仅仅利用索引完成操作的时候，MySQL 会利用临时表来做一次数据的“缓存”，但是不会对临时表中的数据进行 filesort 操作。当然，如果我们在进行 DISTINCT 的时候还使用了 GROUP BY 并进行了分组，并使用了类似于 MAX 之类的聚合函数操作，就无法避免 filesort 了。下面我们就通过几个简单的 Query 示例来展示一下 DISTINCT 的实现。1.首先看看通过松散索引扫描完成 DISTINCT 的操作：sky@localhost:example11:03:41>EXPLAINSELECTDISTINCTgroup_id->FROMgroup_messageG********************* ...继续阅读 (19)

之前连着写了几篇关于 MySQL 中常用操作的一些基本实现原理，如，MySQL ORDER BY，MySQL Join，这次再写一篇 MySQL 中 GROUP BY 的基本实现原理。由于 GROUP BY 实际上也同样会进行排序操作，而且与 ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与 ORDER BY 一样也可以利用到索引。在 MySQL 中，GROUP BY 的实现同样有多种（三种）方式，其中有两种方式会利用现有的索引信息来完成 GROUP BY，另外一种为完全无法使用索引的场景下使用。下面我们分别针对这三种实现方式做一个分析。1.使用松散（Loose）索引扫描实现 GROUP BY何谓松散索引扫描实现 GROUP BY 呢？实际上就是当 MySQL 完全利用索引扫描来实现 GROUP BY 的时候，并不需要扫描所有满足条件的索引键即可完成操作得出结果。下面我们通过一个示例来描述松散索引扫描实现 GROUP BY，在示例之前我们需要首先调整一下 group_message 表的索引，将 gmt_create 字段添加到 group_id 和 user_id 字段的索引中：sky@localhost:example08:49:4 ...继续阅读 (14)

在 MySQL 中，只有一种 Join 算法，就是大名鼎鼎的 Nested Loop Join，他没有其他很多数据库所提供的 Hash Join，也没有 Sort Merge Join。顾名思义，Nested Loop Join 实际上就是通过驱动表的结果集作为循环基础数据，然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。如果还有第三个参与 Join，则再通过前两个表的 Join 结果集作为循环基础数据，再一次通过循环查询条件到第三个表中查询数据，如此往复。还是通过示例和图解来说明吧，后面将通过我个人数据库测试环境中的一个 example（自行设计，非MySQL 自己提供） 数据库中的三个表的 Join 查询来进行示例。注意：由于这里有些内容需要在MySQL 5.1.18之后的版本中才会体现出来，所以本测试的MySQL 版本为5.1.26表结构：sky@localhost:example11:09:32>showcreatetableuser_groupG***************************1.row***************************Table:user_groupCreateTable:CREATETABLE`user_group`(`user_id`int(11)NOTNULL,`group_id`int( ...继续阅读 (10)

早上同事问我在哪里可以找到 MySQL 的客户端安装包，他需要在一台 Oracle 数据库主机上面安装 MySQL 的客户端包做一些事情。当我打开 MySQL 官方网站下载频道页面的时候，眼前出现了让我比较惊讶的内容，截图如下：看出究竟了吧，还没有？那看来你并不是很经常或者并不是很关注 MySQL 各个版本的发展情况。 MySQL Comunnity Server 默认的下载版本已经从 MySQL 5.0 GA 换成 MySQL 5.1 GA 了，已经明确标识为：Current Release (Recommended)MySQL 5.1—Generally Available (GA) release for production useUpcoming ReleasesMySQL 6.0 — AlphaMySQL Maria PreviewSnapshots— source code snapshots of the development treesGlassfish+MySQL bundle— developers editionOlder ReleasesMySQL 5.0 — Previous GA releaseMySQL 4.1 — Previous GA releaseArchives of Older Releases从内容显示，MySQL 5.0 已经 和 ...继续阅读 (26)

在此之前曾经写过一篇介绍“Innodb 索引结构了解 – Innodb Index Structure”的文章，这次再接着分析一下 MyISAM 存储引擎索引的基本存储结构。从索引基本的存放数据结构来说，MyISAM 的索引不论是 Primary Key 还是普通 Index，存储结构都基本一样，基本结构都是 Balance Tree （简称为 B-Tree），所有的键值详细信息和行“指针”信息都存放于 B-Tree 的 Leaf Nodes 上面。这个基本的数据结构和 MySQL 的其他存储引擎如 Innodb 也基本相同。但是，MyISAM 的索引并不像 Innodb 存储引擎那样 Primary Key 和 Secondary Index 中存放的数据存在较大区别。在 MyISAM 存储引擎中，Primary Key 和其他的普通 Index 的主要区别仅仅在于 Primary Key 的索引键需要满足是非空的唯一值而已，另外一个区别其实也是每一个普通索引之间都存在的区别，就是整个索引树的键值排列顺序不太一样。由于 MyISAM 存储引擎中数据行的存储分为固定长度和动态长度两种，所以在 MyISAM 存储引擎的数据文件中定位一行数据所需要信息也存在两种方式。一种是直接通过行号（row number）来定位固定长度表数据的行，另外一种是通过其他一些相对的文件位置标识 ...继续阅读 (10)

总的来说，在 MySQL 中的ORDER BY有两种排序实现方式，一种是利用有序索引获取有序数据，另一种则是通过相应的排序算法，将取得的数据在内存中进行排序。下面将通过实例分析两种排序实现方式及实现图解：假设有 Table A 和 B 两个表结构分别如下：sky@localhost:example01:48:21>showcreatetableA\G***************************1.row***************************Table:ACreateTable:CREATETABLE`A`(`c1`int(11)NOTNULLdefault'0',`c2`char(2)defaultNULL,`c3`varchar(16)defaultNULL,`c4`datetimedefaultNULL,PRIMARYKEY(`c1`))ENGINE=MyISAMDEFAULTCHARSET=utf8sky@localhost:example01:48:32>showcreatetableB\G***************************1.row***************************Table:BCreateTable:CREATETABLE`B`(`c1`int(11)NOTNULLdefault'0',`c2`char( ...继续阅读 (25)

Innodb 作为 MySQL 中使用最为广泛的 事务型存储引擎，不仅在事务实现数据版本控制方面和其他存储引擎有一定的区别，其数据结构也是以非常有特点的方式存储的。每个Innodb表的数据其实可以说就是以一个树型（B-Tree）结构存储的，表的数据和主键（Primary Key）共同组成了一个索引结构，也就是我们常说的Innodb的Clustered Primary Key。在这个Clustered Primary Key中，Leaf Nodes其实就是实际的表记录，我们常规理解上的索引信息全部在Branch Nodes上面。除了Clustered Primary Key之外的其他所有索引在Innodb中被称为Secondary Index。Secondary Index就和普通的B-Tree索引差不多了，只不过在Secondary Index的所有Leaf Nodes上面同时包含了所指向数据记录的主键信息，而不是直接指向数据记录的位置信息。所以，在 Innodb 中，如果主键值占用存储空间较大的话，会直接影响整个存储 Innodb 表所需要的物理空间，同时也会直接影响到 Innodb 的查询性能。下面是画的一张 Innodb 索引基本结构图，包括 Primary Key 和 Secondary Index 两种索引的比较。 ...继续阅读 (17)

随着 BI (DW) 在各个企业中重要性的不断提升，各个数据库厂家都希望能搭上这辆班车。这不，MySQL 也联合Infobright一起推出了开源的数据仓库解决方案，而且是开源的。其实现的各种DW该有的功能就不多说了，但是 Infobright 有一点非常吸引人的技术特点不能不提，那就是以列为导向的架构设计。以列为导向的架构设计是非常适合于DW应用场景的，对于大多数DW的分析场景中，实际关注的数据很多时候都只有那么一列或者少数几列的数据。所以在以列为导向的设计中，大部分的分析查询都只需要读取某一个（或者几个）表的几列，而不需要像传统以行为导向的数据库（或者存储引擎）那样需要扫描整个表的数据，这两者IO量的差距是非常大的。除了以列为导向的架构设计之外，Infobright 和很多其他的DW解决方案一样，也会进行数据压缩，而且由于其以列为导向的存储方式，压缩比率在很多情况下都会比以行为导向的存储方式更高，效果更理想。有人通过测试比较，常规的以行为导向的存储数据压缩比率较高的时候也就 3:1 左右，但是 Infobright 的却很容易就做到 10:1 的压缩比率。此外，从MySQL 以及 Infobright 的官方报道中除了上述技术特点（或者说优势）之外，还有很多其他的被描绘的非常神奇的功能，如被称为 “知识网格” (Knowledge Grid) 的自我管理功能，完全不需要索引或者 ...继续阅读 (13)

自Sun收购了MySQL AB 以来，虽然对于我们来说并没有看到Sun给MySQL带来太多实质性的改进和优化，但是从Sun官方目前在各种场合的表态可以看出他们还是比较重视MySQL这个数据库产品的。而且，Sun也保证了会一直保持MySQL的开源之路。收购了MySQL之后，Sun在整合MySQL和自己以前的软硬件产品方面也在不断的努力和尝试，看看下面这个视频中Sun为整合优化MySQL到自己的软硬件平台所建立的实验室吧，还是耗费了不少 $ 的，呵呵。 ...继续阅读 (10)

这几天看了不少Google针对于MySQL开发的google-mysql-tools，找到一个很有意思的Patch：MirroredBinlogs。这个Patch通过修改MySQL Replication中Slave IO线程的实现，让该线程在写入relay log的同时，再Mirror了一份与Master端完全一模一样binlog。这里所说的一模一样不仅仅是binlog的内容完全一样，同时还包括binlog的文件名。也就是说，该线程在Slave端完全copy了一份Master的binlog日志。在该 Patch 的描述中，该 Patch 产生的初衷是为了解决Slave与Master之前的顺利切换，并保证切换之后其他Slave仍然能够正常从新的Master继续进行复制。作者设想了如下一个场景：在 Hierarchical Replication（级联复制）环境中，第一层是有一台 Master ，第二层是两台 Slaves ，这两台Slave主要作用是作为第三层更多 Slave 的 Master 。也就是，第二层的两台 Slave 的角色在整个集群环境中是一个复制代理。如果我们使用的是普通的MySQL，那么中间代理层的两台Slave之间的binlog日志可能会有较大差异，因为两台Slave自身也会有产生binlog的event。而通过使用该Patch之后，通过 Slave IO 线程 ...继续阅读 (18)

同事 Struct Chen 的Amoeba For MySQL项目已经 出来不短时间了，可一直没有时间好好体验，最近一直在做一些软件和硬件的功能以及性能相关的测试工作，Amoeba For MySQL自然也将被列入计划之内。对 Amoeba For MySQL 的测试到目前位置主要还是功能方面的测试，配置了一套四台机器的环境：Server A： Amoeba ServerServer B： MySQL MasterServer C： MySQL Slave1Server D： MySQL Slave2软件环境：RHEL5.2 （X86_64），JAVA 1.5.0_16， Amoeba For MySQL 0.31测试功能：1、读写分离2、数据垂直切分3、数据水平切分amoeba.xml配置如下：xml version='1.0' encoding='%SOUP-ENCODING%'8066property>10.0.38.21property>proxy server net IO Read thread size500property>proxy server client process thread size500property>mysql server data packet process thread size500property>socket Send and ...继续阅读 (15)

开始着手写这本书也有40来天了，期间有不少热心网友不断的送来非常好的建议，也得到了身边同事和朋友的支持，目前进展基本还算顺利。由于多方面原因的考虑，和出版社商量之后决定暂停正在前面两“基础”和“维护”这两篇的写作，而先转向第三篇“优化”的写作，完成第三篇之后也会继续往后直接进行“架构设计”部分的写作，然后再转回完成第一篇和第二篇的内容完善。谢谢各位朋友的支持！ ...继续阅读 (17)

开始动笔写MySQL数据库性能优化与架构设计的书籍一个多月的时间了，目前已经完成第一部分（基础篇）和第二部分（维护篇）的“MySQL 安全管理”，当然都还只是初稿，还没有开始校验和编排方面的工作；整体进度基本还是在计划控制之内，个人感觉前面部分虽然要更简单，但写作的时候反而比自己想象的更慢，更难写，或许也是因为自己所擅长的点不在这方面吧。后面的内容技术性会越来越强，当然也会是我自己越来越擅长的内容，而且之前也有不少自己编写的文档积累，相信会越来越顺利。在这里要感谢博文的徐编辑一直以来给我的支持与帮助，感谢各位朋友对这本书的关注和建议，还有身边各位同事的支持与建议。 ...继续阅读 (13)

从上个月20号就开始休假回老家，彻底的过了半个月的无网络生活，开始一两天还真有点不适应，不过后面慢慢的就感觉越来越爽了，哈哈。开始的一个星期几乎每天早上都是睡到自然醒，睡的特踏实。后面慢慢起床越来越早，好好感受了一下老家乡村里面早晨那清新的空气。离开了城市的喧嚣嘈杂，感受乡村的宁静清新，这 感觉真是没得说。明天参加杭州市横渡钱塘江的活动，好久没有游泳了，还不知道能不能适应已经开始变冷的水温，希望一切顺利吧。后天又要开始投入工作了，离开这么久，肯定会有不少事情等着处理，估计还得适应个一天才能找回工作状态。 ...继续阅读 (14)