MySQL 8.0升级后分区表变慢主因是分区裁剪失效，需检查WHERE条件是否函数包裹分区键、类型是否一致、分区类型是否支持裁剪，并用EXPLAIN PARTITIONS验证。
升级 MySQL 8.0 后分区表性能没变快、反而更慢，大概率不是分区本身失效了，而是旧配置残留、统计信息过期、或执行计划被新优化器“带偏”了——得逐层验证，不能直接重做分区。
检查分区裁剪是否真正生效
EXPLAIN 显示 type: ALL 或 Extra 里没出现 PARTITION 字样，说明查询根本没走分区裁剪。常见原因有：
- WHERE 条件里用了函数包裹分区键，比如
WHERE DATE(created_at) = '2024-01-01'，会强制全分区扫描 - 分区键类型和查询参数类型不一致，例如分区键是
DATETIME，但传入的是字符串'2024-01-01'，触发隐式转换 - 使用了非 RANGE/LIST/COLUMNS 分区，比如 HASH 分区，在范围查询下天然无法裁剪
- MySQL 8.0 的
INFORMATION_SCHEMA.PARTITIONS里PARTITION_DESCRIPTION值异常（如显示 NULL），说明分区定义已损坏
验证方式：EXPLAIN PARTITIONS SELECT * FROM env_metrics WHERE created_at >= '2024-09-01' AND created_at ，看 <code>partitions 列是否只列出目标分区。
ANALYZE TABLE 不作用于单个分区？
MySQL 8.0 中 ANALYZE TABLE 默认只更新全表统计，不会自动刷新每个分区的 INNODB_TABLESTATS。而分区裁剪依赖各分区独立的行数估算，旧统计会导致优化器误判。
- 必须显式对每个活跃分区执行：
ALTER TABLE env_metrics ANALYZE PARTITION p202409; - 别用
OPTIMIZE PARTITION：InnoDB 不支持该语法，实际会重建整表并报 warning - 批量分析所有分区可写脚本生成语句：
SELECT CONCAT('ALTER TABLE env_metrics ANALYZE PARTITION ', PARTITION_NAME, ';') FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'env_metrics' AND PARTITION_NAME IS NOT NULL; - 长期建议开启
innodb_stats_persistent = ON，避免每次重启后统计清零
重建分区时 ALGORITHM=INPLACE 失效怎么办
想在线加新分区或调整边界，用 ALTER TABLE ... REORGANIZE PARTITION 却卡住或退化为 COPY 模式，往往因为：
- 表含全文索引、虚拟列、外键约束，
ALGORITHM=INPLACE被禁用 - 分区键字段上存在函数索引（如
INDEX idx_dt ((DATE(created_at)))），8.0.23+ 才支持 inplace 重建 -
innodb_large_prefix = OFF且字段长度超限制，导致内部退化 - 长事务正在读取该表，DDL 会等待直到事务结束（
SHOW PROCESSLIST可查）
安全做法：ALTER TABLE env_metrics REORGANIZE PARTITION p202408 INTO (PARTITION p202408 VALUES LESS THAN (UNIX_TIMESTAMP('2024-09-01')), PARTITION p202409 VALUES LESS THAN (MAXVALUE)) ALGORITHM=INPLACE, LOCK=NONE;，执行前先确认 SELECT @@innodb_large_prefix; 和 SHOW CREATE TABLE env_metrics;。
为什么 DROP PARTITION 比 DELETE 快，但磁盘空间没释放？
DROP PARTITION 瞬间删除元数据和物理文件，但若你看到 DATA_FREE 仍很高，问题不在分区本身，而在 InnoDB 表空间管理逻辑：
-
DROP PARTITION后空闲空间归还给表空间（ibdata1或独立.ibd），但不会自动返还给操作系统；只有整个表ALTER TABLE ... ENGINE=InnoDB才可能收缩.ibd - 如果
innodb_file_per_table = OFF，所有分区共享ibdata1，DROP 后空间永远留在 ibdata1 内，无法回收 -
DATA_FREE高 ≠ 真碎片：先算平均行大小SELECT (data_length + index_length) / table_rows AS avg_row_size FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'env_metrics';，若远高于实际字段总长，才是真需处理的碎片
真正要释放磁盘，得在确认 innodb_file_per_table = ON 后，对整表执行 ALTER TABLE env_metrics ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE; ——但这会锁表几秒到几分钟，务必选低峰期。
分区表性能问题最常卡在“以为改了 DDL 就完事”，其实关键路径是：分区裁剪验证 → 分区级统计刷新 → 执行计划比对 → 磁盘空间归属确认。跳过任意一环，都可能白忙半天。
