1. 当索引统计信息"过期"会发生什么？
想象一下你每天走同一条路回家，突然某天路口新增了红绿灯但导航没更新，结果你堵在路口半小时——这和MySQL索引统计信息过期的原理很像。当数据库不知道数据分布的真实情况时，优化器可能做出错误决策。
典型症状：
- 昨天还飞快的查询今天突然变慢
- EXPLAIN显示走了全表扫描而非索引
- 相同条件的查询在不同时间段执行计划不同
示例：某电商订单表异常查询（MySQL 8.0）
-- 创建测试表
CREATE TABLE orders (
id INT PRIMARY KEY,
user_id INT,
status ENUM('pending','shipped','completed'),
created_at DATETIME,
INDEX idx_status (status)
) ENGINE=InnoDB;
-- 插入10万条测试数据（90%是completed状态）
INSERT INTO orders
SELECT
n,
FLOOR(RAND()*1000),
IF(n%10=0, 'pending', 'completed'),
NOW()
FROM nums WHERE n <= 100000;
-- 强制立即更新统计信息（正常情况不要这样做）
ANALYZE TABLE orders;
-- 查看健康查询
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
/* 输出：
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------+
| 1 | SIMPLE | orders | NULL | ref | idx_status | idx_status | 1 | const | 100 | 100.00 | NULL |
+----+-------------+--------+------------+------+---------------+------------+---------+-------+------+----------+-------+
*/
-- 突然批量更新数据（把9万条改成shipped）
UPDATE orders SET status = 'shipped' WHERE status = 'completed' LIMIT 90000;
-- 此时统计信息未更新，查询计划依然错误
EXPLAIN SELECT * FROM orders WHERE status = 'shipped';
/* 错误计划：
+----+-------------+--------+------------+------+---------------+------+---------+------+--------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------+---------+------+--------+----------+-------------+
| 1 | SIMPLE | orders | NULL | ALL | idx_status | NULL | NULL | NULL | 100226 | 10.00 | Using where |
+----+-------------+--------+------------+------+---------------+------+---------+------+--------+----------+-------------+
*/
2. 为什么统计信息会"偷懒"？
MySQL采用抽样统计策略，默认情况下：
- 当表数据变化超过10%时触发自动更新
- 统计信息存储在
mysql.innodb_index_stats和mysql.table_stats - 采样页数默认20页（可通过innodb_stats_persistent_sample_pages调整）
常见触发场景：
- 批量导入/删除数据后未及时维护
- 业务高峰期避免统计更新消耗资源
- 表使用非持久化统计（innodb_stats_persistent=OFF）
3. 手动更新统计信息的正确姿势
3.1 常规维护方案
-- 完整统计（适用于中小表）
ANALYZE TABLE orders;
-- 快速采样（8.0+版本）
ANALYZE TABLE orders PERSISTENT FOR ALL;
3.2 自动化维护策略
0 3 * * * mysql -e "ANALYZE TABLE db1.orders, db1.users;"
3.3 动态调整参数
-- 增加采样精度（需要更多存储空间）
SET GLOBAL innodb_stats_persistent_sample_pages = 50;
-- 降低自动更新阈值
SET GLOBAL innodb_stats_auto_recalc = ON;
4. 不同场景下的选择策略
| 场景 | 推荐方案 | 注意事项 |
|---|---|---|
| 数据仓库定期ETL | 每次ETL后手动ANALYZE | 避开业务高峰期 |
| OLTP高频更新表 | 设置innodb_stats_auto_recalc | 监控服务器资源使用 |
| 超大型表（TB级） | 使用ANALYZE TABLE PERSISTENT | 需要评估执行时间 |
| 主从架构 | 只在从库执行维护 | 避免主库额外负担 |
5. 你可能遇到的"坑"
5.1 统计风暴问题 某电商在凌晨同时ANALYZE 200张表，导致实例CPU打满——建议错峰执行并控制并发量。
5.2 主从不一致 在主库执行ANALYZE后，从库统计信息未同步，导致查询计划差异——建议维护脚本中跳过复制。
5.3 过度优化陷阱
某DBA每小时执行ANALYZE，反而导致性能下降——通过监控Handler_read%指标判断必要性。
6. 最佳实践总结
- 监控先行：设置
information_schema.tables的UPDATE_TIME监控 - 分级处理：核心表每天维护，普通表每周维护
- 版本特性：MySQL 8.0的直方图统计可补充基数估算
- 平衡法则：在统计准确性和资源消耗间找到平衡点
就像定期给汽车做保养，索引统计信息的维护需要系统化的策略。通过理解数据访问模式、合理设置参数、制定维护计划，可以让你的数据库保持"耳聪目明"，避免那些突如其来的性能悬崖。
技术栈说明：本文所有示例均基于MySQL 8.0社区版，涉及参数可能在5.6/5.7版本存在差异。建议生产环境先做兼容性测试。