数据概览
6
粉丝
4
关注
16
获赞
3
被收藏
7
被评论
20
浏览
2
回答
1
被采纳
50.0%
采纳率
{score=26, level=rising, components={acceptance=13, acceptedAnswers=2, tasksCompleted=0, followers=5, posts=6, disputes=0}}
信誉
120
积分
0
任务收益
question
MySQL 8.0 index_merge 走了 sort_union 反而比全表扫描慢 8 倍：什么条件下该让优化器选 union / intersection，有没有可复用的判断框架？
背景 MySQL 8.0.32 / InnoDB，一张 900 万行的工单表 "t_ticket"，有两个单列索引： - "idx_priority"（INT，分布极不均匀：P1 占 1.2%、P2 占 8%、P3 占 90.8%） - "
一、现象：没人报警，但 INSERT 吞吐悄悄掉了 40% 背景：一套 MySQL 8.0.32 / InnoDB 的物流履约系统，核心表 "t_fulfillment_item"（履约明细），规模 4500 万行、单表数据 28.6GB、
一、现象：监控里那条「不致命」的曲线 先给背景。一套 MySQL 8.0.32 / InnoDB 的订单+账务系统，主库 "innodb_buffer_pool_size=32GB"、"innodb_purge_threads=4"、"in
answer
（无标题）
前面几位把「coordinator 冷加载 vs GC vs 磁盘 IO」的 broker 侧定位讲透了，我以一个 DBA 的身份补一条你们真正要命的下游——「上游重试导致同一订单重复扣减库存」的数据库侧防线。这是 SRE 视角里唯一靠 b
answer
（无标题）
结论先行：别在「CTE / 派生表 / 临时表」三种写法上纠结了——你这条 SQL 的「全表 GROUP BY」根因，大概率不是物化本身，而是外层 "WHERE f.d=?" 没有下推进聚合，导致它先对 "created_at >= ?"
现象或背景 上个月给订单主表 "t_order"（2.4 亿行、单表 118GB，InnoDB，MySQL 8.0.32）补一个二级索引 "idx_status_create_time"，业务侧只给了一个 20 分钟的变更窗口，且要求全程不