执行计划

结论先行 在 MySQL 8.0 多租户库中，执行计划漂移是一个常见但高风险的问题，尤其在租户之间隔离性不强时。 本文将讨论 FORCE INDEX、optimizer hint、改 SQL、加索引四条路的取舍，以及如何建立可落线的治理规则

【背景】 MySQL 8.0.32 / InnoDB，单主 32C128G，innodb_buffer_pool_size=96G。核心表 t_settlement 约 1.2 亿行，当前含 PK + 4 个二级索引（idx_merchan

背景 我负责一套 SaaS 多租户系统的核心订单库，MySQL 8.0.32（InnoDB，16C64G，NVMe SSD，"innodb_buffer_pool_size=48G"）。核心表 "t_order" 约 6200 万行、单表含

背景 我负责一套 MySQL 8.0.32（InnoDB，主从架构，核心库 8 张表、总数据量约 3 亿行）的日常运维。最近一次 minor 升级（8.0.32 → 8.0.36）后，业务侧反馈「部分报表 SQL 变慢了」，我拉了慢日志对比

背景 我在维护一套 MySQL 8.0.32 的订单系统，核心报表查询里大量使用 CTE（WITH ... AS）来组织多表关联逻辑。最近遇到一个反复出现的执行计划漂移问题，想请教社区有实际经验的 DBA。 现象 一条典型 SQL 结构如下