mysql 8.0 不支持单实例多 datadir，仅能通过 innodb_file_per_table=on + data directory 手动指定每张表物理路径实现跨盘分布；innodb_data_file_path 仅串联扩展系统表空间，无法负载均衡。
MySQL 8.0 无法通过配置多个 datadir 实现跨磁盘 IO 分担——这是根本行不通的路径，强行尝试会导致启动失败，错误类似 Failed to open log (error 2) 或 Can't find file: './mysql/db.frm'。
为什么 datadir 只能有一个
MySQL 启动时只解析一个 datadir 参数，它是整个实例的根目录：系统库（mysql、information_schema）、默认表空间、redo log、binlog 索引等全部强制落在此路径下。即使你写多个 datadir，mysqld 会直接拒绝启动。
innodb_data_home_dir 和 innodb_log_group_home_dir 不是替代方案：它们只是子路径偏移量，且必须位于 datadir 内部或同级目录；InnoDB 不会把用户表数据写到那里，仅影响已弃用的共享表空间 ibdata1 的位置。
操作系统层面的 I/O 调度（如 CFQ、deadline）和存储层（RAID、NVMe 多队列）才是真正的负载均衡主力，MySQL 层面没有“自动轮询写入多盘”的机制。
真正可用的跨磁盘 IO 分担方式：按表/分区指定 DATA DIRECTORY
前提是启用独立表空间：innodb_file_per_table = ON（MySQL 8.0 默认开启）。此时每张表对应一个 .ibd 文件，可显式控制其物理位置。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 新建库时指定路径：
CREATE DATABASE orders DATA DIRECTORY = '/ssd/mysql/orders';，后续在此库中创建的表默认落到该目录 - 建表时直接指定分区路径：
CREATE TABLE logs (...) PARTITION BY RANGE (YEAR(ts)) (PARTITION p2023 DATA DIRECTORY = '/hdd/logs_2023', ...); - 迁移已有表（MySQL 8.0.23+ 支持）：
ALTER TABLE t1 TABLESPACE = innodb_file_per_table DATA DIRECTORY = '/ssd/t1_new';，需确保目标路径存在且 MySQL 用户有读写权限
注意：DATA DIRECTORY 必须是绝对路径，不能是符号链接；MySQL 不会自动创建父目录，需提前 mkdir -p /ssd/t1_new 并 chown mysql:mysql /ssd/t1_new。
权限与路径限制最容易被忽略
Linux 下常见错误：ERROR 3045 (HY000): Tablespace directory not found 或 Can't create/write to file，本质不是路径不存在，而是 MySQL 进程用户（通常是 mysql）缺乏对目标目录的完整权限（rwx）。
Windows 和 Linux 行为差异大，但共性约束一致：MySQL 不检查挂载点是否为同一文件系统，但要求目标路径可访问、可写、非 NFS（除非明确启用 innodb_flush_method=O_DIRECT 且 NFS 服务端支持）、非加密卷（如某些 LUKS 配置可能阻断文件句柄传递）。
路径不能包含 MySQL 特殊字符（如空格、中文、括号），也不能嵌套在 datadir 内部——否则会被视为非法重定向，启动时报错。
实际部署时，最常卡在权限和路径合法性上，而不是语法本身；一旦路径不可写或用户无权访问，DATA DIRECTORY 就会静默失效或报错退出，不会回退到默认位置。
