Archive for 十月 2011

mysql事件类型和文件头长度

附录

附录1 MySQL 5.1.20 Beta包含的事件类型

下面列举了各种MySQL的事件类型(代码拷贝自MySQL 5.1.20的源代码):

enum Log_event_type

{

/*

Every time you update this enum (when you add a type), you have to

fix Format_description_log_event::Format_description_log_event().

*/

UNKNOWN_EVENT= 0,

START_EVENT_V3= 1,

QUERY_EVENT= 2,

STOP_EVENT= 3,

ROTATE_EVENT= 4,

INTVAR_EVENT= 5,

LOAD_EVENT= 6,

SLAVE_EVENT= 7,

CREATE_FILE_EVENT= 8,

APPEND_BLOCK_EVENT= 9,

EXEC_LOAD_EVENT= 10,

DELETE_FILE_EVENT= 11,

/*

NEW_LOAD_EVENT is like LOAD_EVENT except that it has a longer

sql_ex, allowing multibyte TERMINATED BY etc; both types share the

same class (Load_log_event)

*/

NEW_LOAD_EVENT= 12,

RAND_EVENT= 13,

USER_VAR_EVENT= 14,

FORMAT_DESCRIPTION_EVENT= 15,

XID_EVENT= 16,

BEGIN_LOAD_QUERY_EVENT= 17,

EXECUTE_LOAD_QUERY_EVENT= 18,

TABLE_MAP_EVENT = 19,

/*

These event numbers were used for 5.1.0 to 5.1.15 and are

therefore obsolete.

*/

PRE_GA_WRITE_ROWS_EVENT = 20,

PRE_GA_UPDATE_ROWS_EVENT = 21,

PRE_GA_DELETE_ROWS_EVENT = 22,

/*

These event numbers are used from 5.1.16 and forward

*/

WRITE_ROWS_EVENT = 23,

UPDATE_ROWS_EVENT = 24,

DELETE_ROWS_EVENT = 25,

/*

Something out of the ordinary happened on the master

*/

INCIDENT_EVENT= 26,

/*

Add new events here – right above this comment!

Existing events (except ENUM_END_EVENT) should never change their numbers

*/

ENUM_END_EVENT /* end marker */

};

附录2 MySQL 5.1.20 Beta各事件的附加事件头长度

下面列举了MySQL 5.1.20 Beta各事件的附加事件头长度(拷贝自MySQL源代码):

/* event-specific post-header sizes */

// where 3.23, 4.x and 5.0 agree

#define QUERY_HEADER_MINIMAL_LEN (4 + 4 + 1 + 2)

// where 5.0 differs: 2 for len of N-bytes vars.

#define QUERY_HEADER_LEN (QUERY_HEADER_MINIMAL_LEN + 2)

#define LOAD_HEADER_LEN (4 + 4 + 4 + 1 +1 + 4)

#define START_V3_HEADER_LEN (2 + ST_SERVER_VER_LEN + 4)

#define ROTATE_HEADER_LEN 8 // this is FROZEN (the Rotate post-header is frozen)

#define CREATE_FILE_HEADER_LEN 4

#define APPEND_BLOCK_HEADER_LEN 4

#define EXEC_LOAD_HEADER_LEN 4

#define DELETE_FILE_HEADER_LEN 4

#define FORMAT_DESCRIPTION_HEADER_LEN (START_V3_HEADER_LEN+1+LOG_EVENT_TYPES)

#define ROWS_HEADER_LEN 8

#define TABLE_MAP_HEADER_LEN 8

#define EXECUTE_LOAD_QUERY_EXTRA_HEADER_LEN (4 + 4 + 4 + 1)

#define EXECUTE_LOAD_QUERY_HEADER_LEN (QUERY_HEADER_LEN + EXECUTE_LOAD_QUERY_EXTRA_HEADER_LEN)

#define INCIDENT_HEADER_LEN 2

post_header_len[START_EVENT_V3-1]= START_V3_HEADER_LEN;

post_header_len[QUERY_EVENT-1]= QUERY_HEADER_LEN;

post_header_len[ROTATE_EVENT-1]= ROTATE_HEADER_LEN;

post_header_len[LOAD_EVENT-1]= LOAD_HEADER_LEN;

post_header_len[CREATE_FILE_EVENT-1]= CREATE_FILE_HEADER_LEN;

post_header_len[APPEND_BLOCK_EVENT-1]= APPEND_BLOCK_HEADER_LEN;

