1. MySQL Handler Socket
&
MySQL 5.5 部分新特性介绍
完美世界 顾春江
guchunjiang@wanmei.com

2. ● Handler Socket 项目的意义
● Handler Socket 实现的途径
● MySQL Plugin 体系简介
● MySQL 5.5 新引入的 semi­sync 复制
● MySQL 5.5 值得关注的几个参数及性能变化

3. Handler Socket 出现的意义
●众所周知 RDBMS 的 SQL 引擎存取代价大，对轻量 k/v
型数据没有较好的应用模式
MySQL 和 Memcached 整合后， MC 的数据一致性问
●
题，服务器管理，可用性管理都需要考虑
Memcached 的持久化问题
●
●最好有一种方式能跳过 MySQL 耗时的 SQL 语法解析
器而直接访问存储层

5. 性能瓶颈
● 对于 k/v 式操作，即使是用了 prepared
statement， 或者 query cache 等各种优化，
每秒执行语句的速度也是 Memcache 的4-5分
之一左右
Vmstat 中 user 的 CPU 时间比 sys 时间多不
●
少，因此各种 mutex lock 并非是影响性能的主
要瓶颈

6. $mysqlslap --query="select user_name from test.user
where user_id=1000" –number-of-queries=10000000
--concurrency=30 --host=mysql15 -uxxx -p
$mysqladmin extended-status -i 1 -r -uroot | grep -e
"Com_select"
| Com_select | 86234 |
| Com_select | 82345 |
| Com_select | 85972 |
| Com_select | 84270 |
| Com_select | 84281 |
| Com_select | 83951 |
通过正常的 SQL 接口， MySQL 可以达到84 k/s 的读取次数
$ vmstat 1
us sy id wa st
55 36 9 0 0
53 34 13 0 0
vmstat 的 user 时间占了一半多

7. 资源都消耗在哪里
用 OProfile 查看系统调用
samples % app name symbol name
259130 4.5199 mysqld MYSQLparse(void*)
196841 3.4334 mysqld my_pthread_fastmutex_lock
106439 1.8566 libc-2.5.so _int_malloc
67945 1.1851 mysqld ...make_join...
63435 1.1065 mysqld JOIN::optimize()
55825 0.9737 vmlinux wakeup_stack_begin
55054 0.9603 mysqld MYSQLlex(void*, void*)
可以看到， SQL 解析相关的调用占了大部分 CPU 时
间，如果能跳过 SQL 解析层就能好很多

8. 如何降低查询开销
一般 MySQL 客户端进行查询，有如下过程:
● SQL Parser 解析 SQL 语句
● 打开表对象句柄，申请 mutex
● 根据表信息生成 SQL 执行计划
● IO 读写
● 释放 mutex， 关闭表对象句柄
这5个步骤中，只有第四步是 IO 向的，其余
都是 CPU 向。

9. MySQL 为能够自定义存储引擎，有一个 Handler 结构专门抽象
了底层存储引擎的各个通用接口， SQL 解析器只要调用
handlerton(handler singleton) 这个结构体就可以和各种底层存储
引擎交互。
handlerton example_hton= {
"EXAMPLE",
"Example storage engine",
DB_TYPE_EXAMPLE_DB,
...
NULL, /* commit */
NULL, /* rollback */
NULL, /* prepare */
/* Create a new handler */
example_create_handler,
...
};
Handler Socket 底层就是基于这个接口来实现的。

11. HS 以插件形式启动，启动后监听2个特殊端口，分别接受读请
●
求和写请求，并且 fork 出可配置数量的服务线程
●这些服务线程将轮番处理客户端请求，并对多次分散的请求做
合并处理
HS 不会不停地打开/关闭表对象句柄，它在打开后会保持一段
●
时间，如果在一段时间内没有请求才会关闭，以方便句柄重用
● HS 自己实现了一套基于文本的通信协议（类似 Memcached 的
协议，很简洁，不用构建语法树也不需要优化），支持 telnet 的
调试
open_index <indexid> <dbname> <tablename>
<indexname> <columns> [<fcolumns>]

13. 测试效果:
创建带主键的 InnoDB 表，插入随机数据5,000,000条，通过 HS 端口
$ mysqladmin extended-status -uxxx -p -i 1 -r | grep
"InnoDB_rows_read"
| Innodb_rows_read | 328512 |
| Innodb_rows_read | 340128 |
| Innodb_rows_read | 312134 |
| Innodb_rows_read | 338072 |
| Innodb_rows_read | 342387 |
| Innodb_rows_read | 399023 |
| Innodb_rows_read | 312494 |
| Innodb_rows_read | 353918 |
SQL 引擎 84270 op/s
HandlerSocket 338072 op/s

14. 再看 OProfile 的数据:
847486 5.0876 ha_innodb_plugin. ut_delay
545303 3.2735 ha_innodb_plugin. btr_search_guess_on_hash
317570 1.9064 ha_innodb_plugin. row_search_for_mysql
298271 1.7906 vmlinux tcp_ack
291739 1.7513 libc-2.5.so vfprintf
264704 1.5891 vmlinux .text.super_90_sync
248546 1.4921 vmlinux blk_recount_segments
244474 1.4676 libc-2.5.so _int_malloc
发现原来占用 CPU 时间非常多的几个 SQL 解析调用都已经不在列表上
了，而且此时的 vmstat 数据 sys 占了几乎80%左右的 CPU 时间，说明
优化已经奏效。

