111030 gztechparty-小路-云时代的mysql
Download as key, pdf15 likes874 views
本文件讨论了在云时代使用惭测厂蚕尝的最佳实践和性能调优，包括对滨苍苍辞顿叠的配置建议、不同存储引擎的比较以及索引优化的必要性。特别强调笔础搁础惭贰罢贰搁厂的设置对数据库性能的影响以及使用笔别谤肠辞苍补和惭补谤颈补顿叠等派生产物的优点。最后，文档提到了一些常见的性能问题及优化策略。
111030 gztechparty-小路-云时代的mysql
- 1. 云时代的mysql 其实跟云时代没啥 系
- 2. 本keynote的风格 ? 不会有代码 ? 不会有大段英文(翻译很烂的术语例外) ? 听完之后就能用
- 3. 惭驰滨厂础惭只是个浮云
- 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
- 10. innodb_buffer_pool_size ? buffer_pool的值需要内存的80% ? 神马insert 产耻蹿蹿别谤,索引,数据之类的集中营
- 11. innodb_additional_mem_pool_size ? 跟 buffer_pool的比例约是200:1,即 buffer_pool为200M,这个参数需要设置1M. ? 这个参数用于hash的meta信息和LRU等
- 12. innodb_log_?le_size ? 原则上多多益善,但是过大会让 时间 变得很慢,你就悲剧了 ? 所以你懂得,自己测试,给个参考,1G需要 10分钟来
- 13. innodb_log_buffer_size ? 在这里,他只是一个演员, ,我是想说,log buffer是存在的.... ? 好吧,说个有用的..这一般不需要设置( 飞)
- 14. innodb_adaptive_?ushing ? 自适应?ush技术,会根据redo log日志的增 长速度来调整?ush的频率 ? percona对此进行了进一步的改进,我告诉 过你要用分支..要用分支..有木有!
- 15. innodb_max_dirty_pages_pct ? google建议设置为80 ? 即若超过80%的buffer pool,就需要?ush dirty page到table space了 ? adaptive ?ush你懂的,fuzzy checkpoint你也 是懂的
- 16. innodb_?ush_method ? default(fsync),O_DIRECT,O_DSYNC ? fsync是linux API,更详细看man ? O_DIRECT和O_DSYNC都是open的参数, 看man吧 ? MYISAM当然没这个问题,交给OS buffer来 处理,不过作为数据库....INNODB带你上
- 17. innodb_?ush_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 ? 虫迟谤补产补肠办耻辫（热备利器）
- 24. percona server ? xtradb ? 虫迟谤补产补肠办耻辫（热备利器） ? 安装方便，无缝切换现有的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是神的恩典) ? ?ash cache(考虑用混合硬盘) ? 配置调优(这是尖端科技) ? 加CPU和内存(有钱就是力量) ? 重新设计数据库,分离DB(悲催的 始)