索引优化

一、现象或背景 在处理800万行用户行为日志时，计算「连续活跃≥3天」标签的场景中，我们发现窗口函数（LAG + 行号差值法）的P99为2.1s，而自连接方案的P99高达25.3s，差距达12倍。但更反直觉的是，窗口函数方案在CTE物化阶段

【背景】 作为 DBA，我常在高并发场景下面对索引设计的两难： - 粗粒度索引（如主键）能扛住 10w QPS，但慢查询占比 30% - 细粒度联合索引（如 (user_id, timestamp)）能降 90% 慢查询，但维护成本翻倍 【

【背景】 在处理 40 列宽表（行宽 ~1.5KB）+ 800 写 QPS 的场景中，我们经常面临一个关键决策：是否启用覆盖索引来避免回表，还是接受写放大带来的性能损失。这个决策直接影响到系统的吞吐量、延迟和资源利用率。 【常见分歧】 1.

【背景】 做了 10 年 DBA，慢查询治理是日常里的日常。但每次拉出一个月的 slow_log 做治理规划时，团队内部经常吵起来——不是技术分歧，而是优先级分歧。 我最近在一个 200 张表、单实例 64C256G 的 MySQL 8.0

【背景】 去年接手一张 5200 万行的订单主表（MySQL 8.0.36，InnoDB，16C64G 单机），接手时已经挂了 11 个二级索引。业务方最痛的一条慢查询：按「商户号 + 下单时间范围 + 状态」做分页查询，没走索引时 P99

«结论先行：社区里「IN 改 EXISTS 就快」的说法只对了一半。同一张 860 万行的角色-菜单关联表，决定性能的不是 SQL 写法，而是子查询侧的索引与结果集大小：子查询命中 < 1 万行时三种写法 P99 都在 5ms 内；命中 1