MariaDB 10.3升级至10.5后执行计划异常及独立引擎统计问题

一、是否需要使用独立引擎统计信息？ #

• 如果业务存在大量复杂多表关联、依赖非InnoDB原生统计支持的字段（如varbinary/blob）做过滤查询，独立统计表（persistent stats）能提供更精准的统计数据，有助于优化执行计划。
• 若切换到use_stat_tables='never'后执行计划更优，且业务查询逻辑简单，InnoDB自带的统计足够支撑，完全可以维持该配置，无需强行启用独立统计。

二、正确启用独立引擎统计信息的操作步骤 #

• 从库生成统计，规避主库锁表风险：
  • 在从库执行ANALYZE TABLE tbl_name PERSISTENT;（仅统计查询常用的过滤/关联字段），若必须统计所有字段（包括varbinary/blob），才使用ANALYZE TABLE tbl_name PERSISTENT FOR ALL;——但需注意MariaDB对大字段的统计支持有限，结果可能不够精准。
  • 确认主从同步包含mysql.table_stats、mysql.column_stats这两个系统表（默认同步，若有复制过滤规则需检查），确保从库的统计数据同步到主库。
• 让统计信息在主库生效：
  • 主库执行FLUSH TABLE tbl_name;，或10.5+版本用ANALYZE TABLE tbl_name PERSISTENT SKIP_LOCKED;（避免锁表）。
  • 验证统计是否生效：查询SELECT * FROM mysql.table_stats WHERE table_name='tbl_name';和SELECT * FROM mysql.column_stats WHERE table_name='tbl_name';，确认存在有效数据。
• 若执行后执行计划未改善：
  • 用SELECT @@use_stat_tables;确认配置确实是preferably_for_queries。
  • 尝试FLUSH STATUS;或重启mysqld（极端情况），确保统计信息加载到内存。

三、独立统计表为空时，切换use_stat_tables导致执行计划不同的原因 #

这不是bug，是MariaDB优化器统计优先级逻辑的正常表现：

• 当use_stat_tables='preferably_for_queries'时，优化器会优先尝试读取独立统计表，即使表为空。此时优化器会判定“无可用独立统计”，但 fallback 的估算逻辑和never模式不同：
  • preferably_for_queries模式下，优化器会基于“无独立统计”的状态采用更保守的基数估算（比如默认假设数据分布不均匀）；
  • never模式下，优化器直接跳过独立统计表，完全使用InnoDB的原生采样统计——而10.3到10.5版本中InnoDB的采样逻辑、优化器成本模型有更新，导致估算结果和10.3时期不同，最终影响执行计划。

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