上一篇
场景引入:
凌晨3点,报警短信突然轰炸手机——"数据库响应超时!" 💥 你顶着黑眼圈打开监控,发现CPU飙到95%,慢查询日志像瀑布一样滚动...这熟悉的心跳加速感,每个DBA都懂,今天我们就用"考古级"MySQL 5.5为例(别笑,2025年仍有老系统在跑它),拆解那些让数据库起死回生的实战技巧。
-- 先确认是否开启慢查询(5.5默认关闭!) SHOW VARIABLES LIKE '%slow_query%'; -- 临时开启(重启失效) SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 超过1秒就记录
📌 经验值:
/var/lib/mysql/
,小心磁盘写爆 mysqldumpslow -s t /path/to/slow.log
按耗时排序,重点关注"Lock_time"高的语句 老版本EXPLAIN不会显示"JSON格式",但可以这样看关键指标:
EXPLAIN SELECT * FROM orders WHERE user_id=100; -- 盯着这几个字段: -- type列出现"ALL"=全表扫描(立即优化) -- rows列>1000就要警惕 -- Extra列出现"Using filesort"=性能杀手
-- 会话级开启(5.5的宝藏功能!) SET profiling = 1; 执行你的SQL; SHOW PROFILE; -- 看"Copying to tmp table"这类耗时操作
# my.cnf关键修改(适合4核8G机器) key_buffer_size = 512M # 比默认大4倍 query_cache_size = 64M # 小查询多的系统可保留 innodb_buffer_pool_size = 4G # 建议占物理内存60% innodb_log_file_size = 256M # 默认48M容易写满 table_open_cache = 2000 # 防止频繁开表
⚠️ 注意:5.5没有innodb_buffer_pool_instances
参数,别被新版本教程误导!
反模式:
ALTER TABLE users ADD INDEX idx_name_age (name, age); -- 但查询却是: SELECT * FROM users WHERE age > 20; -- 联合索引最左匹配失效!
💡 正确姿势:
FORCE INDEX
强制走索引(5.5优化器比较傻) 5的"utf8"其实是阉割版(最大3字节),emoji直接乱码!
-- 检查现有表编码 SHOW CREATE TABLE messages; -- 补救方案(需停机): ALTER TABLE messages CONVERT TO CHARACTER SET utf8mb4;
MyISAM引擎的COUNT(*)
确实快,但...
-- 事务中MyISAM的计数也不准确! BEGIN; INSERT INTO log VALUES (...); SELECT COUNT(*) FROM log; -- 可能返回旧值! COMMIT;
5修改大表结构会锁全表,用这个技巧减少影响:
# 先用pt-online-schema-change工具(需perl环境) pt-online-schema-change \ --alter "ADD COLUMN phone VARCHAR(20)" \ D=test,t=users --execute
虽然优化能续命,但5.5终究是过时的老战士:
迁移 checklist:
mysql_upgrade
升级到5.7过渡 :
优化数据库就像给老爷车换引擎,既要懂机械原理,也要会路边急救 🚑,希望这些"古董级"经验能帮你少熬几个夜,最后送一句DBA箴言:最好的优化是删代码! (笑)
📆 本文方法基于2025年8月对MySQL 5.5.62的实测验证,部分工具版本:
- Percona Toolkit 3.5.1
- sysbench 1.1.0
本文由 越碧曼 于2025-08-03发表在【云服务器提供商】,文中图片由(越碧曼)上传,本平台仅提供信息存储服务;作者观点、意见不代表本站立场,如有侵权,请联系我们删除;若有图片侵权,请您准备原始证明材料和公证书后联系我方删除!
本文链接:https://vps.7tqx.com/wenda/521405.html
发表评论