确认统计信息错误需先验证：若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），差一个数量级基本能坐实。
常见干扰项包括：
- 查询里用了函数，如
WHERE DATE(log_dt) = '2024-01-01'，索引直接失效，ANALYZE无意义 -
city_id是INT，但传参是字符串'565'，触发隐式转换，优化器不敢走索引 -
innodb_stats_persistent = OFF且innodb_stats_on_metadata = OFF，统计信息压根不持久，ANALYZE后可能下次查又回退
ANALYZE TABLE 执行时要注意什么
它不是“刷新缓存”，而是重新采样索引页、重算 CARDINALITY 和 ROWS。默认只采样约 10–20 个页，对大表或数据倾斜严重的情况，精度可能仍不够。
- 仅对
InnoDB表有效；MyISAM得用myisamchk -a - 执行期间会加读锁，大表务必避开高峰期，否则阻塞写入
- 想提高精度，可临时调大采样页数：
SET GLOBAL innodb_stats_persistent_sample_pages = 100，再执行ANALYZE TABLE - 如果
innodb_stats_persistent = ON（推荐），统计结果会落盘，后续自动更新阈值由innodb_stats_auto_recalc控制
为什么 ANALYZE 后还是没换索引
执行完 ANALYZE TABLE，EXPLAIN 的 key 字段没变？优先排查这三件事：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查是否真的生效：查
information_schema.STATISTICS表，确认CARDINALITY值已变动，而非只是时间戳更新 - 确认没有被
FORCE INDEX或USE INDEX硬编码覆盖，这类提示会完全绕过优化器决策 - 统计信息更新后，优化器可能仍沿用旧计划缓存。哪怕
ANALYZE TABLE成功，也要确认查询是否触发了计划重编译——有时需要FLUSH TABLES或重启连接才能生效
TDSQL for MySQL 还得额外开两个开关
在 TDSQL for MySQL（TXSQL）中，光跑 ANALYZE TABLE 不够。即使 InnoDB 在后台自动更新了统计信息（比如索引区分度 rec_per_key），也不会主动通知优化器，除非打开关键开关：
-
innodb_stats_notify_change = ON：让 InnoDB 更新后主动通知 Server 层优化器 -
txsql_recalc_table_stats_after_manual_close = ON：确保表被手动关闭后重新打开时，触发统计重算
这两个参数默认常为 OFF，必须用 mysql_param_modify 工具显式修改，路径类似 /data/tdsql_run/4006/mysqlagent/conf/mysqlagent_4006.xml，并指定对应 set_id。
