AppArmor拒绝访问/var/lib/mysql时典型日志为apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/var/lib/mysql/ibdata1"，表明是AppArmor策略拦截而非配置或权限问题。
AppArmor拒绝访问/var/lib/mysql时的典型报错
系统日志里会出现类似这样的关键行：audit: type=1400 audit(1727875620.123:456): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/var/lib/mysql/ibdata1" pid=12345 comm="mysqld" requested_mask="rw" denied_mask="rw"。注意三个要素：profile 名是 /usr/sbin/mysqld，operation 是 open，name 是 MySQL 数据文件路径。只要看到 apparmor="DENIED" + profile="/usr/sbin/mysqld"，基本就能锁定是 AppArmor 拦截，不是配置或权限本身的问题。
确认 AppArmor 是否启用并加载了 MySQL profile
先验证 AppArmor 确实开着，且规则已加载：
- 运行
aa-status，检查输出中是否包含/usr/sbin/mysqld（Ubuntu/Debian 默认自带该 profile） - 若没看到，说明 profile 未加载；若看到但状态是
enforce，则当前是强制模式，拦截生效 - 检查 profile 文件是否存在：
ls -l /etc/apparmor.d/usr.sbin.mysqld。缺失就需手动安装或恢复（如 Ubuntu 上重装apparmor-profiles包）
临时禁用 profile 快速验证是否为根因
不建议直接关整个 AppArmor，而是只卸载 MySQL 的 profile：
- 执行
sudo aa-disable /usr/sbin/mysqld - 再试启动：
sudo systemctl start mysql - 如果成功，100%确认是 profile 规则问题；失败则回归其他排查路径（端口、权限、磁盘等）
- 验证完记得恢复：
sudo aa-enforce /usr/sbin/mysqld，避免留空窗风险
修复 profile 而非绕过：补充缺失路径或权限
常见原因不是 profile 本身损坏，而是 MySQL 配置里用了非标准路径（比如自定义 datadir 或 socket），而 profile 里没放行。修复方式是编辑 profile 并重载：
- 用
sudo vim /etc/apparmor.d/usr.sbin.mysqld打开 - 在
/var/lib/mysql/** rwk,这类规则下方，添加你实际用到的路径，例如：/mnt/data/mysql/** rwk,或/run/mysqld/mysqld.sock w, - 保存后执行：
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld - 再启动服务。注意：修改后必须
apparmor_parser -r，systemctl reload apparmor在多数发行版上无效
AppArmor 的坑在于它不报错到 MySQL 日志里，也不写进 journalctl -u mysql 的主输出——它只打到内核审计日志（dmesg 或 journalctl -k | grep apparmor）。漏看这一层，就会把“权限拒绝”误判成“目录属主不对”，白改半天 chown。
