MySQL优化、新特性和新架构 彭立勋

MySQL优化、新特性和新架构

彭立勋 WWW.PengLiXun.COM

Alibaba  DBA  Team

Topics

•  挖掘MySQL性能

•  InnoDB Plugin新特性

•  Percona带来的改进

•  “动静结合”的分布式数据库架构

•  Q & A

挖掘MySQL性能

•  优化编译：ICC取代GCC

•  优化文件系统：XFS取代EXT3

•  优化存储：SSD取代SAS

•  优化接口：Handler Socket取代SQL

ICC取代GCC

•  ICC能有效利用Intel SSE2指令集，浮点运算效率高

•  ICC内置Intel Math Lib，提升数学函数效率

•  ICC内置Intel Thread Lib，提升多线程稳定性和效率

ICC vs GCC

硬件环境 CPU：Intel Xoen 5520 内存：24G 硬盘：10*15k SAS RAID10

XFS取代EXT3

•  XFS全B-Tree结构，适合大文件操作

•  XFS原生日志设计，日志检查速度远快于EXT3

•  XFS采用延迟分配，提升分配效率

EXT3 vs XFS

210  

100  

295  

140  

0  

50  

100  

150  

200  

250  

300  

350  

插入速度(Rows/s)   相对比例(%)  

64K顺序INSERT效率

EXT3  

XFS  

SSD取代SAS

•  一块SSD盘相当于一套高端存储的IO能力

•  读写不对称，适合用于二级读缓存和日志缓冲

SSD vs SAS

Handler Socket取代SQL

•  绕过费时的SQL解析，简单SQL通过API直接访问InnoDB

InnoDB Plugin新特性

•  新的文件格式 –  可选择的页大小(Page Size) –  可压缩的Blob Page

•  开放IO参数

–  innodb_io_capity –  read/write_io_thread

•  脏页刷新方式改进 –  innodb_adaptive_checkpoint(XtraDB) –  innodb_adaptive_flushing(InnoDB Plugin)

Adaptive Flushing

•  通过日志剩余空间除以日志产生速度算出切换前可以使用的时间：time_remainning

= log_capacity / redo_gen_rate

•  必须在日志切换前完成所有脏页的刷新，所以可以计算出刷新速度：flush_rate =

dirty_page_numbers / time_remaining = dairty_page_numbers * redo_gen_rate / log_capacity

•  将刷新速度减掉LRU_List刷新速度就可以得出Adaptive Flush必须的速度了：adaptive_flush_rate = flush_rate – lru_flush_rate = dairty_page_numbers * redo_gen_rate / log_capacity – lru_flush_rate

Adaptive Checkpoint

•  None：关闭自适应刷新

•  Reflex：脏页少于1/2则不刷新，超过1/2则使用Weak Flush，超过3/4则使用Strong Flush，大于7/8将不断刷新。

•  Estimate：脏页少于1/2则不刷新，超过1/2则基于未刷新的脏页量、日志产生速度、刷新页的Modified Age来计算刷新速度，大于7/8将不断刷新。

•  keep_average：刷新周期从1s提高到0.1s

自适应刷新方式

InnoDB IO流程

Percona带来的改进(1)

•  提升Buffer  Pool的扩展性 XtraDB将Buffer  Pool的全局Mutex拆成了多个Mutex以减少争用  

•  提高InnoDB  IO扩展性 XtraDB增加了许多变量去调整IO到最佳状态，包括调整checkpoint、后台读写数据文件线程数等等的参数  

•  多个回滚段 为提供一直读，InnoDB将事务修改的数据写到回滚段。回滚段被一个独立的Mutex保护，这直接导致了写密集型的工作并发不高。在 XtraDB可以改变回滚段的数目（innodb_extra_rsegments），在写密集型操作中可以大幅度提高性能  

•  可以更高的并发数

InnoDB在回滚段只提供了1024个回滚槽，如果回滚槽用完，新的事务将不能开始，直到有回滚槽被释放，XtraDB提供2047个事务槽

Percona带来的改进(2) •  专用的Purge线程

如果有很多事务，Purge线程清理空间不够快，共享表空间将急剧增长。这 将导致性能严重下降，甚至可能用完所有的磁盘空间。XtraDB使用了专用的线程来清理undo  space，这对undo  space的清理速度可以提升很多。尽管这可能使整体的性能降低，但是可以大大提高稳定性，因而整体性能略微降低是值得的  

•  可配置的Doublewrite缓冲

XtraDB提供了一个选项将doublewrite  buffer放在一个独立的磁盘来提升并发性能  

•  删除过多的函数调用 当MySQL从socket读数据时，将产生很多fcntl（针对描述符提供控制的函数）调用，导致并发性能下降。Percona移出了多于 的调用  

•  减少了Buffer  Pool  Mutex竞争

在InnoDB内核操作时减少了Buffer  Pool之间的Mutex争用（拆分Mutex变量）

新分布式数据库架构

•  静态服务器：主要数据存于静态服务器，除合并数据时，静态服务器数据不变。静态服务器为一组服务器池。

•  动态服务器：更新操作全部集中更在动态服务器，在合并数据时，动态服务器数据集中刷入静态服务器。

•  查询：从静态和动态服务器同时查询，合并结果。

程序结构

操作流程

Q&A