珠三角技术沙龙2011-10广州场-数据库专题报名 :云时代的 MySQL http://techparty.org/2011/10/16/201110-gz-db-party/

1. 云时代的mysql
其实跟云时代没啥 系

2. 本keynote的风格
• 不会有代码
• 不会有大段英文(翻译很烂的术语例外)
• 听完之后就能用

3. MYISAM只是个浮云

4. innodb 1.1是你的选择
• 任何有条件且有理智的人都应该选择
innodb 1.1,MYSQL版本就是 5.5
• 若因为各 人祸,你应该了解MYSQL 5.1
是 innodb 1.0版(应该选择1.04以上的版
本,有重要特性更新)

5. 看图说故事

6. 看图说故事

7. 看图说故事

8. 看图说故事小结
• 先写log,然后写table space,这 作法叫做
WAL,预先写日志
• fuzzy checkpoint延迟写入文件,并且小批
量的慢慢写入 table space
• 写log之前有log buffer,另外日志做 数
据的作用,且把随机IO变成了顺序IO

9. 有图有真相(来自高性能MYSQL)

10. innodb_buffer_pool_size
• buffer_pool的值需要内存的80%
• 神马insert buffer,索引,数据之类的集中营

11. innodb_additional_mem_pool_size
• 跟 buffer_pool的比例约是200:1,即
buffer_pool为200M,这个参数需要设置1M.
• 这个参数用于hash的meta信息和LRU等

12. innodb_log_file_size
• 原则上多多益善,但是过大会让 时间
变得很慢,你就悲剧了
• 所以你懂得,自己测试,给个参考,1G需要
10分钟来

13. innodb_log_buffer_size
• 在这里,他只是一个演员, ,我是想说,log
buffer是存在的....
• 好吧,说个有用的..这一般不需要设置(
飞)

14. innodb_adaptive_flushing
• 自适应flush技术,会根据redo log日志的增
长速度来调整flush的频率
• percona对此进行了进一步的改进,我告诉
过你要用分支..要用分支..有木有!

15. innodb_max_dirty_pages_pct
• google建议设置为80
• 即若超过80%的buffer pool,就需要flush
dirty page到table space了
• adaptive flush你懂的,fuzzy checkpoint你也
是懂的

16. innodb_flush_method
• default(fsync),O_DIRECT,O_DSYNC
• fsync是linux API,更详细看man
• O_DIRECT和O_DSYNC都是open的参数,
看man吧
• MYISAM当然没这个问题,交给OS buffer来
处理,不过作为数据库....INNODB带你上

17. innodb_flush_log_at_trx_commit
• 可以选择是0,1,2,具体意思看手册
• 0是无ACID
• 1是默认,完整的ACID
• 2是半ACID(推荐,可以提高写入的性能)

18. innodb_io_capacity
• 以前默认是刷100脏页,写死的
• 现在可以调整了,推荐设置为500以上,具
体看自己硬盘多牛X,你懂的,测试不可避
免

19. innodb_support_xa
• 在一部分不要求数据安全的slave服务器
可以 闭之
• 若不想用binlog的单MYSQL服务器可以
闭之
• 闭能提高N多的性能(但问题你要想到)

20. adaptive hash索引是神马,能吃吗?
• 是的,能吃的....
• innodb有 索引,一 是B+树索引,另外
一 是hash索引
• hash索引不能干预,是自动处理的

21. 当然,还有牛X的参数
• 这里只 注了性能
• 还有维护性的参数之类的
• 你懂的,参数才是新技术...

22. mysql还是yoursql?
• percona server
• mariadb
• drizzle
• 终究还是oracle’s sql(MYSQL 5.5)

23. percona server
• xtradb
• xtrabackup（热备利器）

24. percona server
• xtradb
• xtrabackup（热备利器）
• 安装方便，无缝切换现有的MYSQL

25. xtradb实现快速启动
• 会自动保存buffer pool的LRU
• 本质上是让 buffer pool时，读取硬盘
从随机IO改成顺序IO

26. HandlerSocket
• 比memcached更快的KV cache
• 使用buffer pool
• 跟innodb合用可更有效的利用buffer
pool，节约更多的机器

27. MariaDB（等等）
• 对MYSQL有多 改进
• 内置多 引擎
• 包括Handlesocket，XtraDB
• 线程池，20000+连接都没问题
• 优化子查询和join查询

28. index condition pushdown
• 改进mysql的索引机制
• 根据where条件来判断索引的读取数量
• mysql 5.6收录此功能

29. 实例
• where date = 20111011 and name = ‘kk’
• 用了 index condition pushdown的在判断
date索引会结合name选择过滤掉没用的
record
• 注意：只有联合索引才有意义

30. 动态字段
• create table t (id int auto_increment primary key,
test mediumblob）；
• insert into t (test) values （COLUMN_CREATE(1, "bt", 4, "小bt")）（2，‘小bt’，3，‘大
BT’）（1，”dd“，4，”pp“）
• select COLUMN_GET(test, 4 as char(10)), column_list(test) as list
from t where COLUMN_GET(test, 1 as char(10)) = ‘bt’;
• 结果： name list
小bt 1，4

31. 动态字段
• where date = 20111011 and name = ‘%kk
%’
• 用了 index condition pushdown会判断符
合的%kk%的条件，从而避免了符合date
的所有的记录的读取，降低了IO
• 注意：只有联合索引才有意义

32. MariaDB 5.5
• MariaDB 5.5 == MariaDB 5.3 + Mysql 5.5
• MariaDB 5.5是新霸主

33. Drizzle（不推荐）
• 激进的改进
• 制功能完全重写
• 一切插件化
• 当前特性还不足
• 介于pgsql跟Mysql的之间的新数据库

34. 高可用利器
• DRDB
• Distributed Replicated Block Device

35. mysql 5.5
• 改进分区（分区进入实用阶段）
• 改进主从（主从功能不再山寨），主从的数据
安全大幅提升
• 不基于mysql 5.5的分支都是 流氓

36. TokuDB引擎
• 数据占用空间非常小
• 插入性能 佳
• 查询速度也还行
• 多核表现不佳（貌似没对多核进行优化）

37. 索引！索引！索引！
• 绝大部分MYSQL性能问题，都是程序员对索引
不精通
• 网上流传的limit优化实质是用子查询来使用索
引
• select * from user where id >=（select id from
user limit 1000000，1）limit 100

38. 几个问题
• 单机性能还是scale out
• 并行计算还是 k-v二元组范式
• 专用系统vs通用系统
• 数据安全vs性能

39. 看点刚性数据
• 只供参考，具体情景自己测试
• 硬盘随机读写100 iops 顺序读写 50w iops
• 内存 随机访问 25w 顺序访问 500w

40. 我们学派建议神马?
• 索引(学会explain是神的恩典)
• flash cache(考虑用混合硬盘)
• 配置调优(这是尖端科技)
• 加CPU和内存(有钱就是力量)
• 重新设计数据库,分离DB(悲催的 始)

41. 有毛问题?
• 请注意,我不是DBA
• 尽量不要问问题,因为我不懂技术