Mysql调优
Download as PPTX, PDF6 likes1,150 views
本文档探讨了MySQL性能优化的基本要点，包括硬件、软件及其监控工具。重点介绍了如何发现和解决数据库性能问题，涉及服务器调优、架构设计和查询优化等方面的最佳实践。还讨论了缓存管理、表设计和存储引擎选择的有效策略，以提升数据库整体性能。
Mysql调优
- 1. MYSQL性能优化 www.nsfocus.com nsfocus.com © 2011 绿盟科技
- 3. 问题包括下面三类，分而治之 • 硬件 • 软件 • MySQL
- 4. 硬件
- 5. 与数据库性能相关的硬件资源 • CPU • Memory • Disk • Network
- 6. 必知必会的几个监控工具 • vmstat • iostat • netstat • dstat • top • ifconfig
- 9. 配合上面的工具要能回答下面几个问题 • I/O – I/O负载是否高？ iostat tps 每秒i/o请求次数 iostat %util 一秒钟内有多少时间用于I/O操作 wa cpu平均等待IO的时间 – 主要是读还是写？ iostat r/s , w/s很容易判断 – 是随机写还是顺序写？ 顺序读写性能远高于随机读写 数据库文件涉及索引等内容，写入是随机写 binlog文件是顺序写
- 10. • Memory – mem使用率是否过高？ 很容易判断，free，top，vmstat – mem用在了哪？ 各种 buffer&cache， 后面再细讲 • CPU – CPU使用率是否过高？ 很容易判断，top，vmstat – 什么进程占用cpu top • Network – 带宽？ dstat，ifconfig – 谁占用的带宽？ iftop、tcpdump
- 11. 软件
- 12. • OS 可做的事情不多 – 用主流的发行版（RHEL、Ubuntu、SLES） – kernel版本 （>=2.6.12） – 用主流的文件系统(ext3 , xfs) – 用64-bit架构系统（RAM>4G） – 其它的就不要碰了
- 13. MySQL
- 14. 定位mysql的性能问题 调优的过程也是一个寻找问题的过程 • MySQL整体性能如何？瓶颈在哪？ – show status – mysqlreport – tuning-primer.sh • 系统中哪些查询最慢？ – mysqldumpslow -s c -t 10 /var/lib/mysql/slowquery.log 查看10条出现最多的慢查询 • 当前哪些进程正在操作数据库？ – Show processlist • 某个查询是否使用了索引？效率是否足够高？ – explain • 一个查询，时间都花在了哪？ – profiling
- 16. 目录 • 服务器调优 • Shcema设计 • 查询优化 • 存储引擎优化 • 架构设计
- 17. • 服务器调优
- 18. • Tips • 所有MySQL服务器调优的参数，都在my.cnf中设置。 • 所有参数的值都可以通过show variables查看 。 • 所有参数设置是否合理，都可以通过show status来判断。 也可以通过mysqlreport这样的工具帮助分析。 • 与性能相关的参数主要是log，以及各种buffer & cache
- 19. log
- 20. log • 主要log • Error log 默认打开 • Binlog 一般都打开，增量备份和复制的基础 • Slow query log 需要调优时打开 • Query log 除非出于debug目的，否则肯定不开，I/O消耗严重 • 各类日志相关的参数中，性能相关主要是两项 – Binlog -- sync_log – log_slow_queries -- long_query_time
- 21. • Binlog -- sync_log 只要系统不是对事务的安全性要求特别高，都将sync_binlog置为0，当 sync_binlog=1时，事务的安全性最高，但是系统整体性能下降极为明显。
- 22. • log_slow_queries -- long_query_time. 慢查询的阈值，默认为2秒。最短可设置为1秒。记录慢查询日志会消耗cpu资源，需 要对每次查询计算时间，只要cpu资源足够，影响不大。 我们的数据库中，默认为2秒，2202630284次查询中，83692次查询时间超过2秒，整 体来说并不差。 mysqldumpslow -s c -t 5 /var/lib/mysql/slowquery.log 显示最慢的5条SQL
- 23. Buffer & cache
- 24. Buffer & cache Global buffer Thread buffer query_cache sort_buffer key_buffer join_buffer innodb_buffer_pool read_buffer thread_cache_size read_rnd_buffer table_open_cache
- 25. • 查询缓存 -> query_cache • MyISAM 索引缓存 -> key_buffer • InnoDB缓存 -> innodb_pool_buffer • 慢查询日志 -> log_slow • 日志优化 -> binlog_cache • 连接线程池 -> thead_cache • 文件描述符缓存 -> table_cache • 各类线程级buffer -> sort/join/read_rnd/read buffer
- 26. query cache • Query_cache • 经验值 query_cache_size 设成32 – 128 M • 缓存命中率 = Qcache_hits/(Qcache_hits+Qcache_inserts) * 100 % • query_cache_min_res_unit合理值 = (query_cache_size-Qcache_free_memory /Qcache_queries_in_cache • 当Qcache_lowmem_prunes持续增长，而free memory还比较大，说明query cache有很多碎片。
- 27. • Key_buffer • key_buffer_size 分配给MyISAM 的索引缓存大小 • Key_buffer_size 的理想值 = 所有索引文件的大小 • Key_buffer_size 的经验值 = 25%- 33% RAM • 查询命中率 = （Key_read_requests- key_reads）/Key_read_requests • Key_blocks_used ，Key_blocks_unused显示key_buffer的实际使用情况
- 28. • innodb_buffer_pool • 缓存innodb数据和索引 • Innodb_buffer_pool_size 理想值 = Innodb表数据文件大小+索引文件大小 • Innodb_buffer_pool_size 经验值 = 50% – 80% RAM • Buffer 使用率 = Innodb_buffer_pool_pages_data/Innodb_buffer_pool_pages_total * 100% • 查询命中率 = (Innodb_buffer_pool_read_requests- Innodb_buffer_pool_reads)/Innodb_buffer_pool_read_requests * 100%
- 29. • thread-cache • 连接线程池 • Thread_cache_size经验值 = 8 - 12 • 连接线程缓存命中率 = (Connections - Threads_created) / Connections * 100%
- 30. • table_open_cache • table_open_cache 经验值 = 64 – 2048 • open_tables 保证<= table_open_cache
- 31. 解释 经验值 我们设置的大小 sort_buffer_size 系统在排序时使用的 2 – 16 M 8M buffer join_buffer_size 当Join 是ALL index ， 8M rang 或index_merge 的时候使用的 Buffer read_buffer_size 顺序读buffer 2M read_rnd_buffer_size 随机读buffer 16M
- 32. • Schema 设计
- 33. • 表结构设计 • 限制表的数量 – 单库不超过300-400个表 • 限制单表数据量 – 一年内纯int不超过1000W – 一年内含char不超过500W • 限制列的数量 – 单表字段数控制在20 – 50个 • 大字段垂直拆分 – TEXT处理性能远低于VARCHAR – 尽量不用TEXT/BLOB类型字段 – 如必须使用，则拆分到单独的表中 • 反范式 – 适当冗余，减少关联查询
- 34. • 字段类型 • 整型 TINYINT、INT、BIGINT • 浮型 FLOAT、DOUVBLE、DECIMAL、NUMERIC • 时间日期 DATETIME、DATE、TIMESTAMP • 字符类型 VARCHAR、CHAR、BLOB、TEXT、ENUM
- 35. • 原则 • 选用更小的数据类型，减少存储空间 • 通过合适数据类型加速数据比较
- 38. • 字段设计 • 将字符转为数字 – 用无符号INT存储IP，而非CHAR(15) – INET_ATON(’10.1.1.1’) = 167837953 – INET_NTOA(653235463) = 38.239.149.7 • 优先使用ENUM或SET – ENUM占用1个字节 – SET视界节点，最多占用8字节 – `sex` enum(‘F’,’M’) • 避免使用NULL字段 – 很难进行查询优化 – NULL列添加索引需要额外空间 – 含NULL复合索引无效 • 使用timestamp而不是datetime – UNIX_TIMESTAMP('2012-07-17 15:01:15') = 1342508475 – FROM_UNIXTIME(1342508475) = 2012-07-17 15:01:15
- 39. • SQL语句优化
- 40. • 索引 • 小结果集驱动大结果集 • http://vdisk.weibo.com/s/SMRp • http://vdisk.weibo.com/s/4sEw- • http://vdisk.weibo.com/s/gYYQ
- 41. • 存储引擎
- 42. • MyISAM 表锁 不支持事务 Count() 快 内存占用和磁盘存储小 • InnoDB 行锁 支持事务 count()慢 内存占用和磁盘存储大
- 43. • 并发读高 MyISAM • 并发写高 MyISAM • 并发写高+并发读高 InnoDB
- 44. • 架构设计
- 46. scalability • Scale Up • Scale Out Replication Sharding Cluster
- 47. replication • Master - Slaves
- 48. replication
- 49. 级联 • Master -- Master – Slaves -- Slaves
- 50. sharding • Sharding 垂直分区 水平分区
- 51. 垂直分区 优点: • 拆分规则简单 • 数据整合容易 • 维护方便 缺点: • 事务处理复杂 • 扩展性有瓶颈
- 52. 水平分区 优点: • 应用程序端架构改动相对较少 • 事务处理相对简单 • 无扩展性限制 缺点: • 很难有满足全局的切分规则 • 数据维护复杂 • 应用系统耦合度高
- 53. 数据整合 • 数据整合 自行研发 MySQL Proxy Amoeba
- 54. MySQL Proxy • 连接路由 • 查询分析 • 查询过滤 • Load balance • HA
- 55. Amoeba • 数据切分后数据源整合 • 连接池 • 读写分离路由 与MySQL Proxy比较： 优点：不需要自己写大量lua script 缺点：作者个人维护，缺少社区支持
- 56. cluster
- 58. HA • HA 数据备份 Fail-over
- 60. cluster
- 61. DRBD • 网络RAID1
- 62. 谢谢！