Mysql性能优化教程
发布日期:2018-09-14 作者:atguigu 9947人浏览
3. Mysql 运维优化
3.1. 存储引擎类型
- Myisam 速度快,响应快。表级锁是致命问题。
- Innodb 目前主流存储引擎
- 行级锁
- 务必注意影响结果集的定义是什么
- 行级锁会带来更新的额外开销,但是通常情况下是值得的。
- 事务提交
- HEAP 内存引擎
3.2. 内存使用考量
- 理论上,内存越大,越多数据读取发生在内存,效率越高
- 要考虑到现实的硬件资源和瓶颈分布
- 学会理解热点数据,并将热点数据尽可能内存化
- 所谓热点数据,就是最多被访问的数据。
- 通常数据库访问是不平均的,少数数据被频繁读写,而更多数据鲜有读写。
- 学会制定不同的热点数据规则,并测算指标。
- 热点数据规模,理论上,热点数据越少越好,这样可以更好的满足业务的增长趋势。
- 响应满足度,对响应的满足率越高越好。
- 比如依据最后更新时间,总访问量,回访次数等指标定义热点数据,并测算不同定义模式下的热点数据规模
3.3. 性能与安全性考量
- 数据提交方式
- 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承载力强。
- 性能与安全本身存在相悖的情况,需要在业务诉求层面决定取舍
- 学会区分什么场合侧重性能,什么场合侧重安全
- 学会将不同安全等级的数据库用不同策略管理
3.4. 存储压力优化
- 顺序读写性能远高于随机读写
- 日志类数据可以使用顺序读写方式进行
- 将顺序写数据和随机读写数据分成不同的物理磁盘,有助于i/o压力的疏解,前提是,你确信你的i/o压力主要来自于可顺序写操作(因随机读写干扰导致不能顺序写,但是确实可以用顺序写方式进行的i/o操作)。
3.5. 运维监控体系
- 系统监控
- 服务器资源监控
- Cpu, 内存,硬盘空间,i/o压力
- 设置阈值报警
- 服务器流量监控
- 连接状态监控
- Show processlist 设置阈值,每分钟监测,超过阈值记录
- 应用监控
- 慢查询监控
- 慢查询日志
- 如果存在多台数据库服务器,应有汇总查阅机制。
- 请求错误监控
- 高频繁应用中,会出现偶发性数据库连接错误或执行错误,将错误信息记录到日志,查看每日的比例变化。
- 偶发性错误,如果数量极少,可以不用处理,但是需时常监控其趋势。
- 会存在恶意输入内容,输入边界限定缺乏导致执行出错,需基于此防止恶意入侵探测行为。
- 微慢查询监控
- 高并发环境里,超过01秒的查询请求都应该关注一下。
- 频繁度监控
- 写操作,基于binlog,定期分析。
- 读操作,在前端db封装代码中增加抽样日志,并输出执行时间。
- 分析请求频繁度是开发架构 进一步优化的基础
- 最好的优化就是减少请求次数!
- 总结:
- 监控与数据分析是一切优化的基础。
- 没有运营数据监测就不要妄谈优化!
- 监控要注意不要产生太多额外的负载,不要因监控带来太多额外系统开销