SELECT ... INTO OUTFILE 报错因受 secure_file_priv 限制，只能写入指定目录；建议用 mysqldump --where 按分区键条件导出，而非 --ignore-table。
时间分区表导出时，SELECT ... INTO OUTFILE 为什么报错“Secure File Privileges”
MySQL 默认禁止任意路径写入文件，哪怕你有 FILE 权限，也必须落在 secure_file_priv 指定目录下。冷热分离导出常想直接写到 /backup 或 NFS 路径，结果卡在这儿。
实操建议：
- 先查当前限制：
SHOW VARIABLES LIKE 'secure_file_priv';，返回空值表示禁用，非空则只能写入该路径 - 不要改配置重启——生产环境不现实；改用
mysqldump配合--where导出分区数据，再重定向到本地磁盘 - 若必须用
INTO OUTFILE，可临时软链：ln -s /your/backup/path /var/lib/mysql-files/backup（需确认mysql-files是secure_file_priv所指目录）
按 PARTITION 导出时，mysqldump --where 和 --ignore-table 哪个更稳
mysqldump 本身不支持直接指定分区导出，所谓“按分区导出”，本质是靠条件过滤行数据。用 --where 精准匹配时间字段最可靠；--ignore-table 是整表跳过，对分区表无效——它不识别分区逻辑。
实操建议：
- 确认分区键字段名（比如
create_time），用--where="create_time >= '2023-01-01' AND create_time - 避免用
YEAR(create_time)这类函数——会绕过索引，导出变慢，还可能漏数据 - 导出前先
EXPLAIN PARTITIONS SELECT ...验证是否真的只扫目标分区，防止误触热区
从原表 INSERT INTO ... SELECT 迁移到归档库，为什么锁表时间远超预期
即使目标表是空的，INSERT INTO archive_table SELECT ... FROM hot_table PARTITION (p2023) 在 MySQL 5.7/8.0 中仍可能触发全表扫描或元数据锁等待，尤其当原表有大事务未提交或二级索引多时。
实操建议：
- 别依赖
PARTITION提示——MySQL 优化器未必采纳；改用带时间条件的WHERE，并确保该字段有索引 - 加
LOW_PRIORITY或拆成小批次（比如每次 10 万行 +LIMIT+ 循环），减少单次锁持有时间 - 避开业务高峰；迁移前
KILL掉长事务（SELECT * FROM information_schema.INNODB_TRX查）
归档后删数据，ALTER TABLE ... DROP PARTITION 和 DELETE WHERE 差在哪
DROP PARTITION 是 DDL，瞬间释放空间、不走 undo log、不锁全表；DELETE 是 DML，生成大量 binlog 和回滚段，可能拖慢主从同步，还容易被 kill 成半截状态。
实操建议：
- 只要分区定义清晰（比如按月分），优先用
ALTER TABLE t DROP PARTITION p2022_01 - 执行前确认该分区无跨分区查询依赖（比如某些报表 JOIN 了历史分区）
- 注意：MySQL 8.0+ 支持
TRUNCATE PARTITION，比DROP + REORGANIZE更轻量，但不释放磁盘空间
分区名不是随便起的，INFORMATION_SCHEMA.PARTITIONS 里查清楚再操作；手抖输错一个字母，删错分区没法回滚。
