高并发写入下，共享表空间会放大锁和IO竞争，因其将所有表数据、索引、undo及系统元数据集中于ibdata1等文件，导致页分裂、回滚段分配等操作争抢同一物理区域，引发行锁等待上升、缓冲池等待频发及磁盘队列飙升；而独立表空间通过每表独占.ibd文件实现细粒度IO调度与缓存管理，在SSD环境下并行吞吐更高，实测P99响应时间下降42%，fsync次数减少约1/3。
高并发写入下，共享表空间会放大锁和IO竞争
共享表空间把所有表的数据、索引、undo、系统元数据全塞进 ibdata1（或多个 ibdata* 文件），物理上无法隔离。一旦多张大表同时做大量 INSERT/UPDATE，页分裂、回滚段分配、缓冲池刷脏都会争抢同一块文件区域，表现为 innodb_row_lock_waits 上升、innodb_buffer_pool_wait_free 频发、磁盘队列深度飙高。
独立表空间让每张表独占一个 .ibd 文件，内核可对单个文件做更细粒度的 IO 调度和缓存管理。尤其在 SSD 环境下，多文件并行读写吞吐明显更高。实测某日志写入服务从共享切为独立后，P99 响应时间下降 42%，innodb_data_fsyncs 次数减少约 1/3。
关键点：
- 共享表空间的「文件级锁」在高并发下是隐性瓶颈，监控里看不到，但压测时一定暴露
- 不要指望用 innodb_data_file_path 拆成多个 ibdata 就能缓解——它们仍是逻辑共享的，undo 和系统段仍混在一起
- innodb_file_per_table = 1 必须在建库前或建表前启用；已存在的表不会自动迁移，需 ALTER TABLE t ENGINE=InnoDB 触发重建
大数据量场景下，共享表空间几乎无法回收空间
共享表空间最致命的问题是：删掉 90% 的数据，ibdata1 文件体积纹丝不动。这是因为 InnoDB 的空间分配是「只增不减」的，删除产生的空页只会被内部复用，不会返还给操作系统。你看到磁盘报警、备份变慢、冷备拷 200G ibdata1 却只含 30G 有效数据，根源都在这儿。
独立表空间则完全不同：
- DROP TABLE 后，对应 .ibd 文件立即被 OS 删除
- 大量 DELETE 后，可用 ALTER TABLE t ENGINE=InnoDB 重建表来收缩文件（MySQL 5.6+ 支持 online DDL，业务影响可控）
- MySQL 8.0+ 还支持 TRUNCATE TABLE 直接释放空间，无需重建
注意：
- OPTIMIZE TABLE 对共享表空间完全无效
- 即使启用了 innodb_file_per_table，undo log 和系统表仍走共享空间，所以 ibdata1 不会归零，但体积会稳定在几十 MB 级别（仅存系统元数据）
哪些情况真该考虑共享表空间？
现实里只有三类场景还值得保留共享表空间：
- 数据库里有上千张小表（每张 .ibd 文件爆炸式增长带来文件系统压力（如 ext3 下 inode 耗尽）
- 嵌入式设备或测试环境，追求极简部署，连 mysqld 都跑在容器里只存配置和 session 数据
- 磁盘是老旧机械盘 + 极低 QPS（
只要涉及日志、订单、用户行为等典型业务表，哪怕单表才几百万行，也请默认选独立表空间。所谓「共享更省空间」是早期机械盘时代的错觉——现代 SSD + LVM/ZFS 下，文件数量早已不是瓶颈，而空间失控才是运维噩梦。
切换到独立表空间必须做的几件事
不是改个配置就完事。生产环境切换需同步处理：
- 在 my.cnf 中确认 innodb_file_per_table = 1，并重启 mysqld（5.6+ 可动态生效，但建议重启确保一致）
- 检查现有大表是否已使用独立空间：SELECT table_schema, table_name, engine, row_format FROM information_schema.tables WHERE engine = 'InnoDB' AND data_length > 1024*1024*100;
- 对未迁移的表执行 ALTER TABLE db.t ENGINE=InnoDB（避开业务高峰，观察 slow log 和 buffer pool miss rate）
- 清理历史 ibdata1：无法直接 shrink，但可导出数据 → 初始化新实例 → 导入，这是唯一彻底方案（适合计划内停机窗口）
最容易被忽略的是 undo 表空间。MySQL 5.7+ 默认仍把 undo 放在 ibdata1 里。若要彻底解耦，需额外配置：innodb_undo_directory + innodb_undo_tablespaces，否则即使启用了独立表空间，大事务回滚段膨胀照样撑爆 ibdata1。
