数据概览
23
粉丝
2
关注
39
获赞
8
被收藏
25
被评论
603
浏览
1
回答
0
被采纳
0.0%
采纳率
24
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
广受欢迎
已解锁
收获 5 位关注者
高山仰止
已解锁
内容被他人引用 1 次
背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分
答
（无标题）
结论先说：这不是"刷新时机"问题，而是 optimizer 在"索引命中行数骤降"后，主动用全表顺序扫替代索引随机回表的合理决策。 你要解决的不是"让统计信息别变"，而是"在统计信息已经变了的前提下，锁住这条 SQL 的执行计划"。下面按落
背景：MySQL 8.0.36，InnoDB，REPEATABLE READ。一张 3200 万行的工单表 tickets，主键 id（自增），二级索引 idx_tenant_status (tenant_id, status, creat
背景：MySQL 8.0.36，单主 + 2 从（半同步 rpl_semi_sync_master_wait_for_slave=ON），主库 32C/128G/ESSD PL2，从库同规格但磁盘是 SSD。binlog 日均增长约 200
背景：MySQL 8.0.36，InnoDB，一张约 5000 万行的日志表 access_log，主键 id，二级索引 idx_path (path)，idx_path_status (path, status)，idx_time (cr
背景：MySQL 8.0.36，主从架构（单主 + 1 从，半同步），主库一台 16C/64G/ESSD，从库同规格。业务在每天 02:00–03:30 跑一次订单归档批处理：把 orders 表里 create_time 早于 90 天的
背景：MySQL 8.0.36，InnoDB，一张约 1200 万行的订单表 orders，现有复合索引 idx_a_b_c (a, b, c)，a 是租户 id（bigint，等值），b 是订单时间（datetime，范围），c 是状态（
背景：MySQL 8.0.36，InnoDB 单表（约 8000 万行），主键为自增 id。业务方反馈：连续 2 天内 id 出现约 3 万次的跳号，期间没有观察到批量插入，也没有触发器或 AFTER INSERT 钩子。 现象： 1) S
结论先行 慢查询治理不是「加索引」三个字能糊弄的，正确顺序是：先定位（EXPLAIN + 慢日志）→ 再判断（是索引问题还是写法问题）→ 最后才是加索引或改写 SQL。我 3 年在 DBA 岗位上踩过的坑，绝大多数都败在「上来就加索引」这一