麒麟OS MySQL启动失败时，须先用sudo mysql -e "SHOW VARIABLES LIKE 'log_error'"或grep -r "log-error"定位真实错误日志路径；再通过systemctl status mysqld查退出码（如status=13→权限问题、status=137→OOM）；最后用tail -n 50聚焦日志末尾关键词，结合chown -R mysql:mysql修复数据目录权限，并用mysqld --console前台验证配置。
麒麟OS上MySQL服务启动失败时，必须立刻定位错误日志才能判断是配置写错、权限缺失、端口被占，还是InnoDB数据文件损坏——它不报具体原因，只显示“failed”，但日志里每行[ERROR]都对应一个可修复的动作。
确认MySQL错误日志真实路径
麒麟OS默认不统一日志位置，不能直接去/var/log/mysql/error.log硬找。先用MySQL自身命令查准路径：
执行 sudo mysql -u root -p -e "SHOW VARIABLES LIKE 'log_error';"，若能登录就直接返回Value值；若登录失败，说明服务根本没起来，改用配置文件查找法。
运行 sudo grep -r "log-error" /etc/mysql/ /etc/my.cnf 2>/dev/null，优先看/etc/mysql/mysql.conf.d/mysqld.cnf里的设置。如果没搜到，说明MySQL沿用编译默认路径，此时错误日志极大概率在数据目录下，执行 sudo mysqld --verbose --help | grep "datadir" 得到路径后，进该目录找 【以主机名命名的.err文件，如 kylin-server.err】。
用systemctl status快速抓退出码
这一步比翻日志还快，3秒内锁定问题大类：
运行 sudo systemctl status mysqld --no-pager -l（注意麒麟OS常用服务名是mysqld，不是mysql）。
重点看Active行右侧的“failed”后面括号里的退出码，比如(code=exited, status=1/FAILURE)——status=1表示通用初始化失败，大概率是配置语法错或log_error路径不可写；status=2通常指向my.cnf里有非法参数；status=137基本可断定是OOM Killer干的，得立刻检查innodb_buffer_pool_size是否设得过大。
查看错误日志末尾50行关键报错
找到日志路径后，别从头读，直接盯最后几十行：
执行 sudo tail -n 50 /var/log/mysql/error.log（路径按上一步确认的来）。
逐行扫以下关键词：
• Can't start server: Bind on TCP/IP port: Address already in use → 立刻执行 sudo lsof -i :3306 查谁占着端口；
• InnoDB: Unable to lock ./ibdata1 error: 11 → 说明有残留mysqld进程没杀干净，运行 sudo ps aux | grep mysqld 找PID后 sudo kill -9 PID；
• Operating system error number 13 in a call to fcntl() → 文件权限出问题，常见于迁移数据目录后忘了改属主，下一步要修复；
• Unknown suffix 'G' used for variable 'innodb_buffer_pool_size' → 麒麟OS预装的MySQL 5.7不认“2G”这种写法，必须改成“2048M”或“2147483648”。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
验证并修复数据目录权限
麒麟OS对SELinux兼容性弱，但更常踩的是传统Linux权限坑：
第一步：确认数据目录实际路径，执行 sudo grep "datadir" /etc/mysql/mysql.conf.d/mysqld.cnf；
第二步：检查该路径属主是否为mysql用户，运行 ls -ld /var/lib/mysql，若显示root:root或mysql:root，就必须改；
第三步：执行 sudo chown -R mysql:mysql /var/lib/mysql 和 sudo chmod -R 755 /var/lib/mysql；
第四步：连带检查log_error指向的日志目录，比如是/var/log/mysql，则同样执行 sudo chown mysql:mysql /var/log/mysql；
【切勿对整个/var/log递归chmod，只动MySQL专用子目录】。
手动前台启动验证配置有效性
绕过systemd，让错误直接打到终端，避免日志重定向掩盖关键信息：
方法一（推荐）：用mysql用户身份运行 sudo -u mysql mysqld --defaults-file=/etc/mysql/mysql.conf.d/mysqld.cnf --console；
方法二（精简）：若怀疑是配置文件本身语法错，先做静态校验 sudo mysqld --defaults-file=/etc/mysql/mysql.conf.d/mysqld.cnf --validate-config，返回“Syntax OK”才继续；
提示：如果前台启动后卡在mysqld: ready for connections就说明服务其实能跑，问题出在systemd单元文件里——此时应运行 sudo systemctl daemon-reload 再试启动。
