如何更新MySQL统计信息修复索引选择错误

确认统计信息错误需先验证：若EXPLAIN中rows预估严重失真（如实际200行却显示8000万），且SHOW INDEX的CARDINALITY与COUNT(DISTINCT)相差一个数量级，再排除函数使用、隐式转换及innodb_stats_persistent=OFF等干扰，方可判定为统计错误。

怎么确认真是统计信息错了

别一慢就跑 ANALYZE TABLE。先看 EXPLAIN 里 rows 预估是否离谱：比如 WHERE city_id = 565 实际只返回 200 行，但 EXPLAIN 显示 rows=80000000，这就是典型基数崩了。再查 SHOW INDEX FROM table_name，对比 CARDINALITY 和真实去重数（SELECT COUNT(DISTINCT city_id) FROM table_name），差一个数量级基本能坐实。

常见干扰项包括：

1. 查询里用了函数，如 WHERE DATE(log_dt) = '2024-01-01'，索引直接失效，ANALYZE 无意义
2. city_id 是 INT，但传参是字符串 '565'，触发隐式转换，优化器不敢走索引
3. innodb_stats_persistent = OFF 且 innodb_stats_on_metadata = OFF，统计信息压根不持久，ANALYZE 后可能下次查又回退

ANALYZE TABLE 执行时要注意什么

它不是“刷新缓存”，而是重新采样索引页、重算 CARDINALITY 和 ROWS。默认只采样约 10–20 个页，对大表或数据倾斜严重的情况，精度可能仍不够。

1. 仅对 InnoDB 表有效；MyISAM 得用 myisamchk -a
2. 执行期间会加读锁，大表务必避开高峰期，否则阻塞写入
3. 想提高精度，可临时调大采样页数：SET GLOBAL innodb_stats_persistent_sample_pages = 100，再执行 ANALYZE TABLE
4. 如果 innodb_stats_persistent = ON（推荐），统计结果会落盘，后续自动更新阈值由 innodb_stats_auto_recalc 控制

为什么 ANALYZE 后还是没换索引

执行完 ANALYZE TABLE，EXPLAIN 的 key 字段没变？优先排查这三件事：

1. 检查是否真的生效：查 information_schema.STATISTICS 表，确认 CARDINALITY 值已变动，而非只是时间戳更新
2. 确认没有被 FORCE INDEX 或 USE INDEX 硬编码覆盖，这类提示会完全绕过优化器决策
3. 统计信息更新后，优化器可能仍沿用旧计划缓存。哪怕 ANALYZE TABLE 成功，也要确认查询是否触发了计划重编译——有时需要 FLUSH TABLES 或重启连接才能生效

TDSQL for MySQL 还得额外开两个开关

在 TDSQL for MySQL（TXSQL）中，光跑 ANALYZE TABLE 不够。即使 InnoDB 在后台自动更新了统计信息（比如索引区分度 rec_per_key），也不会主动通知优化器，除非打开关键开关：

1. innodb_stats_notify_change = ON：让 InnoDB 更新后主动通知 Server 层优化器
2. txsql_recalc_table_stats_after_manual_close = ON：确保表被手动关闭后重新打开时，触发统计重算

这两个参数默认常为 OFF，必须用 mysql_param_modify 工具显式修改，路径类似 /data/tdsql_run/4006/mysqlagent/conf/mysqlagent_4006.xml，并指定对应 set_id。