前段时间，在有幸被多人举荐并由 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 称号。
为了对核心技术拥有更多的自主控制能力，为了解决数据库的线性扩展问题，为了尽量减少对商业软件的依赖，为了摆脱对高端硬件的依赖，为了… 基于以上多种原因，2年前，我们计划将公司某核心应用平台进行大手术：数据库平台从软件到硬件全部重构。当然，这其中应用架构的改造也不可避免的进行了大换血。
这个项目无论是从技术角度还是是业务角度来说，都对我们有着非常大的价值，也必定会带来非常深远的影响。项目历时2年多，分4个阶段才完成：
- Oracle数据库中拆分（1拆16）
这个阶段本不是必要的，但是由于项目启动稍微晚了点，数据出现了爆发性增长，导致该系统的数据表太大（单表不带索引过500GB），原 Oracle 数据库已经快撑不住了。为了安全起见，先在 Oracle 中从一个主表以会员ID进行 hash 运算后再进行水平拆分，从1个表分拆成了16个。附表由于访问量稍小，而且全部是根据主键访问，暂时保留原样。
当然，这样的水平拆分，必然会带来数据访问路由以及数据合并的问题。我们专门为此开发了具有分布式数据库路由/数据合并，数据库读写分离，数据库链接管理等功能的数据访问中间层，专门解决拆分后给应用服务器带来的影响，使得应用服务器完全感受不到后端数据库的变化。
这个数据访问中间层，对前端应用服务器来说，就是一个完整的数据库，所有数据请求都从这里实现，以协议的方式和前端应用服务器的jdbc驱动进行交互，以便让数据库对应用服务器彻底透明。
- Oracle迁移至 MySQL（16拆128）
这个阶段是整个阶段中历时最长，复杂度最高，风险系数最高的，未知因素也最多的一个阶段。虽然 MySQL 数据库已经在互联网行业占据了大片江山，但是对于阿里巴巴来说，却仍然是一个新鲜玩意儿，因为之前我们一直都用 Oracle 来提供所有的业务系统的数据库服务。
在此之前，我们从来没有在如此核心业务系统的数据库上使用过 PC Server 和本地硬盘来承载数据库，一直是使用 IBM 小型机和中高端存储设备来解决高性能和高可靠的问题。在更换成 PC Server 和本地硬盘来承载数据库之后，我们就必须面对 PC Server 本身硬件可能存在的不可靠性所带来的 Crash，所以我们必须有一套完善的 HA 切换机制，要比小型机厂商所提供的商业 HA 管理软件更加高效更加自动化更加可控，才能我们降低了设备本身可靠性之后达到原有的可用性要求。
对于一个需要满足 365 * 24 * 7 的核心业务系统来说，肯定是不可能给我们太多时间来进行数据迁移的，所以我们不得不设计出一个对现有系统影响尽可能小的迁移方案，这势必会造成方案的高度复杂化，带来更多的风险。最后的迁移方案要经历如下4个阶段：
1. Oracle 读/写;；MySQL 初始化并增量写
2. Oracle 读/写； MySQL 写
3. Oracle 写； MySQL 读/写
4. Oracle 停访问； MySQL 读/写
当然，也正式由于有如此复杂的方案，才确保了在整个迁移过程中的的停机时间被控制在了10分钟之类。
- 附属Detail信息迁移至 MySQL
从项目开始，至完成主表拆分结束，已经接近2年了。这2年时间内，数据量一直都在飞涨，这让即使仅仅只是按照主键访问的附表也快无法承受持续增长的业务压力，附表的拆分也就成了必行之势。由于在原来主表拆分的过程中，整个项目组已经积累了大量的经验，附表拆分过程非常顺利，基本没有出现任何问题。虽然附表的拆分过程与主表相比除了 1拆16这个阶段外没有减少其他任何环节，但是整个拆分过程也才2个月就全部搞定了。
这个迁移项目算是彻底完成了，但是我们的迁移之路并不会就此止步，还有很多的系统仍然存在扩展性问题，还有很多的数据库应用等着我们去拆分。
注：同事们还为此送了我们一个虽不太雅但也意思相近的名称 “拆迁队”。
MySQL, oracle, 可扩展, 数据库迁移
部门同事（MySQL DBA）一次关于 MySQL Explain 分享所使用的 PPT，写得很不错。
本PPT版权所有：胡中泉
MySQL, mysql explain
最近经常有人问我 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 结果集将不会被 Cache
- query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小
- query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数
- query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下：
- 0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache
- 1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache
- 2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache
- query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。
Query Cache 如何处理子查询的？
这是我遇到的最为常见的一个问题。其实 Query Cache 是以客户端请求提交的 Query 为对象来处理的，只要客户端请求的是一个 Query，无论这个 Query 是一个简单的单表查询还是多表 Join，亦或者是带有子查询的复杂 SQL，都被当作成一个 Query，不会被分拆成多个 Query 来进行 Cache。所以，存在子查询的复杂 Query 也只会产生一个Cache对象，子查询不会产生单独的Cache内容。UNION[ALL] 类型的语句也同样如此。
Query Cache 是以 block 的方式存储的数据块吗？
不是，Query Cache 中缓存的内容仅仅只包含该 Query 所需要的结果数据，是结果集。当然，并不仅仅只是结果数据，还包含与该结果相关的其他信息，比如产生该 Cache 的客户端连接的字符集，数据的字符集，客户端连接的 Default Database等。
Query Cache 为什么效率会非常高，即使所有数据都可以 Cache 进内存的情况下，有些时候也不如使用 Query Cache 的效率高？
Query Cache 的查找，是在 MySQL 接受到客户端请求后在对 Query 进行权限验证之后，SQL 解析之前。也就是说，当 MySQL 接受到客户端的SQL后，仅仅只需要对其进行相应的权限验证后就会通过 Query Cache 来查找结果，甚至都不需要经过 Optimizer 模块进行执行计划的分析优化，更不许要发生任何存储引擎的交互，减少了大量的磁盘 IO 和 CPU 运算，所以效率非常高。
客户端提交的 SQL 语句大小写对 Query Cache 有影响吗？
有，由于 Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以必须要整个 SQL 语句在字符级别完全一致，才能在 Query Cache 中命中，即使多一个空格也不行。
一个 SQL 语句在 Query Cache 中的内容，在什么情况下会失效？
为了保证 Query Cache 中的内容与是实际数据绝对一致，当表中的数据有任何变化，包括新增，修改，删除等，都会使所有引用到该表的 SQL 的 Query Cache 失效。
为什么我的系统在开启了 Query Cache 之后整体性能反而下降了？
当开启了 Query Cache 之后，尤其是当我们的 query_cache_type 参数设置为 1 以后，MySQL 会对每个 SELECT 语句都进行 Query Cache 查找，查找操作虽然比较简单，但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性，可能由于表上的数据变化比较频繁，大量的 Query Cache 频繁的被失效，所以 Query Cache 的命中率就可能比较低下。所以有些场景下，Query Cache 不仅不能提高效率，反而可能造成负面影响。
如何确认一个系统的 Query Cache 的运行是否健康，命中率如何，设置量是否足够？
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：
- Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目
- Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量
- Qcache_hits：Query Cache 命中次数
- Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数
- Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
- Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
- Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量
- Qcache_total_blocks：Query Cache 中总的 Block 数量
可以根据这几个状态计算出 Cache 命中率，计算出 Query Cache 大小设置是否足够，总的来说，我个人不建议将 Query Cache 的大小设置超过256MB，这也是业界比较常用的做法。
MySQL Cluster 是否可以使用 Query Cache？
其实在我们的生产环境中也没有使用 MySQL Cluster，所以我也没有在 MySQL Cluster 环境中使用 Query Cache 的实际经验，只是 MySQL 文档中说明确实可以在 MySQL Cluster 中使用 Query Cache。从 MySQL Cluster 的原理来分析，也觉得应该可以使用，毕竟 SQL 节点和数据节点比较独立，各司其职，只是 Cache 的失效机制会要稍微复杂一点。
之前说起 将参加 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，更换转速更快的磁盘…）
- 向外扩展（Scale Out）
- 数据拷贝分发（一处写入多处读取，读写分离…）
- 数据垂直/水平切分（功能模块切分（vertical sharding），水平分片切分（horizontal sharding），两者综合）
- Cache 和 Search（应用程序更新Cache，数据库更新 Cache，利用Search全文搜索…）
对于扩展性，Scale Up基本上就是各个厂商自身单台设备扩容能力的比拼，我们没有太多能力干预，所以我也只是简单分析了一下。
而对于 Scale Out，我想肯定是大家最关心的问题了。而Scale Out 中的 Sharding ，我想大家肯定也不是第一次听到，毕竟不是什么新东西了。
我这里重点介绍的是Sharding过程中如何选择合适的Sharding方法，如何解决Sharding之后的数据合并问题（其实没有解决，囧…），以及如何利用数据库外部资源（Cache,Search）来解决数据层的扩展性问题。
其实架构这个东西本身就是 仁者见仁智者见智，没有万能的架构，也没有长久适用的架构。架构和业务场景息息相关密不可分，离开了实际业务场景谈架构，可以说就是纸上谈兵，那如果离开了架构仅仅追求快速的业务实现呢？呵呵，出来混，迟早要还的。
注：我本身不是什么架构师，占用大家那么多宝贵时间听我扯淡架构，挺感动的…
Architecture, dtcc, MySQL Replication, 主题演讲, 架构
