配置一致的Galera集群（预发/生产）生成不同查询计划的问题问询

核心差异是预发环境利用bay_depend_id索引做关联查询（ref执行类型），而生产环境选择了全表扫描+BNL（Block Nested Loop）连接，这是性能差距的直接诱因。结合你给出的环境一致前提，优先排查以下方向：

1. 统计信息过期或不准确 #

生产环境数据比预发多1个月，MySQL优化器依赖表的统计信息判断索引选择性。若统计信息未及时更新，优化器可能误判bay_depend_id索引的效率，转而选择BNL连接。

• 执行命令更新统计信息：

  ANALYZE TABLE b;
  

  更新后重新执行查询并查看执行计划，确认是否恢复索引关联。

2. 索引状态异常 #

尽管schema一致，但生产环境可能存在索引碎片过多、索引失效（如意外删除后重建不完整）的情况：

• 检查表b的索引状态：

  SHOW INDEX FROM b;
  

  对比预发环境的索引列表，确认bay_depend_id索引存在且Cardinality（基数）合理。若碎片较多，可低峰期执行OPTIMIZE TABLE b;（注意锁表风险）。

3. 优化器参数差异 #

即便整体配置相同，Docker容器内的MySQL参数可能存在细微差异，影响优化器决策：

• 对比预发和生产的优化器开关：

  SHOW VARIABLES LIKE 'optimizer_switch';
  

  重点查看block_nested_loop是否开启（默认开启，若预发环境关闭则会直接禁用BNL）。
• 检查连接缓冲区大小：

  SHOW VARIABLES LIKE 'join_buffer_size';
  

  若生产环境join_buffer_size过大，优化器可能更倾向于选择BNL连接。

4. 数据分布倾斜 #

生产环境多1个月的数据，可能导致部分bay_id对应的记录数激增，优化器认为索引关联成本高于BNL：

• 统计生产环境bay_depend_id的基数与记录分布：

  SELECT bay_depend_id, COUNT(*) FROM b GROUP BY bay_depend_id ORDER BY COUNT(*) DESC LIMIT 10;
  

  若存在某个bay_depend_id对应大量记录，可尝试强制索引验证性能：

  SELECT ... FROM b FORCE INDEX (bay_depend_id) WHERE ...;
  

  若强制索引后性能恢复，说明优化器成本计算有误，可考虑调整optimizer_cost_constants参数或重构查询。

内容的提问来源于stack exchange，提问作者urobo