Archive for November, 2008
MySQL5.1 Generally Available (GA) release for production use
Thursday, November 27th, 2008
早上同事问我在哪里可以找到 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 use
Upcoming Releases
MySQL 6.0 — Alpha
MySQL Maria Preview
Snapshots — source code snapshots of the development trees
Glassfish+MySQL bundle — developers edition
Older Releases
MySQL 5.0 — Previous GA release
MySQL [...]
MyISAM 索引结构了解 - MyISAM Index Structure
Wednesday, November 26th, 2008
在此之前曾经写过一篇介绍 “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）来定位固定长度表数据的行，另外一种是通过其他一些相对的文件位置标识信息来定位动态长度表数据的行，这里我们姑且将两种方式统称为 RID（Row ID）吧。
下面这张图片展示了 MyISAM 索引的基本存储方式：
[...]
MySQL ORDER BY 的实现分析
Saturday, November 22nd, 2008
总的来说，在 MySQL 中的ORDER BY有两种排序实现方式，一种是利用有序索引获取有序数据，另一种则是通过相应的排序算法，将取得的数据在内存中进行排序。
下面将通过实例分析两种排序实现方式及实现图解：
假设有 Table A 和 B 两个表结构分别如下：
sky@localhost : example 01:48:21> show create table A\G
*************************** 1. row ***************************
Table: A
Create Table: CREATE TABLE `A` (
`c1` int(11) NOT NULL default ‘0′,
`c2` char(2) default NULL,
`c3` varchar(16) default NULL,
`c4` datetime default NULL,
PRIMARY KEY (`c1`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
sky@localhost : example 01:48:32> show create table B\G
*************************** 1. row ***************************
Table: B
Create [...]
2009 TEAM 关键字
Friday, November 21st, 2008
2008是 专业、严谨、高效
2009加入创新： 专业、严谨、创新、高效
Innodb 索引结构了解 - Innodb Index Structure
Tuesday, November 18th, 2008
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 两种索引的比较。
原文出自： Innodb 索引结构了解 - Innodb Index Structure
MySQL 的 DW 解决方案(MySQL + Infobright)
Friday, November 14th, 2008
随着 BI (DW) 在各个企业中重要性的不断提升，各个数据库厂家都希望能搭上这辆班车。这不，MySQL 也联合 Infobright 一起推出了开源的 数据仓库解决方案，而且是开源的。
其实现的各种DW该有的功能就不多说了，但是 Infobright 有一点非常吸引人的技术特点不能不提，那就是以列为导向的架构设计。
以列为导向的架构设计是非常适合于DW应用场景的，对于大多数DW的分析场景中，实际关注的数据很多时候都只有那么一列或者少数几列的数据。所以在以列为导向的设计中，大部分的分析查询都只需要读取某一个（或者几个）表的几列，而不需要像传统以行为导向的数据库（或者存储引擎）那样需要扫描整个表的数据，这两者IO量的差距是非常大的。除了以列为导向的架构设计之外，Infobright 和很多其他的DW解决方案一样，也会进行数据压缩，而且由于其以列为导向的存储方式，压缩比率在很多情况下都会比以行为导向的存储方式更高，效果更理想。有人通过测试比较，常规的以行为导向的存储数据压缩比率较高的时候也就 3:1 左右，但是 Infobright 的却很容易就做到 10:1 的压缩比率。
此外，从MySQL 以及 Infobright 的官方报道中除了上述技术特点（或者说优势）之外，还有很多其他的被描绘的非常神奇的功能，如被称为 “知识网格” (Knowledge Grid) 的自我管理功能，完全不需要索引或者分区，神奇的自我查询优化器等等。
这里是官方给出的一张 Infobright 的架构图：
感兴趣的朋友可以通过自行阅读其 技术白皮书 获取更多的细节
原文链接：MySQL 的 DW 解决方案(MySQL + Infobright)
