MySQL启动报InnoDB: Failed to create check sector file, errno:13，根本原因是innodb_data_home_dir路径未以斜杠结尾导致路径解析歧义，非权限问题；应修改my.cnf中该参数为带尾部斜杠的格式（如/data1/mysql/）并重启服务。
MySQL 启动报 InnoDB: Failed to create check sector file, errno:13 怎么办
这不是权限或 SELinux 问题，而是 MySQL 在检测文件系统对 O_DIRECT 支持时，因路径末尾缺少斜杠触发的已知行为。它不阻断启动，但每次都会打印 ERROR 日志，干扰监控和日志归集。
根本原因是：MySQL 5.7+ 在初始化数据目录时，会尝试在 innodb_data_home_dir 指定路径下创建临时校验文件（如 /data1/check_sector_size），若该路径是目录但未以 / 结尾，底层 open() 调用可能因路径解析歧义返回 errno:13 (Permission denied) —— 实际是“路径不规范”而非权限不足。
- 确认当前配置：
SHOW VARIABLES LIKE 'innodb_data_home_dir';，输出类似/data1/mysql（无结尾斜杠） - 修改
my.cnf中的innodb_data_home_dir，强制加尾部/：innodb_data_home_dir = /data1/mysql/ - 重启 mysqld，错误消失；无需删
check_sector_size文件，MySQL 会自动跳过已存在校验文件
O_DIRECT 在 tmpfs 上报 Invalid argument 怎么处理
当 tmpdir=/tmp 且 /tmp 是 tmpfs（内存文件系统）时，InnoDB 对临时表文件（如 /tmp/#sql*.ibd）调用 O_DIRECT 会失败，因为 tmpfs 不支持该 flag。这不是配置错误，而是内核限制。
现象包括：ERROR InnoDB: Failed to set O_DIRECT on file /tmp/#sql*.ibd: CREATE: Invalid argument，严重时导致 mysqld 崩溃（尤其 MySQL 5.5）。
- 最稳妥方案：改
tmpdir到非tmpfs路径，例如tmpdir = /var/tmp或专用磁盘分区 - 若必须用
/tmp，可临时禁用O_DIRECT用于临时表场景，但注意这会加剧双缓存压力——仅建议低负载调试期使用 - 不要尝试 patch 内核或挂载选项绕过，
tmpfs + O_DIRECT组合本身无意义，且 MySQL 官方 Bug #26662 明确标记为 “not a bug”
ext4/xfs 文件系统启用 O_DIRECT 前必须验证什么
O_DIRECT 不是开箱即用的加速开关，它依赖底层文件系统和块设备栈的严格对齐支持。错配会导致性能反降、写入静默失败，甚至数据损坏风险。
关键验证点：
- 检查文件系统特性：
xfs_info /path/to/datadir（XFS）或tune2fs -l /dev/sdX | grep "Filesystem features"（ext4），确认含extent、uninit_bg等现代特性；避免journal=ordered的 ext4 配置，它会强制退化为普通 write - 排查中间层干扰：LVM、mdadm、QEMU
cache=writeback等会拦截并丢弃O_DIRECTflag；用strace -p $(pgrep mysqld) -e trace=open,openat观察实际open()是否带O_DIRECT - 确认 redo log 和数据文件**不在同一挂载点**：若共用
/data，而该挂载启用了 barrier 或 journal，O_DIRECT可能被部分忽略；理想情况是数据文件走O_DIRECT，redo log 走独立挂载点 +O_SYNC
ARM 架构（如鲲鹏920）下 O_DIRECT 报错怎么应对
ARM 平台对 O_DIRECT 的 syscall 实现与 x86 存在差异，尤其在早期 kernel 版本中，O_DIRECT 可能被静默忽略或返回 EINVAL。MySQL 5.7 在鲲鹏上常见启动失败或刷盘异常。
官方推荐替代方案不是硬扛 O_DIRECT，而是切换到更适配 ARM I/O 栈的模式：
- 优先使用
innodb_flush_method = O_DIRECT_NO_FSYNC：它保留直接写入优势，同时跳过冗余 fsync，降低 ARM 下 syscall 开销 - 确认 kernel 版本 ≥ 4.19（鲲鹏推荐 ≥ 5.10），老 kernel 对
O_DIRECT的 page alignment 检查更严，易触发失败 - 若仍报错，回退至
fdatasync并调优innodb_log_buffer_size和innodb_flush_log_at_trx_commit，ARM 平台往往更受益于 log buffer 批量合并，而非绕过 cache
真正起作用的从来不是参数名本身，而是你是否清楚每一行配置在当前硬件栈里实际触发了哪条系统调用路径。