post_header_len[EXEC_LOAD_EVENT-1]= EXEC_LOAD_HEADER_LEN;

post_header_len[DELETE_FILE_EVENT-1]= DELETE_FILE_HEADER_LEN;

post_header_len[NEW_LOAD_EVENT-1]= post_header_len[LOAD_EVENT-1];

post_header_len[FORMAT_DESCRIPTION_EVENT-1]= FORMAT_DESCRIPTION_HEADER_LEN;

post_header_len[TABLE_MAP_EVENT-1]= TABLE_MAP_HEADER_LEN;

post_header_len[WRITE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

post_header_len[UPDATE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

post_header_len[DELETE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

/*

We here have the possibility to simulate a master of before we changed

the table map id to be stored in 6 bytes: when it was stored in 4

bytes (=> post_header_len was 6). This is used to test backward

compatibility.

This code can be removed after a few months (today is Dec 21st 2005),

when we know that the 4-byte masters are not deployed anymore (check

with Tomas Ulin first!), and the accompanying test (rpl_row_4_bytes)

too.

*/

DBUG_EXECUTE_IF(“old_row_based_repl_4_byte_map_id_master”,

post_header_len[TABLE_MAP_EVENT-1]=

post_header_len[WRITE_ROWS_EVENT-1]=

post_header_len[UPDATE_ROWS_EVENT-1]=

post_header_len[DELETE_ROWS_EVENT-1]= 6;);

post_header_len[BEGIN_LOAD_QUERY_EVENT-1]= post_header_len[APPEND_BLOCK_EVENT-1];

post_header_len[EXECUTE_LOAD_QUERY_EVENT-1]= EXECUTE_LOAD_QUERY_HEADER_LEN;

post_header_len[INCIDENT_EVENT-1]= INCIDENT_HEADER_LEN;

附录3 MySQL 5.1.20 Beta中各列在内部存储时可能的各种数据类型

enum enum_field_types

{

MYSQL_TYPE_DECIMAL = 0,

MYSQL_TYPE_TINY = 1,

MYSQL_TYPE_SHORT = 2,

MYSQL_TYPE_LONG = 3,

MYSQL_TYPE_FLOAT = 4,

MYSQL_TYPE_DOUBLE = 5,

MYSQL_TYPE_NULL = 6,

MYSQL_TYPE_TIMESTAMP = 7, // 4 from_unixtime(0x)

MYSQL_TYPE_LONGLONG = 8,

MYSQL_TYPE_INT24 = 9, //field_medium

MYSQL_TYPE_DATE = 10,

MYSQL_TYPE_TIME = 11,

MYSQL_TYPE_DATETIME = 12,

MYSQL_TYPE_YEAR = 13,

MYSQL_TYPE_NEWDATE = 14,

MYSQL_TYPE_VARCHAR = 15, //field_varstring

MYSQL_TYPE_BIT = 16,

MYSQL_TYPE_NEWDECIMAL = 246,

MYSQL_TYPE_ENUM = 247,

MYSQL_TYPE_SET = 248,

MYSQL_TYPE_TINY_BLOB = 249,

MYSQL_TYPE_MEDIUM_BLOB = 250,

MYSQL_TYPE_LONG_BLOB = 251,

MYSQL_TYPE_BLOB = 252,

MYSQL_TYPE_VAR_STRING = 253,

MYSQL_TYPE_STRING = 254,

MYSQL_TYPE_GEOMETRY = 255,

};

附录4 MySQL 5.1.20 Beta中各ROW_EVENTm_flags包含的标志位

MySQL 5.1.20 Beta中,各ROW_EVENT都含有m_flags标志位集合。可能的标志如下:

名称

含义

STMT_END_F

1

语句执行结束标志

NO_FOREIGN_KEY_CHECKS_F

2

不进行外键约束检查的标志

RELAXED_UNIQUE_CHECKS_F

4

不进行唯一键约束检查的标志

相关代码如下:

/*

These definitions allow you to combine the flags into an

appropriate flag set using the normal bitwise operators. The

implicit conversion from an enum-constant to an integer is

accepted by the compiler, which is then used to set the real set

of flags.

*/

enum enum_flag

{

/* Last event of a statement */

STMT_END_F = (1U << 0),

/* Value of the OPTION_NO_FOREIGN_KEY_CHECKS flag in thd->options */

NO_FOREIGN_KEY_CHECKS_F = (1U << 1),

/* Value of the OPTION_RELAXED_UNIQUE_CHECKS flag in thd->options */

RELAXED_UNIQUE_CHECKS_F = (1U << 2)

};

typedef uint16 flag_set;

/* Special constants representing sets of flags */

enum

{

RLE_NO_FLAGS = 0U

};

mysql replication数据复制格式



















1.1MySQL
replication
数据复制格式



这里我们基于MySQL
5.1.20
Beta
描述MySQL两个slave端的thread发送和接收数据的格式。某些字段所占的字节数跟MySQL的版本有关,这里我们所描述的为binlog版本为4MySQL
server
版本为5.1.20
Beta
下的数据格式。


1.1.1MySQL
I/O thread
数据格式


1.1.1.1向主服务器注册自己



向主服务器注册自己并不是一个必须的操作,如果没有注册同样可以向主服务器请求数据。如果需要向主服务器注册,那么可以调用mysql.h中的simple_command(mysql,
command, arg, length,
skip_check)
函数,在arg参数中依序填入下述的各个字段,并指定其中的参数commandCOM_REGISTER_SLAVE以注册自己。



































































名称




字节数




含义




server_id




4




MySQL
instance
server_id




strlen(report_host)




1 or
2




标识接下来的report_host的长度,如果长度<2511个字节,否则占两个字节




report_host




Strlen(report_host)




向主服务器注册的MySQL
instance
标识




strlen(report_user)




1 or
2




标识接下来的report_user的长度,如果长度<2511个字节,否则占2个字节




report_user




Strlen(report_user)




向主服务器注册的用户名




strlen(report_password)




1 or
2




标识接下来的report_password的长度,如果长度<2511个字节,否则占2个字节




report_password




Strlen(report_password)




向主服务器注册的密码




report_port




2




向主服务器注册的端口




rpl_recovery_rank




4




复制的恢复等级




master_id




4




填入0,主服务器将自行填入master_id




1、主服务器注册示意图







1.1.1.2向主服务器请求数据



从服务器向主服务器发送了请求数据的命令以后主服务器将根据要求将对应binlog文件的指定位置开始的事件记录发送给从服务器。向主服务器请求数据,可以调用mysql.h中的simple_command(mysql,
command, arg, length,
skip_check)
函数,在arg参数中依序填入下述的各个字段,并指定其中的参数commandCOM_BINLOG_DUMP





































名称




字节数




含义




master_log_pos




4




请求主服务器发送的事件记录在binlog文件中的偏移量




binlog_flags




2




暂时填0,做扩展用




server_id




4




MySQL
instance
server_id




logname




Strlen(logname)




请求主服务器发送的binlog文件的文件名




如果没有指定MySQL使用methods,那么我们应该调用函数sql_common.h头文件中的cli_advanced_command()代替simple_command()。



向主服务器请求了数据以后,从服务器就可以通过cli_safe_read(mysql);获得主服务器发送过来的数据,每次获得一个事件记录的数据。cli_safe_read的返回值标示了从主服务器发送过来的数据的数据字节数。而发送过来的数据保存在mysql->net->read_pos数组中。I/O
thread
模块可以利用MySQLio_cache将对应事件记录存储到relay-log文件中。






1.1.1.3MySQL
binlog
文件初始化



由于MySQL
binlog
的特殊性,以及为了mysqlbinlog工具能够识别我们relay-log文件,在新建一个relay-log文件时必须写入一定的初始化数据。这些初始化数据依序包括如下字段:


















名称




字节数




含义




BINLOG_MAGIC("\xfe\x62\x69\x6e")




BIN_LOG_HEADER_SIZE(4)




Binlog文件的标识值







1.1.2MySQL
SQL thread
数据格式



只要循环的调用cli_safe_read函数,从服务器可以不断得到从主服务器发送过来的事件记录。接下来我们介绍一下相关的一些事件记录格式。在提交了COM_BINLOG_DUMP命令后,主服务器首先给从服务器发送的两个事件依序分别为ROTATE_EVENTFORMAT_DESCRIPTION_EVENT事件。ROTATE_EVENT事件用来标示接下来主服务器将从哪一个binlog文件的哪个位置开始发送事件记录。而FORMAT_DESCRIPTION_EVENT事件用来记录本MySQL
instance
server_id值,binlog版本号,MySQL
server
的版本,本relay-log创建的时间以及各个不同事件的事件头所占的字节数等信息。我们关心的其他的事件记录的格式包括WRITE_ROWS_EVENTUPDATE_ROWS_EVENTDELETE_ROWS_EVENT等。






1.1.2.1事件头字段描述



各个事件都包括一个事件头,事件头的字段格式如下:











































名称




字节数




含义




When




4




事件的创建时间。




Type




1




事件的类型(见附录1)




server_id




4




事件发生时所在MySQLserver_id值。




data_written




4




该事件一共占用的字节数,包括事件头的字节数。




log_pos




4




下一事件在binlog文件中将要开始的位置,即本事件的结束位置




Flags




2




事件的其他标志位。







1.1.2.2ROTATE_EVENT事件字段描述



由于各个事件的事件头基本一致,这里我们就不重复介绍事件头的各字段了,后面的各个事件我们也都将忽略对事件头字段的描述。



ROTATE_EVENT事件的附加事件头字段主要包括:


















名称




字节数




含义




pos




8




主服务器将要发送的事件记录在binlog文件中的偏移量。一般为从服务器提交的COM_BINLOG_DUMP请求中的偏移量值。




ROTATE_EVENT事件的其他信息字段主要包括:


















名称




字节数




含义




new_log_ident




strlen(new_log_ident)




主服务器将要发送的事件记录的binlog文件名。一般为从服务器提交的COM_BINLOG_DUMP请求中的binlog文件名。







1.1.2.3FORMAT_DESCRIPTION_EVENT事件字段描述



FORMAT_DESCRIPTION_EVENT事件的附加事件头的字段如下:






































名称




字节数




含义




binlog_version




2




Binlog文件的版本号,这里一般为最新的版本号4




server_version




ST_SERVER_VER_LEN(50)




MySQL的版本号。例如:”
5.1.20-beta-log”




Created




4




事件创建时间,这里一般和事件头中的when一致




event_header_len




1




一般事件的事件头长度,一般设置为:LOG_EVENT_HEADER_LEN(19)




post_header_len




ENUM_END_EVENT-1(26)




不同事件类型的附加事件头的长度,见附录2








1.1.2.4TABLE_MAP_EVENT事件字段描述



TABLE_MAP_EVENT事件的附加事件头的字段如下:























名称




字节数




含义




m_table_id




6(5.1.4前的版本中为4)




表的id标识符




m_flags




2




表的各种标志位,见附录4




TABLE_MAP_EVENT事件的其他信息字段主要包括:











































名称




字节数




含义




m_dblen




1




数据库名的长度




m_dbnam




m_dblen+1




数据库名,以’\0’结尾




m_tbllen




1




表名的长度




m_tblnam




m_tbllen+1




表名,以’\0’结尾




m_colcnt




net_field_length()




表的字段个数,所占字节数根据第一个字节的大小由net_field_length函数确定




m_coltype




m_colcnt




表的各个字段的字段类型,参见附录3








1.1.2.5WRITE_ROWS_EVENT事件字段描述



WRITE_ROWS_EVENT事件的附加事件头的字段如下:























名称




字节数




含义




m_table_id




6(5.1.4前的版本中为4)




表的id标识符




m_flags




2




表的各种标志位,见附录4




WRITE_ROWS_EVENT事件的其他信息字段主要包括:




























名称




字节数




含义




m_width




net_field_length()




表的各列的位图长度,所占字节数根据第一个字节的大小由net_field_length函数确定




m_cols.bitmap




(m_width
+ 7) / 8




表的各列的位图,每一位表示m_rows_buf是否包含表中一列的值,如果没有置位表示该列的值没有包含在m_rows_buf




m_rows_buf




剩余字节数(len-已占字节数)




将要插入到表中的一行数据值。







1.1.2.6UPDATE_ROWS_EVENT事件字段描述



UPDATE_ROWS_EVENT事件的附加事件头的字段如下:























名称




字节数




含义




m_table_id




6(5.1.4前的版本中为4)




表的id标识符




m_flags




2




表的各种标志位,见附录4




UPDATE_ROWS_EVENT事件的其他信息字段主要包括:

































名称




字节数




含义




m_width




net_field_length()




表的各列的位图长度,所占字节数根据第一个字节的大小由net_field_length函数确定




m_cols.bitmap




(m_width
+ 7) / 8




表中被匹配行数据的各列的位图,每一位表示m_rows_buf是否包含表中该列的值。




m_cols_ai.bitmap




(m_width
+ 7) / 8




表中将要更新的行数据的各列的位图,每一位表示m_rows_buf是否包含表中一列的值。




m_rows_buf




剩余字节数(len-已占字节数)




表中被匹配的那一行数据的值以及将要更新的一行数据值。








1.1.2.7DELETE_ROWS_EVENT事件字段描述



DELETE_ROWS_EVENT事件的附加事件头的字段如下:























名称




字节数




含义




m_table_id




6(5.1.4前的版本中为4)




表的id标识符




m_flags




2




表的各种标志位




DELETE
_ROWS_EVENT
事件的其他信息字段主要包括:




























名称




字节数




含义




m_width




net_field_length()




表的各列的位图长度,所占字节数根据第一个字节的大小由net_field_length函数确定




m_cols.bitmap




(m_width
+ 7) / 8




表的各列的位图,每一位表示m_rows_buf是否包含表中一列的值。




m_rows_buf




剩余字节数(len-已占字节数)




表中将要删除的一行数据值。







1.1.2.8XID_EVENT事件字段描述



XID_EVENT一般出现在一个事务操作(transaction)之后或者其他语句提交之后。它的主要作用是提交事务操作和把事件刷新至binlog文件中。



XID_EVENT事件的信息字段包括:


















名称




字节数




含义




xid




sizeof(xid)
8




commit标识符











5




MySQL 5.1的新特性

把08年左右自己写的东西翻出来凑个数,主要是翻译的MySQL reference相关章节

MySQL 5.1的新特性
MySQL在版本5.1中增加了很多新特性,其中的row based replication是mmrd要求必须满足的条件。目前为止,也许是出于谨慎或者稳定性的目的,MySQL 5.1虽然已经出到版本5.1.26了,仍然是Release Candidate Development Release,不能用于生产环境。不过SUN和MySQL公司还是声称将于近期推出可供生产环境使用的Release版本。下面我们列出主要的MySQL的主要新特性并进行简单介绍。

Partitioning分区
数据库分区是一种物理数据库设计技术,虽然分区技术可以实现很多效果,但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。分区主要有两种形式:(这里一定要注意行和列的概念(row是行,column是列))
水平分区(Horizontal Partitioning):这种形式分区是对表的行进行分区,通过这样的方式不同分组里面的物理列分割的数据集得以组合,从而进行个体分割(单分区)或集体分割(1个或多个分区)。所有在表中定义的列在每个数据集中都能找到,所以表的特性依然得以保持。举个简单例子:一个包含十年发票记录的表可以被分区为十个不同的分区,每个分区包含的是其中一年的记录。
垂直分区(Vertical Partitioning):这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度,使某些特定的列被划分到特定的分区,每个分区都包含了其中的列所对应的行。举个简单例子:一个包含了大text和BLOB列的表,这些text和BLOB列又不经常被访问,这时候就要把这些不经常使用的text和BLOB了划分到另一个分区,在保证它们数据相关性的同时还能提高访问速度。
在数据库供应商开始在他们的数据库引擎中建立分区(主要是水平分区)时,DBA和建模者必须设计好表的物理分区结构,不要保存冗余的数据(不同表中同时都包含父表中的数据)或相互联结成一个逻辑父对象(通常是视图)。这种做法会使水平分区的大部分功能失效,有时候也会对垂直分区产生影响。
分区带来的好处有很多,这里列出两点:
性能的提升(Increased performance):在扫描操作中,如果MySQL的优化器知道哪个分区中才包含特定查询中需要的数据,它就能直接去扫描那些分区的数据,而不用浪费很多时间扫描不需要的地方 了。需要举个例子,百万行的表划分为10个分区,每个分区就包含十万行数据,那么查询分区需要的时间仅仅是全表扫描的十分之一了,很明显的对比。同时对十万行的表建立索引的速度也会比百万行的快得多得多。如果你能把这些分区建立在不同的磁盘上,这时候的I/O读写速度就提升很多了。
对数据管理的简化(Simplified data management):分区技术可以让DBA对数据的管理能力提升。通过优良的分区,DBA可以简化特定数据操作的执行方式。例如:DBA在对某些分区的内容进行删除的同时能保证余下的分区的数据完整性(这是跟对表的数据删除这种大动作做比较的)。
此外分区是由MySQL系统直接管理的,DBA不需要手工的去划分和维护。

Row-based replication
MySQL5.1以前的replication都是statement replication,它把在master端提交的语句记录到binlog并传播到它的各个salve服务器,slave服务器读取并翻译提交对应的statement语句。从5.1.5开始,MySQL就支持另一种复制手段:row-based replication。这种复制方式不同于statement replication,它在binlog中记录的是修改更新语句对MySQL数据表行数据的影响,实际上记录的是表结构信息和具体的各行数据信息。在5.1.8中还推出了两种方式的组合mixed形式的复制并做为MySQL 5.1的缺省复制模式。它默认采用statement replication,而只有在特别的情况下才采用row-based replication。
行复制的引入能够避免一些master和slave环境不同引起的问题的出现,所有的字段和对应的值都被复制到slave段,从而保持slave和master数据的一致性。

Plugin API.
MySQL5.1提供了一套灵活的plugin api,它可以在不重启服务器的基础上实时地装载和卸载各种不同的组件。这些plugin API可以包括(不限于):全文检索,存储引擎和服务器扩展等方面。例如:plugin full-text parsers就允许用户在索引文本上添加他们自己的输入过滤器,从而可以在PDF或者其他文件类型的文本上实现全文检索的目的。pre-parser full-text plugin将从文本中分析和抽取出具体的信息并传给MySQL本身的全文检索模块。

Event scheduler
事件调度器是在 MySQL 5.1中新增的另一个特色功能,可以作为定时任务调度器,取代部分原先只能用操作系统任务调度器才能完成的定时功能。例如,Linux中的crontab只能精确到每分钟执行一次,而MySQL的事件调度器则可以实现每秒钟执行一个任务,这在一些对实时性要求较高的环境下就非常实用了。
事件调度器是定时触发执行的,在这个角度上也可以称作是”临时的触发器”。触发器只是针对某个表产生的事件执行一些语句,而事件调度器则是在某一个 (间隔)时间执行一些语句。事件是由一个特定的线程来管理的,也就是所谓的”事件调度器”。启用事件调度器后,拥有 SUPER 权限的账户执行SHOW PROCESSLIST就可以看到这个线程了。通过设定全局变量event_scheduler 的值即可动态的控制事件调度器是否启用。

Server log tables
在版本5.1之前,MySQL的general query log和slow query log都是写在日志文件中的。5.1中就灵活多了。日志记录可以写在日志文件中,也可以写在mysql数据库中的表general_log和slow_log中。如果开启了logging的功能,用户可以选择它们其中的一个或者全都记录对应的日志信息。可以通过控制选项–log-output来决定日志信息的记录方式。

Upgrade program
mysql_upgrade工具可以检查所有现有数据表来查看它是否与现有的MySQL服务器的版本兼容,并且在必要的时候修复它们。在每一次MySQL升级时,都应该使用该工具来检查一下。

MySQL Cluster replication
Replication现在可以支持MySQL cluster之间的复制机制了,并且,现在也支持在MySQL cluster和非cluster之间的复制。

MySQL Cluster disk data storage
在MySQL 5.1.6版本以前,NDBCLUSTER存储引擎只能在内存中使用。之后,cluster的数据就可以存储在磁盘上了(不包括索引数据)。这使得MySQL cluster对内存的依赖减少了。
Improved backups for MySQL Cluster
在老版本的MySQL cluster中,cluster数据备份过程中单个节点的错误将导致整个备份过程的失败。但是新版本中不会出现这个问题。

MySQL Cluster NDB 6.x
在MySQL Cluster NDB 6.x中改进了很多并且还增加了一些新的特性。

Backup of tablespaces
mysqldump现在支持导出tablespaces的选项。可以使用-Y或者–all-tablespaces来启用该功能。

Improvements to INFORMATION_SCHEMA
相比5.0,5.1版本的MySQL在它的元数据数据库information_schema中提供了更多的信息。在这个数据库中新的数据表包括:FILES, EVENTS, PARTITIONS, PROCESSLIST, ENGINES, and PLUGINS.

XML functions with XPath support
在MySQL 5.1中,可以利用ExtractValue()返回匹配XPath串中XML片段的内容。也可以使用UpdateXML()来用一个XML片段元素来替换XPath串中的某一段XML片段元素,并返回替换后的串。

Load emulator
mysqlslap工具用来模拟客户端压力并报告每一步的时间消耗。它模拟很多个client连接MySQL server的情况。