mysql 8.0+ 默认启用独立表空间，ibdata1仅存元数据；可通过select @@innodb_file_per_table确认状态，为1即生效；大表迁移用alter table ... engine=innodb即可。
MySQL 8.0+ 默认表空间在哪？ibdata1 还管用吗？
MySQL 8.0 开始，innodb_file_per_table 默认为 ON，意味着每张 InnoDB 表默认生成独立的 .ibd 文件，不再统一写入系统表空间 ibdata1。所以安装完不手动干预的话，ibdata1 仅存数据字典、undo log 和 change buffer 等元信息，体积很小（通常几十 MB），基本不用再担心它无限膨胀。
但要注意：如果初始化时用了 --initialize-insecure 或跳过配置文件，MySQL 可能沿用旧行为；可通过查询确认：
SELECT @@innodb_file_per_table;
返回 1 才是预期状态。若为 0，需在 my.cnf 中显式设置并重启：
innodb_file_per_table = ON
想把大表迁到单独表空间？用 ALTER TABLE ... ENGINE=InnoDB 就行
对已存在且当前在共享表空间（ibdata1）里的表，只需执行一次 DDL 即可将其“导出”到独立 .ibd 文件：
ALTER TABLE my_large_table ENGINE=InnoDB;
这个操作会重建表，并按当前 innodb_file_per_table 设置决定存放位置。执行前注意：
- 确保磁盘剩余空间 ≥ 当前表大小的 2 倍（临时表 + 原表保留）
- 该语句会锁表（MySQL 5.6+ 对多数 DDL 支持 ALGORITHM=INPLACE，但非全部；8.0+ 的
ALGORITHM=INSTANT仅限加列等极简操作） - 执行后原
ibdata1不会自动收缩——InnoDB 不回收共享表空间已分配的空间，只能导出全量再重建实例
innodb_data_file_path 和 innodb_undo_directory 别乱动
这两个参数控制系统表空间和 undo 日志物理路径，属于“改了容易翻车”的类型：
-
innodb_data_file_path = ibdata1:12M:autoextend：只应在初始化前设置；运行中修改会直接启动失败 -
innodb_undo_directory：MySQL 8.0.14+ 已废弃，undo 表空间默认在mysql数据目录下以undo_001、undo_002形式管理；手动指定路径需配合innodb_undo_tablespaces，且必须在初始化时完成 - 常见误操作：看到
ibdata1没增长就以为“没在用”，其实 undo/redo 仍可能占大量 I/O；用SHOW ENGINE INNODB STATUS\G查看LOG和UNDO LOG部分更靠谱
SSD 上要不要关 innodb_flush_neighbors？
这个参数影响刷脏页时是否连带刷相邻页，在 HDD 时代能减少寻道，但在 SSD 上反而增加无效 I/O。MySQL 5.6+ 默认根据存储类型自动判断，但安装后未探测或使用虚拟盘时可能误判：
SELECT @@innodb_flush_neighbors;
如果是 1（启用），而你确实在 SSD 上跑，建议显式关闭：
SET GLOBAL innodb_flush_neighbors = 0;
并写入配置文件持久化。不过要注意：该值只对 innodb_buffer_pool_pages_dirty 较高时生效，日常负载低时影响几乎不可测。
真正影响存储效率的，往往是慢查询导致的频繁回表、缺失索引引发的全表扫描，以及没设 innodb_io_capacity 导致刷新节奏跟不上 SSD 吞吐——这些比纠结单个参数更值得优先排查。
