Mysql 性能优化教程二之——Mysql 运维优化

Mysql 运维优化

存储引擎类型

 Myisam 速度快，响应快。表级锁是致命问题。

 Innodb 目前主流存储引擎

 行级锁 

 务必注意影响结果集的定义是什么

 行级锁会带来更新的额外开销，但是通常情况下是值得的。

 事务提交 

 对i/o效率提升的考虑

 对安全性的考虑

 HEAP 内存引擎

 频繁更新和海量读取情况下仍会存在锁定状况

内存使用考量

 理论上，内存越大，越多数据读取发生在内存，效率越高

 Query cache的使用

 如果前端请求重复度不高，或者应用层已经充分缓存重复请求，query cache不必设置很大，甚至可以不设置。

 如果前端请求重复度较高，无应用层缓存，query cache是一个很好的偷懒选择

 对于中等以下规模数据库应用，偷懒不是一个坏选择。

 如果确认使用query cache，记得定时清理碎片，flush query cache.

 要考虑到现实的硬件资源和瓶颈分布

 学会理解热点数据，并将热点数据尽可能内存化

 所谓热点数据，就是最多被访问的数据。

 通常数据库访问是不平均的，少数数据被频繁读写，而更多数据鲜有读写。

 学会制定不同的热点数据规则，并测算指标。

 热点数据规模，理论上，热点数据越少越好，这样可以更好的满足业务的增长趋势。

 响应满足度，对响应的满足率越高越好。

 比如依据最后更新时间，总访问量，回访次数等指标定义热点数据，并测算不同定义模式下的热点数据规模

性能与安全性考量

 数据提交方式

 innodb_flush_log_at_trx_commit = 1 每次自动提交，安全性高，i/o压力大

 innodb_flush_log_at_trx_commit = 2 每秒自动提交，安全性略有影响，i/o承载强。

 日志同步

 Sync-binlog
=1 每条自动更新，安全性高，i/o压力大

 Sync-binlog = 0 根据缓存设置情况自动更新，存在丢失数据和同步延迟风险，i/o承载力强。

 个人建议保存binlog日志文件，便于追溯 更新操作和系统恢复。

 如对日志文件的i/o压力有担心，在内存宽裕的情况下，可考虑将binlog 写入到诸如 /dev/shm 这样的内存映射分区，并定时将旧有的binlog转移到物理硬盘。

 性能与安全本身存在相悖的情况，需要在业务诉求层面决定取舍

 学会区分什么场合侧重性能，什么场合侧重安全

 学会将不同安全等级的数据库用不同策略管理

存储/写入压力优化

 顺序读写性能远高于随机读写

 将顺序写数据和随机读写数据分成不同的物理磁盘进行，有助于i/o压力的疏解

• 数据库文件涉及索引等内容，写入是随即写

• binlog文件是顺序写

• 淘宝数据库存储优化是这样处理的

 部分安全要求不高的写入操作可以用 /dev/shm 分区存储，简单变成内存写。

 多块物理硬盘做raid10，可以提升写入能力

 关键存储设备优化，善于比对不同存储介质的压力测试数据。

• 例如fusion-io在新浪和淘宝都有较多使用。

 涉及必须存储较为庞大的数据量时

• 压缩存储，可以通过增加cpu开销（压缩算法）减少i/o压力。前提是你确认cpu相对空闲而i/o压力很大。 新浪微博就是压缩存储的典范。

• 通过md5去重存储，案例是QQ的文件共享，以及dropbox这样的共享服务，如果你上传的是一个别人已有的文件，计算md5后，直接通过md5定位到原有文件，这样可以极大减少存储量。涉及文件共享，头像共享，相册等应用，通过这种方法可以减少超过70%的存储规模，对硬件资源的节省是相当巨大的。缺点是，删除文件需要甄别该md5是否有其他人使用。 去重存储，用户量越多，上传文件越多，效率越高！

• 文件尽量不要存储到数据库内。尽量使用独立的文件系统存储，该话题不展开。

运维监控体系

 系统监控

 服务器资源监控

 Cpu, 内存，硬盘空间，i/o压力

 设置阈值报警

 服务器流量监控

 外网流量，内网流量

 设置阈值报警

 连接状态监控

 Show processlist 设置阈值，每分钟监测，超过阈值记录

 应用监控

 慢查询监控

 慢查询日志

 如果存在多台数据库服务器，应有汇总查阅机制。

 请求错误监控

 高频繁应用中，会出现偶发性数据库连接错误或执行错误，将错误信息记录到日志，查看每日的比例变化。

 偶发性错误，如果数量极少，可以不用处理，但是需时常监控其趋势。

 会存在恶意输入内容，输入边界限定缺乏导致执行出错，需基于此防止恶意入侵探测行为。

 微慢查询监控

 高并发环境里，超过0.01秒的查询请求都应该关注一下。

 频繁度监控

 写操作，基于binlog，定期分析。

 读操作，在前端db封装代码中增加抽样日志，并输出执行时间。

 分析请求频繁度是开发架构 进一步优化的基础

 最好的优化就是减少请求次数！

 总结：

 监控与数据分析是一切优化的基础。

 没有运营数据监测就不要妄谈优化！

 监控要注意不要产生太多额外的负载，不要因监控带来太多额外系统开销