不能。mysql分区表仅按规则分散数据，删除分区虽快，但自动归档需自行实现触发、存储、校验等逻辑；误操作易致数据丢失或全表扫描，须严格遵循时间字段分区、避免函数过滤、定期导出+冷存+验证后删分区。
分区表能自动归档旧数据吗
不能。MySQL 分区表本身不提供“自动归档”能力，它只负责把数据按规则分散到不同物理段（PARTITION），删掉一个分区确实快，但触发时机、归档目标（比如存到 S3 或冷备库）、数据校验等全得自己写逻辑来兜底。
常见错误现象：DROP PARTITION 执行后发现应用查不到数据了——其实是没同步更新 WHERE 条件范围，或误删了还在用的分区；更隐蔽的是，分区字段和查询条件不匹配，导致全表扫描，性能反而更差。
使用场景：适合时间维度明确、读写分离清晰的表，比如日志、订单、监控记录，且业务能接受“按月/周切分 + 定期清理最老分区”。
- 必须用
DATE或DATETIME类型字段做分区键（如created_at），且该字段要高频出现在WHERE条件里 - 避免在分区键上用函数，比如
WHERE YEAR(created_at) = 2023会让分区失效 - 新建分区要用
ALTER TABLE ... REORGANIZE PARTITION或ADD PARTITION，不能靠 DML 自动产生
如何安全地把旧分区数据导出到冷存储
别直接 SELECT ... INTO OUTFILE，那个文件只能存在 MySQL 服务端本地磁盘，还依赖 secure_file_priv 配置。真正可落地的方式是客户端拉取 + 外部存储写入。
实操建议：
- 用
mysqldump --where="created_at --no-create-info - 导出后立刻校验行数：
SELECT COUNT(*) FROM t WHERE created_at 和本地文件行数比对 - 压缩并打时间戳：
gzip -c dump_2022Q4.sql > dump_2022Q4.sql.gz，再上传到对象存储（如aws s3 cp） - 确认上传成功后再执行
ALTER TABLE t DROP PARTITION p_2022_q4
为什么 DROP PARTITION 后空间没释放
因为 MySQL 的 InnoDB 表空间不会自动收缩。即使删了整个分区，ibd 文件大小也不变，磁盘空间仍在占用。
根本原因：InnoDB 的 TRUNCATE PARTITION 实际是重建分区，但默认复用原表空间；只有显式启用 innodb_file_per_table=ON 且每个分区单独存为 .ibd，才能做到删分区即删文件。
检查方法：SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'; 看是否每个 PARTITION_NAME 对应独立文件。
- 建表时必须加
ENGINE=InnoDB ROW_FORMAT=DYNAMIC和KEY_BLOCK_SIZE=0 - 已有表无法直接改成分区表+独立文件，得
CREATE TABLE ... PARTITION BY RANGE ...再INSERT INTO ... SELECT迁移 - 删完分区后，用
OPTIMIZE TABLE t强制重建，但会锁表，慎用
分区策略选 RANGE 还是 LIST，会影响归档效率吗
会影响。RANGE 按连续区间切分（比如按月），天然适配时间归档；LIST 是枚举值匹配，比如按地区 ID 归档，没法表达“所有小于某时间”的语义。
错误用法示例：PARTITION BY LIST (YEAR(created_at)) —— 这样每年都要手动 ALTER TABLE ... ADD PARTITION，漏加就写不进新数据，而且无法用 条件高效裁剪分区。
- 归档场景只用
PARTITION BY RANGE COLUMNS(created_at)，支持多列、非函数表达式 - 分区表达式必须是确定性函数，禁止用
NOW()、CURRENT_DATE等运行时值 - 提前建好未来 3–6 个月的分区，用脚本定期检查并补充，避免业务写入失败
WHERE created_at ，实际执行计划里却显示 <code>type: ALL，说明 MySQL 根本没走分区索引。每次改分区逻辑前，先跑一遍 EXPLAIN PARTITIONS。
