MySql 性能优化

MySQL 凭借着出色的性能、低廉的成本、丰富的资源，已经成为绝大多数互联网公司的首选关系型数据库。虽然性能出色，但所谓“好马配好鞍”，如何能够更好的使用它，已经成为开发工程师的必修课，我们经常会从职位描述上看到诸如“精通 MySQL”、“SQL 语句优化”、“了解数据库原理”等要求。

什么是数据库的性能

• 用查询的响应时间度量性能，性能即响应时间。
• 优化性能，在一定工作负载下，降低查询的响应时间。
  

性能趋势

优化方向

• 硬件优化
• 操作系统优化
• MySql 配置优化
• 表结构优化
• 适用优化
• 架构优化

硬件优化

垂直扩展、向上扩展，购买强悍的硬件获取更高的性能。

• 无论使用公有云的RDS，还是自建MySQL，该优化方向都是代价最小的，性能优化的首选之一。
• 时间就是金钱。
• 人力成本远远大于硬件成本。

操作系统优化

• IO 调度策略 - 操作系统与磁盘的通信方式
  

• RAID卡策略 – MegaCli工具
• write back
• write through

• BUU
  

• swapness，代表权重，即使设置0也有可能会使用swap。
• NUMA，高版本innodb_numa_interleave。
• ulimit
  

MySql 优化配置

• innodb_buffer_pool_size
• innodb_io_capacity
• innodb_thread_concurrency
• innodb_flush_log_at_trx_commit
• sync_binlog

MySql 版本选择

• MySQL
• Percona
• MariaDB
  

表结构优化

• 最佳实践 - bigint类型的自增主键。
  

使用优化

• 分类了四种在使用方面的性能问题原因以及出现场景
  

使用优化之 慢查询

• 现象：负载增加、慢查数据量增加。
• 解决：分析慢查日志，优先解决掉扫描行数大的慢查。
• 预防：
  

使用优化之 并发量

• 现象：负载陡增、QPS/TPS增加、thread_running增加。
• 解决：架构优化，过载保护，安全防护。
• 业务场景预防：容量压测、业务评估，找到热点数据、热点操作，隔离、缓存、限流。

  使用优化之 数据量

• 现象：负载增加，某个表慢查数量增加。
• 解决：分析慢查日志，定位数据量异常的表。
• 预防：监控无索引使用的查询。

  使用优化之 执行计划

• 现象：负载增加，某个id的慢查数量增加。
• 原因：因为采样误差、延后，静态模型，优化器会判断失误。
• 解决：
  • 分析慢查，同一类慢查扫描行数max与min之差如果该值过大，需要注意。
  • SQL中加入提示词，STRAIGHT_JOIN、FORCE_INDEX等。
• 预防：避免、监控数据倾斜情况发生。

使用优化之 pt-query-digest

• 为每类SQL生成fingerprint，很方便构建SQL指纹库。
• 方便做二次修改或者包一层。

架构优化

• 演进方向
  

架构优化-以秒杀为例

• 热点操作
  • 读操作
  • 写操作
• • 发现热点数据
  • 静态数据，可以提前预测的热点数据。
  • 动态数据，不可预测的热点数据。
• 处理热点数据的常见方法 - 缓存、限流
  

总结

想要做好数据库优化，就要先做好测量（监控）。
监控尽可能的全面（KV，事件类，日志类），用数据说话。

分享链接：https://ke.qq.com/course/404589?taid=3237791161265261&tuin=1d644a5

转载于:https://blog.51cto.com/51reboot/2394485