MySQL 凭借着出色的性能、低廉的成本、丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库。虽然性能出色,但所谓“好马配好鞍”,如何能够更好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如“精通 MySQL”、“SQL 语句优化”、“了解数据库原理”等要求。
什么是数据库的性能
- 用查询的响应时间度量性能,性能即响应时间。
-
优化性能,在一定工作负载下,降低查询的响应时间。
image
性能趋势
image优化方向
image- 硬件优化
- 操作系统优化
- MySql 配置优化
- 表结构优化
- 适用优化
- 架构优化
硬件优化
垂直扩展、向上扩展,购买强悍的硬件获取更高的性能。
image
- 无论使用公有云的RDS,还是自建MySQL,该优化方向都是代价最小的,性能优化的首选之一。
- 时间就是金钱。
- 人力成本远远大于硬件成本。
操作系统优化
-
IO 调度策略 - 操作系统与磁盘的通信方式
image -
RAID卡策略 – MegaCli工具
-
write back
-
write through
-
BUU
image -
swapness,代表权重,即使设置0也有可能会使用swap。
-
NUMA,高版本innodb_numa_interleave。
-
ulimit
image
MySql 优化配置
- innodb_buffer_pool_size
- innodb_io_capacity
- innodb_thread_concurrency
- innodb_flush_log_at_trx_commit
- sync_binlog
MySql 版本选择
- MySQL
- Percona
-
MariaDB
image
表结构优化
-
最佳实践 - bigint类型的自增主键。
image
使用优化
-
分类了四种在使用方面的性能问题原因以及出现场景
image
使用优化之 慢查询
- 现象:负载增加、慢查数据量增加。
- 解决:分析慢查日志,优先解决掉扫描行数大的慢查。
-
预防:
image
使用优化之 并发量
- 现象:负载陡增、QPS/TPS增加、thread_running增加。
- 解决:架构优化,过载保护,安全防护。
- 业务场景预防:容量压测、业务评估,找到热点数据、热点操作,隔离、缓存、限流。
使用优化之 数据量
- 现象:负载增加,某个表慢查数量增加。
- 解决:分析慢查日志,定位数据量异常的表。
- 预防:监控无索引使用的查询。
使用优化之 执行计划
- 现象:负载增加,某个id的慢查数量增加。
- 原因:因为采样误差、延后,静态模型,优化器会判断失误。
- 解决:
- 分析慢查,同一类慢查扫描行数max与min之差如果该值过大,需要注意。
- SQL中加入提示词,STRAIGHT_JOIN、FORCE_INDEX等。
- 预防:避免、监控数据倾斜情况发生。
使用优化之 pt-query-digest
image- 为每类SQL生成fingerprint,很方便构建SQL指纹库。
- 方便做二次修改或者包一层。
架构优化
-
演进方向
image
架构优化-以秒杀为例
-
热点操作
- 读操作
- 写操作
- 发现热点数据
- 静态数据,可以提前预测的热点数据。
- 动态数据,不可预测的热点数据。
-
处理热点数据的常见方法 - 缓存、限流
image
总结
image想要做好数据库优化,就要先做好测量(监控)。
监控尽可能的全面(KV,事件类,日志类),用数据说话。
image
分享链接:https://ke.qq.com/course/404589?taid=3237791161265261&tuin=1d644a5
网友评论