ANALYZE TABLE 能让查询变快，因为它更新表统计信息（如 cardinality），使优化器准确选择索引和执行计划；适用于 InnoDB 表，需在批量 DML、冷表启用或 cardinality 异常时手动执行。
为什么 ANALYZE TABLE 能让查询变快
表统计信息不准时，优化器会误判索引选择性、行数分布，导致选错索引甚至全表扫描。analyze table 重新采样数据，更新 mysql.innodb_table_stats 和 information_schema.statistics 中的关键值（比如 cardinality），直接影响后续 explain 输出的 rows 和 key 字段。
常见错误现象：EXPLAIN 显示走了索引但实际慢；新增大量数据后某条查询突然变慢；WHERE 条件字段明明有索引却走 type: ALL。
- 只对 InnoDB 表有效（MyISAM 已废弃，且统计方式不同）
- 不会锁表，但会短暂加 MDL 读锁，高并发写入时可能轻微阻塞新查询编译
- 默认采样约 10–20 页（非全量扫描），速度较快；若表极不均匀（如某值占 95%），可配合
innodb_stats_persistent_sample_pages调大采样页数
什么时候必须手动执行 ANALYZE TABLE
MySQL 不会自动触发统计更新，尤其在以下场景下容易“过期”：
- 批量导入/删除超过 10% 行数后（例如用
LOAD DATA INFILE或DELETE FROM ... LIMIT） - 长期未访问的冷表首次被高频查询，且之前统计是建表时生成的
- 执行了
ALTER TABLE ... ENGINE=InnoDB或OPTIMIZE TABLE（后者会顺带做一次ANALYZE，但前者不会） - 发现
SHOW INDEX FROM tbl中Cardinality列为 0 或明显偏离实际唯一值数量
ANALYZE TABLE 的参数和陷阱
ANALYZE TABLE 本身没有参数，但行为受全局配置影响，容易踩坑的地方集中在权限和并发上：
- 需要
SELECT+INSERT权限（不是ALTER）；若用普通账号执行失败，错误信息是ERROR 1227 (42501): Access denied; you need ... privilege - 对分区表，
ANALYZE TABLE tbl默认分析所有分区；若只想分析某一分区，得写成ANALYZE TABLE tbl PARTITION(p2024) - 在从库上执行无效（从库不维护自己的统计信息，完全复用主库的
ANALYZE日志或靠复制同步） - 不要在凌晨低峰期盲目全库跑
ANALYZE TABLE—— 某些小表可能因采样偏差反而让统计更差，建议优先处理大表或近期 DML 频繁的表
如何验证 ANALYZE 是否生效
别只信“Query OK”，要直接查统计是否更新：
SELECT table_name, cardinality FROM information_schema.STATISTICS WHERE table_schema = 'your_db' AND table_name = 'your_table' AND column_name = 'your_index_col';
对比执行前后 cardinality 值变化；再用 EXPLAIN SELECT ... 看 rows 预估是否更贴近真实返回行数。如果没变，大概率是权限不足、表名写错，或者该表根本没被 InnoDB 引擎管理（比如是视图或临时表）。
复杂点在于：统计信息只是优化器的输入之一，即使 ANALYZE 正确执行，也可能因 SQL 写法（如函数包裹条件）、隐式类型转换、或优化器开关（optimizer_switch）导致最终计划不变。这时候得结合 EXPLAIN FORMAT=JSON 里的 used_columns 和 range_analysis 段落看它到底信了哪些统计。
