文章目录
开篇暴击:你的数据库真的在认真工作吗?!
作为后端开发的老司机(菜鸟也适用),咱们肯定都经历过这样的场景——页面加载转圈转得能织毛衣,接口响应慢得像树懒约会,最后定位到数据库查询耗时5秒+(血压瞬间180)!今天就手把手带大家玩转MySQL性能调优,让咱们的数据库从老爷车变身超跑!
真实案例:某电商平台大促期间,商品列表页查询从8秒优化到0.3秒,直接省下3台服务器(老板当场表演笑容逐渐变态)
调优三板斧(新手必看生存指南)
第一式:慢查询日志全开!(超级重要)
-- 开启慢查询日志(建议开发环境都开着)
SET GLOBAL slow_query_log = ON;
-- 设置慢查询阈值为1秒(别手软!)
SET GLOBAL long_query_time = 1;
-- 未使用索引的查询也记录(抓出隐藏杀手)
SET GLOBAL log_queries_not_using_indexes = ON;
执行完这三条命令,你的MySQL就变成了"测谎仪"。第二天打开慢查询日志,绝对会发现新大陆(保准刺激)!
第二式:EXPLAIN大法好
遇到慢查询先别急着改代码,掏出这个杀手锏:
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'PAID';
重点盯梢这几个列:
- type:ALL就是全表扫描(死刑宣告)
- rows:扫描行数超过1000就要警惕
- Extra:出现"Using temporary"或"Using filesort"立即报警!
第三式:索引的正确打开方式
常见翻车现场:
- 给性别字段加索引(值太少没卵用)
- 索引字段顺序乱排(白瞎了组合索引)
- 索引列参与计算(
WHERE YEAR(create_time) = 2023
)
正确姿势:
-- 组合索引黄金法则:高频查询字段在前,区分度高字段优先
CREATE INDEX idx_user_status ON orders(user_id, status);
-- 巧用覆盖索引(查询字段全在索引里)
SELECT user_id, order_no FROM orders WHERE status = 'PAID';
进阶玩家必备骚操作
参数调优三板斧(配置文件警告)
# my.cnf 核心参数(根据机器配置量力而行)
innodb_buffer_pool_size = 16G # 建议设置为物理内存的70%
innodb_log_file_size = 2G # 事务日志别抠门
max_connections = 1000 # 防连接风暴
血泪教训:某次把
innodb_buffer_pool_size
设到32G,结果服务器物理内存才16G…(那重启速度比Windows更新还刺激)
冷热数据分离大法
遇到5千万级订单表怎么办?试试这个套路:
-- 历史订单归档(按时间分表)
CREATE TABLE orders_2022 LIKE orders;
ALTER TABLE orders_2022 COMMENT='历史订单归档表';
-- 业务查询只查主表
SELECT * FROM orders WHERE create_time > '2023-01-01';
连表查询避坑指南
错误示范:
SELECT * FROM users
LEFT JOIN orders ON users.id = orders.user_id
LEFT JOIN products ON orders.product_id = products.id
WHERE users.level > 3;
优化策略:
- 用EXPLAIN检查执行计划
- 添加适当的索引
- 考虑拆分成多个简单查询
- 必要时上缓存(Redis真香)
压轴大招:监控体系搭建
必备监控指标清单
指标名称 | 报警阈值 | 检查频率 |
---|---|---|
QPS | > 5000 | 实时 |
连接数使用率 | > 80% | 5分钟 |
缓存命中率 | < 95% | 15分钟 |
磁盘IO等待时间 | > 200ms | 1分钟 |
Prometheus+Granafa监控方案
(图示:包含QPS、慢查询、连接数、缓存命中率等关键指标)
终极奥义:调优不是玄学!
最后送大家调优三原则:
- 先测量再优化(拒绝盲目操作)
- 先索引再配置(索引收益最大)
- 先单点再全局(别想一口吃成胖子)
记住:没有最好的配置,只有最适合业务的配置!调优是个持续过程,就像健身一样——管住SQL乱写,迈开监控步伐,你的数据库迟早练出八块腹肌!
调优后效果:某物流系统日均处理订单从50万提升到300万,服务器数量反而减少40%(运维小哥终于不用007了)