40 列宽表（行宽~1.5KB）+ 800 写 QPS：覆盖索引省回表 vs 写放大，盈亏平衡点怎么量化？有没有可复现的判定流程？

背景

我负责一套商户结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 32G）。核心表 t_trade_detail 约 2800 万行，40 列宽表（大量 VARCHAR(128) 的业务字段 + DECIMAL 金额列），SHOW TABLE STATUS 单表约 42GB，现有 5 个二级索引。写入画像：INSERT ~600 QPS + 状态 UPDATE ~200 QPS。

现象

一条高频查询（对账明细列表，~300 QPS）：

SELECT merchant_id, status, order_no, amount, created_at, pay_channel, settle_status
FROM t_trade_detail
WHERE merchant_id = ? AND status IN ('SETTLED','SETTLING')
ORDER BY created_at DESC
LIMIT 20

现状走 idx_merchant_status_time (merchant_id, status, created_at)，EXPLAIN：type=range，key 正常，单次 P50 ~25ms、P99 ~180ms（并发 300 QPS 下抖动明显）。performance_schema 里回表相关等待占比不低，我怀疑瓶颈在回表随机 I/O——宽表行宽大，一次回表可能跨多个 extent，buffer pool 装得下索引却装不下数据页（和 #2417 描述的「半命中」形态很像）。

已尝试与结果

1. 加大 buffer_pool 32G→48G：P99 略降（180→150ms），但没有质变，说明不是单纯容量问题。
2. 考虑覆盖索引 idx_merchant_status_time_cover (merchant_id, status, created_at, order_no, amount, pay_channel)：本地压测单条 P99 降到 ~8ms。但顾虑：这条索引要携带 order_no VARCHAR(64) + amount DECIMAL + pay_channel VARCHAR(32)，索引体积预估膨胀到主表数据量的 30~40%（~15GB），且 800 QPS 写入每个事务都要维护它——写放大在 #2605 的讨论里大家算过，但我没有针对宽表大行宽场景的量化数据。
3. 改写 SQL 只取必要列：业务方不答应，列表页要展示 pay_channel 和 order_no，砍列等于砍功能。

我卡住的核心问题（期望答案形态）

不是「要不要加覆盖索引」的定性讨论（#878 和 #2417 已经把账单讲清楚了），而是求一个可复现的量化判据，具体想问三点：

1. 回表 I/O 成本的实测方法：在宽表（行宽 1KB+）场景下，怎么把「一次回表的真实 I/O 代价」从 performance_schema / sys 库里拆出来？我目前只能看 innodb_buffer_pool_reads 总量，分不清是索引页 miss 还是数据页 miss——有没有比看总命中率更细的观测手段（比如按表拆的 file_ios 或 table_iostat）？
2. 盈亏平衡的量化公式：假设覆盖索引体积膨胀 ΔGB、写 QPS 为 W，回表单次 I/O 代价为 C_io（ms），查询 QPS 为 R——在什么 R/W 比值和行宽下，覆盖索引的「省回表收益」会低于「写放大 + buffer pool 挤占」的成本？有没有人实际跑过这个对比实验并给出数据点？我需要一个可以代入自己数字做判断的模型，而不是「看场景」。
3. 中间路线：如果覆盖索引太重、普通索引回表太慢，有没有第三种方案？比如：只把 order_no 塞进索引（半覆盖，省掉最大的 VARCHAR 回表成本）、或者把列表页的 pay_channel 拆到关联小表、或者用 innodb_buffer_pool 的 sub-pool 隔离热数据页？你们线上走过哪条？

引用依据

• #878（覆盖索引的隐形账单：P99 从 12ms 涨到 68ms 的取舍账本）——把「索引膨胀 + 写放大 + 缓存效率」三笔账讲得很清楚，但缺宽表大行宽场景的数据。
• #2417（「索引命中但数据页冷」的半命中查询）——我怀疑我的 P99 抖动就是这种形态，想请教怎么精确确认。
• #2605（高写入表加第 9 个二级索引后写入 P99 涨 40%）——写放大的量化方向一致，但那是窄表场景，我的表行宽是它的 5 倍以上。

期望的回答：有具体观测 SQL / 压测脚本 / 数据点支撑的量化判据，最好能给出一个「代入我的参数（2800 万行 / 40 列 / 800 写 QPS / 300 读 QPS / 行宽 1.5KB）就能出结论」的决策路径。