mysql单表不能直接修改.ibd文件路径，必须通过停库后创建软链接或重建表实现迁移；禁用data directory语法，推荐软链方案并确保权限与文件系统一致。
MySQL单表不能直接修改.ibd文件路径
InnoDB 表的物理存储路径（即 .ibd 文件位置）由 MySQL 服务在创建表时自动确定，**不支持运行时用 ALTER TABLE ... MOVE TO 或类似语句直接迁移 .ibd 文件位置**。这是底层设计限制，不是权限或配置问题。强行移动文件、改名或软链会导致启动失败或崩溃，因为 ibdata1 或数据字典中仍记录着原始路径和空间 ID（space_id），校验不通过会拒绝加载该表。
真正可行的扩容路径：用 innodb_file_per_table=ON + 表重建
前提是该表已启用独立表空间（绝大多数现代 MySQL 实例默认开启）。确认方式：
SELECT TABLE_NAME, ENGINE, CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';
若返回中 CREATE_OPTIONS 包含 row_format=Dynamic 且无 TABLESPACE 指定，则大概率是独立表空间。接着按以下步骤操作：
- 停写该表（或业务低峰期），确保无长事务、无 DML 操作
- 用
ALTER TABLE your_table ENGINE=InnoDB触发重建 —— 此操作会生成新的.ibd文件，但仍在原datadir下 - 若目标是迁移到另一块磁盘（如从 HDD 换到 SSD），需先修改 MySQL 的
datadir（见下一条），或使用符号链接（仅限 Linux，且必须在 mysqld 停止后操作）
把整个表目录软链到大容量磁盘（Linux 下实操最稳）
这是生产中最常用、风险最低的“单表扩容”变通方案。核心思路：不动 MySQL 配置，只让特定表的 .ibd 和 .frm（或 .sdi）实际落在另一块盘上。
- 停止 MySQL：
sudo systemctl stop mysql - 找到原表文件（假设库为
mydb，表为biglog）：/var/lib/mysql/mydb/biglog.{ibd,frm,sdi} - 将这些文件整体移到新路径，例如：
mv /var/lib/mysql/mydb/biglog.* /mnt/fastdisk/mydb/ - 在原位置创建软链接：
ln -s /mnt/fastdisk/mydb/biglog.ibd /var/lib/mysql/mydb/biglog.ibd（同理处理.frm或.sdi） - 确保
mysql用户对新路径有读写权限：chown -R mysql:mysql /mnt/fastdisk/mydb - 启动 MySQL：
sudo systemctl start mysql
注意：innodb_file_per_table 必须为 ON；软链目标不能跨文件系统类型（如 ext4 → xfs 可能出问题）；MySQL 8.0+ 使用数据字典，.frm 已废弃，主要链接 .ibd 和 .sdi 即可。
误用 DATA DIRECTORY 的典型错误
有人尝试在建表时用 DATA DIRECTORY='/mnt/bigdisk' 指定路径，但该功能在 MySQL 5.7+ 默认禁用，且需同时满足：
innodb_file_per_table=ON-
innodb_directories配置项显式包含该路径（MySQL 8.0.22+） - MySQL 用户对该路径有完整权限（非仅 root）
- 路径必须是绝对路径，且不能是
datadir子目录
即便全满足，该语法也**仅在 CREATE TABLE 时生效，无法用于已有表**；且 MySQL 8.0.30+ 已标记为 deprecated，未来可能移除。线上环境不建议依赖。
真正要扩容单表，别想着“改路径”，重点放在：是否允许停写、能否接受重建耗时、新磁盘是否已挂载并授权。路径软链是最小改动、最高成功率的解法，但务必在停库后操作，且验证 SELECT COUNT(*) 和索引查询是否正常。
