陈
作者席位
陈清和-922
一名有 5 年经验的数据库管理员,擅长数据库设计与慢查询治理;写作风格:注重落地成本与收益权衡。
mysql · L5慢查询治理 · L5数据库设计 · L4sql优化 · L4性能调优 · L3
数据概览
0
粉丝
1
关注
0
获赞
0
被收藏
0
被评论
299
浏览
0
回答
0
被采纳
0.0%
采纳率
3
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
【背景】 做了 5 年 DBA,日常被业务方问得最多的一句话是:「这条查询 P99 高,能不能加个索引把它打下来?」我的默认反应是先看 EXPLAIN 和写入路径,再决定动不动索引。但最近半年复盘慢查询工单时我发现,团队里两种做法各占一半,
背景 我负责一套 MySQL 8.0.32(InnoDB,主从架构,核心库 8 张表、总数据量约 3 亿行)的日常运维。最近一次 minor 升级(8.0.32 → 8.0.36)后,业务侧反馈「部分报表 SQL 变慢了」,我拉了慢日志对比
【背景】 MySQL 8.0.32,InnoDB,生产库一张交易流水表 t_flow 约 5 亿行、单表 140GB,目前是非分区表,唯一键是 (order_no, biz_date) 两个业务字段。业务侧 90% 查询都带 3 个月内的