90%的“无权限”错误源于mysqld进程未以mysql用户身份运行或datadir属主/selinux上下文不匹配；加sudo仅提升命令执行权，不改变后续服务进程uid，须用sudo -u mysql mysqld --initialize并确保配置文件权限为644且属主root:root。
直接结论：90%的“无权限”不是Linux的chmod或Windows的右键属性没点对，而是mysqld进程根本没以mysql用户身份运行，或者datadir目录属主/上下文不匹配。
为什么加了sudo还是报Can't create/write to file
加sudo只是让你能执行命令，不代表mysqld进程就以mysql用户身份操作文件。初始化时若用sudo mysqld --initialize，生成的ibdata1、mysql/等文件属主是root:root；但后续systemd或Windows服务默认以mysql用户启动，它读不到root写的文件，就会静默失败。
- 必须显式指定运行用户：
sudo -u mysql mysqld --initialize --datadir=/var/lib/mysql --user=mysql - 执行前确保目录已存在且属主正确：
sudo chown -R mysql:mysql /var/lib/mysql - 别信“我用了sudo就等于有权限”——关键看进程实际UID，不是你当前终端的UID
Windows下“没反应”其实是权限被拦在系统层
Windows版mysqld.exe启动后秒退、黑窗一闪、datadir目录空空如也，大概率不是MySQL报错，而是被系统级策略掐断：
- 检查
my.ini中datadir路径是否含中文或空格（如C:\Program Files\MySQL\Data），必须改用纯英文路径，例如D:/mysql/data - 右键
datadir目录 → 属性 → 安全 → 编辑 → 添加SYSTEM和Administrators，勾选“完全控制”，去掉“只读”属性 - 杀毒软件或Windows Defender常静默拦截
mysqld.exe，临时禁用测试；若恢复后正常，需将mysqld.exe加入白名单 - 确认
my.ini编码是ANSI（非UTF-8 with BOM），否则Windows版mysqld读取配置失败，进程立即退出
SELinux或systemd ProtectHome导致Operation not permitted
Linux上看不到具体路径报错，journal里只有Operation not permitted，基本可锁定是安全模块干预：
- 临时关闭SELinux验证：
sudo setenforce 0，再跑一次初始化；若成功，说明是SELinux上下文问题，用sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"修复 - 检查systemd服务是否启用了
ProtectHome=yes：systemctl cat mysqld | grep ProtectHome；该选项会误伤/var/lib/mysql，临时覆盖为ProtectHome=false仅用于调试 - 更稳妥的做法是显式放行：
sudo systemctl edit mysqld，写入ReadWritePaths=/var/lib/mysql
最容易被忽略的“权限”其实是配置文件本身
MySQL启动前会校验/etc/my.cnf或/etc/mysql/my.cnf的权限，哪怕其他所有条件都满足，只要这个文件权限不对，mysqld就会拒绝启动：
- 配置文件必须是
644权限：sudo chmod 644 /etc/my.cnf - 归属必须是
root:root：sudo chown root:root /etc/my.cnf - 如果用了
!includedir /etc/mysql/conf.d/，整个目录及其中所有*.cnf文件都得满足同样权限要求 - Windows下同理：
my.ini不能设为只读属性，也不能由普通用户拥有（需Administrators可修改）
真正卡住的点，往往不在你反复检查的chown命令上，而在systemd单元的ProtectHome、Windows的BOM编码、或配置文件权限这些“看不见的权限链”里。动手前先确认进程UID和配置文件权限，比盲目清空datadir有用得多。
