云时代的mysql 其实跟云时代没啥   系
本keynote的风格• 不会有代码• 不会有大段英文(翻译很烂的术语例外)• 听完之后就能用
MYISAM只是个浮云
innodb 1.1是你的选择• 任何有条件且有理智的人都应该选择 innodb 1.1,MYSQL版本就是 5.5• 若因为各    人祸,你应该了解MYSQL 5.1 是 innodb 1.0版(应该选择1.04以上的版 本,有重要特性更新)
看图说故事
看图说故事
看图说故事
看图说故事小结• 先写log,然后写table space,这   作法叫做 WAL,预先写日志• fuzzy checkpoint延迟写入文件,并且小批 量的慢慢写入 table space• 写log之前有log buffer,另外日志做 ...
有图有真相(来自高性能MYSQL)
innodb_buffer_pool_size• buffer_pool的值需要内存的80%• 神马insert buffer,索引,数据之类的集中营
innodb_additional_mem_pool_size• 跟 buffer_pool的比例约是200:1,即 buffer_pool为200M,这个参数需要设置1M.• 这个参数用于hash的meta信息和LRU等
innodb_log_file_size• 原则上多多益善,但是过大会让   时间 变得很慢,你就悲剧了• 所以你懂得,自己测试,给个参考,1G需要 10分钟来
innodb_log_buffer_size• 在这里,他只是一个演员,    ,我是想说,log buffer是存在的....• 好吧,说个有用的..这一般不需要设置( 飞)
innodb_adaptive_flushing• 自适应flush技术,会根据redo log日志的增 长速度来调整flush的频率• percona对此进行了进一步的改进,我告诉 过你要用分支..要用分支..有木有!
innodb_max_dirty_pages_pct• google建议设置为80• 即若超过80%的buffer pool,就需要flush  dirty page到table space了• adaptive flush你懂的,fuzzy ch...
innodb_flush_method• default(fsync),O_DIRECT,O_DSYNC• fsync是linux API,更详细看man• O_DIRECT和O_DSYNC都是open的参数, 看man吧• MYISAM当然没这...
innodb_flush_log_at_trx_commit• 可以选择是0,1,2,具体意思看手册• 0是无ACID• 1是默认,完整的ACID• 2是半ACID(推荐,可以提高写入的性能)
innodb_io_capacity• 以前默认是刷100脏页,写死的• 现在可以调整了,推荐设置为500以上,具 体看自己硬盘多牛X,你懂的,测试不可避 免
innodb_support_xa• 在一部分不要求数据安全的slave服务器    可以   闭之• 若不想用binlog的单MYSQL服务器可以    闭之•    闭能提高N多的性能(但问题你要想到)
adaptive hash索引是神马,能吃吗?• 是的,能吃的....• innodb有 索引,一   是B+树索引,另外 一   是hash索引• hash索引不能干预,是自动处理的
当然,还有牛X的参数• 这里只 注了性能• 还有维护性的参数之类的• 你懂的,参数才是新技术...
mysql还是yoursql?• percona server• mariadb• drizzle• 终究还是oracle’s sql(MYSQL 5.5)
percona server• xtradb• xtrabackup(热备利器)
percona server• xtradb• xtrabackup(热备利器)• 安装方便,无缝切换现有的MYSQL
xtradb实现快速启动• 会自动保存buffer pool的LRU• 本质上是让 buffer pool时,读取硬盘 从随机IO改成顺序IO
HandlerSocket• 比memcached更快的KV cache• 使用buffer pool• 跟innodb合用可更有效的利用buffer pool,节约更多的机器
MariaDB(等等)• 对MYSQL有多 改进• 内置多 引擎• 包括Handlesocket,XtraDB• 线程池,20000+连接都没问题• 优化子查询和join查询
index condition pushdown• 改进mysql的索引机制• 根据where条件来判断索引的读取数量• mysql 5.6收录此功能
实例• where date = 20111011 and name = ‘kk’• 用了 index condition pushdown的在判断  date索引会结合name选择过滤掉没用的  record• 注意:只有联合索引才有意义
动态字段•   create table t (id int auto_increment primary key,                       test    mediumblob);•   insert into t (te...
动态字段• where date = 20111011 and   name = ‘%kk  %’• 用了 index condition pushdown会判断符  合的%kk%的条件,从而避免了符合date  的所有的记录的读取,降低了IO...
MariaDB 5.5• MariaDB 5.5 == MariaDB 5.3 + Mysql 5.5• MariaDB 5.5是新霸主
Drizzle(不推荐)• 激进的改进• 制功能完全重写• 一切插件化• 当前特性还不足• 介于pgsql跟Mysql的之间的新数据库
高可用利器• DRDB•   Distributed Replicated Block Device
mysql 5.5• 改进分区(分区进入实用阶段)•   改进主从(主从功能不再山寨),主从的数据    安全大幅提升•   不基于mysql 5.5的分支都是   流氓
TokuDB引擎•   数据占用空间非常小•   插入性能   佳•   查询速度也还行•   多核表现不佳(貌似没对多核进行优化)
索引!索引!索引!•   绝大部分MYSQL性能问题,都是程序员对索引    不精通•   网上流传的limit优化实质是用子查询来使用索    引•   select * from user where id >=(select id fro...
几个问题• 单机性能还是scale out•   并行计算还是 k-v二元组范式•   专用系统vs通用系统•   数据安全vs性能
看点刚性数据• 只供参考,具体情景自己测试•   硬盘随机读写100 iops 顺序读写 50w iops•   内存 随机访问 25w 顺序访问 500w
我们学派建议神马?• 索引(学会explain是神的恩典)• flash cache(考虑用混合硬盘)• 配置调优(这是尖端科技)• 加CPU和内存(有钱就是力量)• 重新设计数据库,分离DB(悲催的      始)
有毛问题?• 请注意,我不是DBA• 尽量不要问问题,因为我不懂技术
Upcoming SlideShare
Loading in …5
×

111030 gztechparty-小路-云时代的mysql

2,494 views

Published on

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

Published in: Technology
0 Comments
15 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,494
On SlideShare
0
From Embeds
0
Number of Embeds
310
Actions
Shares
0
Downloads
138
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 111030 gztechparty-小路-云时代的mysql

    1. 1. 云时代的mysql 其实跟云时代没啥 系
    2. 2. 本keynote的风格• 不会有代码• 不会有大段英文(翻译很烂的术语例外)• 听完之后就能用
    3. 3. MYISAM只是个浮云
    4. 4. innodb 1.1是你的选择• 任何有条件且有理智的人都应该选择 innodb 1.1,MYSQL版本就是 5.5• 若因为各 人祸,你应该了解MYSQL 5.1 是 innodb 1.0版(应该选择1.04以上的版 本,有重要特性更新)
    5. 5. 看图说故事
    6. 6. 看图说故事
    7. 7. 看图说故事
    8. 8. 看图说故事小结• 先写log,然后写table space,这 作法叫做 WAL,预先写日志• fuzzy checkpoint延迟写入文件,并且小批 量的慢慢写入 table space• 写log之前有log buffer,另外日志做 数 据的作用,且把随机IO变成了顺序IO
    9. 9. 有图有真相(来自高性能MYSQL)
    10. 10. innodb_buffer_pool_size• buffer_pool的值需要内存的80%• 神马insert buffer,索引,数据之类的集中营
    11. 11. innodb_additional_mem_pool_size• 跟 buffer_pool的比例约是200:1,即 buffer_pool为200M,这个参数需要设置1M.• 这个参数用于hash的meta信息和LRU等
    12. 12. innodb_log_file_size• 原则上多多益善,但是过大会让 时间 变得很慢,你就悲剧了• 所以你懂得,自己测试,给个参考,1G需要 10分钟来
    13. 13. innodb_log_buffer_size• 在这里,他只是一个演员, ,我是想说,log buffer是存在的....• 好吧,说个有用的..这一般不需要设置( 飞)
    14. 14. innodb_adaptive_flushing• 自适应flush技术,会根据redo log日志的增 长速度来调整flush的频率• percona对此进行了进一步的改进,我告诉 过你要用分支..要用分支..有木有!
    15. 15. innodb_max_dirty_pages_pct• google建议设置为80• 即若超过80%的buffer pool,就需要flush dirty page到table space了• adaptive flush你懂的,fuzzy checkpoint你也 是懂的
    16. 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. 17. innodb_flush_log_at_trx_commit• 可以选择是0,1,2,具体意思看手册• 0是无ACID• 1是默认,完整的ACID• 2是半ACID(推荐,可以提高写入的性能)
    18. 18. innodb_io_capacity• 以前默认是刷100脏页,写死的• 现在可以调整了,推荐设置为500以上,具 体看自己硬盘多牛X,你懂的,测试不可避 免
    19. 19. innodb_support_xa• 在一部分不要求数据安全的slave服务器 可以 闭之• 若不想用binlog的单MYSQL服务器可以 闭之• 闭能提高N多的性能(但问题你要想到)
    20. 20. adaptive hash索引是神马,能吃吗?• 是的,能吃的....• innodb有 索引,一 是B+树索引,另外 一 是hash索引• hash索引不能干预,是自动处理的
    21. 21. 当然,还有牛X的参数• 这里只 注了性能• 还有维护性的参数之类的• 你懂的,参数才是新技术...
    22. 22. mysql还是yoursql?• percona server• mariadb• drizzle• 终究还是oracle’s sql(MYSQL 5.5)
    23. 23. percona server• xtradb• xtrabackup(热备利器)
    24. 24. percona server• xtradb• xtrabackup(热备利器)• 安装方便,无缝切换现有的MYSQL
    25. 25. xtradb实现快速启动• 会自动保存buffer pool的LRU• 本质上是让 buffer pool时,读取硬盘 从随机IO改成顺序IO
    26. 26. HandlerSocket• 比memcached更快的KV cache• 使用buffer pool• 跟innodb合用可更有效的利用buffer pool,节约更多的机器
    27. 27. MariaDB(等等)• 对MYSQL有多 改进• 内置多 引擎• 包括Handlesocket,XtraDB• 线程池,20000+连接都没问题• 优化子查询和join查询
    28. 28. index condition pushdown• 改进mysql的索引机制• 根据where条件来判断索引的读取数量• mysql 5.6收录此功能
    29. 29. 实例• where date = 20111011 and name = ‘kk’• 用了 index condition pushdown的在判断 date索引会结合name选择过滤掉没用的 record• 注意:只有联合索引才有意义
    30. 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. 31. 动态字段• where date = 20111011 and name = ‘%kk %’• 用了 index condition pushdown会判断符 合的%kk%的条件,从而避免了符合date 的所有的记录的读取,降低了IO• 注意:只有联合索引才有意义
    32. 32. MariaDB 5.5• MariaDB 5.5 == MariaDB 5.3 + Mysql 5.5• MariaDB 5.5是新霸主
    33. 33. Drizzle(不推荐)• 激进的改进• 制功能完全重写• 一切插件化• 当前特性还不足• 介于pgsql跟Mysql的之间的新数据库
    34. 34. 高可用利器• DRDB• Distributed Replicated Block Device
    35. 35. mysql 5.5• 改进分区(分区进入实用阶段)• 改进主从(主从功能不再山寨),主从的数据 安全大幅提升• 不基于mysql 5.5的分支都是 流氓
    36. 36. TokuDB引擎• 数据占用空间非常小• 插入性能 佳• 查询速度也还行• 多核表现不佳(貌似没对多核进行优化)
    37. 37. 索引!索引!索引!• 绝大部分MYSQL性能问题,都是程序员对索引 不精通• 网上流传的limit优化实质是用子查询来使用索 引• select * from user where id >=(select id from user limit 1000000,1)limit 100
    38. 38. 几个问题• 单机性能还是scale out• 并行计算还是 k-v二元组范式• 专用系统vs通用系统• 数据安全vs性能
    39. 39. 看点刚性数据• 只供参考,具体情景自己测试• 硬盘随机读写100 iops 顺序读写 50w iops• 内存 随机访问 25w 顺序访问 500w
    40. 40. 我们学派建议神马?• 索引(学会explain是神的恩典)• flash cache(考虑用混合硬盘)• 配置调优(这是尖端科技)• 加CPU和内存(有钱就是力量)• 重新设计数据库,分离DB(悲催的 始)
    41. 41. 有毛问题?• 请注意,我不是DBA• 尽量不要问问题,因为我不懂技术

    ×