15. HandlerSocket 的特点
● 性能卓越
● 不再有重复的 Cache， 数据保持一致
● 不影响正常数据库功能的使用
● 以插件的形式存在
● 内置线程池
● 利用 MySQL 的 Handler 接口，和底层引擎
类型无关

16. Handler Socket 的限制
● 缺乏安全性
● 对于磁盘 IO 向的场景没有效果
● 性能瓶颈从 CPU 向转到网卡向
● 加重 slave 的复制压力

17. MySQL Plugin 体系介绍

18. MySQL Plugin 类型
● Daemon Plugins
● INFORMATION_SCHEMA Plugins
● Storage Engine Plugins
● Full­Text Parser Plugins
● Audit Plugins
● Authentication Plugins
● Replication Plugins

19. MySQL Server
st_mysql_plugin demo1= st_mysql_plugin demo2=
{ {
Int type; Int type;
void *info; void *info;
... ...
} }
Binlog_transmit_observer {
rpl_stat_transmit_start,
NULL,
NULL,
rpl_stat_before_send_event,
...
}

20. MySQL Plugin essentials
mysql_declare_plugin(demo_plugin)
{
MYSQL_DAEMON_PLUGIN,
&simple_parser_descriptor,
"simple_parser",
"Some Corporation",
"Simple DAEMON Plugin",
PLUGIN_LICENSE_GPL,
simple_parser_plugin_init,
simple_parser_plugin_deinit,
0x0001,
simple_status,
simple_system_variables,
NULL
}
mysql_declare_plugin_end;

21. MySQL 5.5 Semi­Sync

22. MySQL 5.5 Semi­Sync
● 修改了原生复制的 packet header, 添加
BINLOG_SEMI_SYNC 0x02
● session 事务提交成功，如果至少有一个开启
了 semi­sync 的 slave 的 io thread 接收到
commit 复制事件
● 如果 master 等待 ack 超时，事务会被提
交， semi­sync 将被自动关闭，直到有一个
slave 跟上 master
● 支持 GROUP COMMIT

23. MySQL 5.5 Semi­Sync

24. semi­sync 效率
1200000
1110723
1000000
800000
异步
600000
semi­sync
504971
400000
200000
0
2 million, 8G 4 million, 17G

26. Binlog Transmit Observer
Binlog_transmit_observer
transmit_observer = {
sizeof(Binlog_transmit_observer),
rpl_stat_transmit_start, //start
NULL, // stop
NULL, // reserve_header
rpl_stat_before_send_event,
NULL, // after_send_event
NULL, // reset
};

27. MySQL 5.5 的变化

28. MySQL 5.5 的改进
● MySQL 全面改用 CMake 作为主编译系统
● InnoDB 成为默认引擎， Barracuda
● MySQL 在 Win 平台上的性能提升较大
● 复制能够被更好地监控和管理
● 执行 SQL 语句时支持自定义异常处理并可
将异常抛会调用程序
● 新增性能模式库( Performance Schema)

29. MySQL 5.5 的改进
● InnoDB 同时支持多个 BufferPool 实例
● InnoDB 提升默认的并发线程策略
innodb_thread_concurrency=0
● InnoDB 细粒度控制后台 I/O 线程数量
innodb_read/write_io_threads
● InnoDB 可配置的主线程 I/O 速率
innodb_io_capacity=500
● Linux 平台原生异步 I/O 支持

30. MySQL 5.5 性能测试
● Linux Gentoo mysql23 2.6.34­hardened­r6
x86_64 GenuineIntel GNU/Linux
● 4*6(core) Intel(R) Xeon(R) CPU X5670 @
2.93GHz, 12M Cache, 6.40 GT/s Intel® QPI
● 32GB 内存
● 存储: 394 G /data, 82G /logs， 块大小: 4096,
deadline, AIO
● 存储性能使用 fio(Flexible IO Tester)

31. 磁盘性能
IOPS 带宽
只读 4,159 op/s 297 MB/s
只写 1,592 op/s 176 MB/s
读写 1,296 op/s
4k block

32. MySQL 5.5 vs MySQL 5.1
MySQL 5.5 配置 MySQL 5.1 配置
innodb_buffer_pool_size=20G innodb_buffer_pool_size=20G
innodb_file_per_table=1 innodb_file_per_table=1
innodb_doublewrite=0 innodb_doublewrite=no
innodb_max_dirty_pages_pct=80 innodb_max_dirty_pages_pct=80
innodb_flush_log_at_trx_commi=2 innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=8M innodb_log_buffer_size=8M
innodb_thread_concurrency=0 innodb_thread_concurrency=0
innodb_flush_method = O_DIRECT innodb_flush_method = O_DIRECT
innodb_write_io_threads=24 max_connections=3000
innodb_read_io_threads=24 query_cache_size=0
innodb_io_capacity=2700 #IOPS query_cache_type=0
innodb_use_native_aio
max_connections=3000
query_cache_size=0
query_cache_type=0

33. MyISAM 引擎只读测试

34. MyISAM 引擎读写测试

35. InnoDB 引擎只读测试

36. InnoDB 引擎读写测试

37. tpcc­mysql
测试使用500 w 的数据基数，64个并发线程，200秒预热时间，测试时间:3000秒。

38. Q & A