表空间写入失败主因是操作系统权限或安全模块限制，而非mysql权限配置；需检查ibdata1等文件属主、selinux/apparmor策略及innodb_data_file_path大小匹配性。
表空间权限不足导致写入失败，95% 以上不是 MySQL 权限配置问题，而是操作系统层面对 ibdata1、ibtmp1 或 datadir 目录的写权限缺失，或 SELinux/文件系统挂载限制所致。
为什么 mysqld 启动时提示 “Permission denied” 却查不到用户权限问题？
MySQL 进程（通常以 mysql 用户身份运行）需要对数据目录下所有关键文件有读写权限，包括：ibdata1（系统表空间）、ibtmp1（临时表空间）、ib_logfile*（重做日志）。即使 mysql.user 表里权限全开，若 chown 或 chmod 没设对，启动或写入时仍会报 OS error 13。
- 常见现象：
mysqld: File './ibdata1' not found (OS errno 13 - permission denied)或启动日志中反复出现Can't create test file - 检查命令：用
ls -l /var/lib/mysql/ibdata1看属主是否为mysql:mysql；用stat /var/lib/mysql看父目录是否可写、是否被挂载为noexec或ro - 特别注意：Docker 容器内若挂载宿主机路径，必须确保该路径对容器内
mysqlUID（通常是 999 或 27）可写，不能只看宿主机上的ls -l显示
SELinux 或 AppArmor 阻止 ibtmp1 动态增长怎么办？
在 CentOS/RHEL/Fedora 上，SELinux 默认禁止 mysqld 对非标准路径（如自定义 innodb_tmpdir）或大块临时文件进行写操作；Ubuntu/Debian 则可能触发 AppArmor 规则拦截。这不是 MySQL 配置能绕过的。
- 快速验证：临时禁用 SELinux 测试——
setenforce 0，再试INSERT；若恢复则确认是策略问题 - 永久修复（不推荐关 SELinux）：
semanage fcontext -a -t mysqld_db_t "/path/to/custom/tmpdir(/.*)?"，然后restorecon -Rv /path/to/custom/tmpdir - AppArmor 方案：编辑
/etc/apparmor.d/usr.sbin.mysqld，在/var/lib/mysql/** rwk,下追加类似行：/mnt/bigdisk/mysql-tmp/** rwk,，再执行sudo systemctl reload apparmor
innodb_data_file_path 配置与磁盘文件大小不一致引发写入卡死
MySQL 8.0+ 在启动时会对 innodb_data_file_path 中每个文件做严格校验：声明大小（单位 MB）必须等于磁盘文件字节数向下取整到 MB。一旦不匹配，InnoDB 拒绝加载，所有写入操作立即失败，错误如 MY-012264。
- 典型诱因：运维曾用
dd扩容ibdata1，但没同步更新my.cnf；或升级后默认配置覆盖原配置，变成ibdata1:12M:autoextend，而实际文件已是几十 GB - 安全修复步骤：
– 查真实大小：ls -l ibdata1 | awk '{printf "%.0f\n", $5/1024/1024}'
– 编辑my.cnf，显式写出大小（仅最后一个允许:autoextend）：innodb_data_file_path = ibdata1:10240M;ibdata2:2048M:autoextend
–mysql -e "SHUTDOWN;"停库，勿kill -9；再启动 - 注意：
ibdata1不支持在线收缩，扩容后无法回退；长期建议改用独立表空间（innodb_file_per_table=ON）并避免直接操作系统表空间文件
真正棘手的是混合问题：比如磁盘空间充足、用户权限正确，但 ibtmp1 因 SELinux 限制无法扩展，同时 innodb_data_file_path 校验又失败——这两类错误日志常混在一堆 warning 里，容易漏掉关键行。排查时务必逐行扫 error log，盯住第一个 ERROR 级别条目，而不是最后那个 Table is read only。
