MySQL启动失败时，error log默认在数据目录下（如/var/lib/mysql/hostname.err），Docker用docker logs，Windows在C:\ProgramData\MySQL\MySQL Server X.X\Data*.err；关键错误包括端口占用、文件锁、配置语法错、权限不足等。
mysql服务启动失败时，error log在哪找
MySQL 启动失败，第一反应不是重装或瞎猜，而是看 error.log —— 它才是真实原因的唯一信源。但很多人卡在“根本找不到日志在哪”。
- 默认位置取决于安装方式：
mysqld --verbose --help | grep "datadir"能看到数据目录，error log 通常就在那附近（如/var/lib/mysql/hostname.err或/usr/local/mysql/data/*.err） - 如果启用了
log_error配置项，就以它为准：grep "log_error" /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null - Docker 启动的 MySQL，别翻宿主机文件系统，用
docker logs；容器内日志路径常被映射到/var/log/mysql/error.log，但实际输出优先走 stdout - Windows 下常见于
C:\ProgramData\MySQL\MySQL Server X.X\Data\*.err（注意ProgramData是隐藏目录）
error log 里哪些错误信息最值得立刻关注
别从头扫到尾。90% 的启动失败集中在几类错误，盯住它们就能快速定位：
-
Can't start server: Bind on TCP/IP port: Address already in use→ 端口被占，lsof -i :3306或netstat -tuln | grep :3306查进程 -
InnoDB: Unable to lock ./ibdata1 error: 11→ 文件被其他 mysqld 实例锁住，或上次崩溃没清理干净，检查是否有残留进程ps aux | grep mysqld -
Unknown suffix 'G' used for variable 'innodb_buffer_pool_size'→ 配置项写错，MySQL 5.7 不支持1G这种写法，得写成1073741824或1024M -
Failed to open log file '/var/log/mysql/error.log' (Errcode: 13 - Permission denied)→ mysqld 用户（通常是mysql）没权限写日志路径，chown mysql:mysql /var/log/mysql+chmod 755 /var/log/mysql
my.cnf 配置错误导致 silent 启动失败
MySQL 启动时遇到非法配置，有时不报错、不写日志、直接退出——尤其当 log_error 本身写错路径时，连错误都记不了。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
mysqld --defaults-file=/etc/my.cnf --validate-config做静态校验（5.7.16+ 支持），能提前发现语法错误和无效参数 -
skip-grant-tables和skip-networking在某些版本组合下会冲突，导致初始化失败，临时注释掉再试 - 配置了
innodb_log_group_home_dir但路径不存在或权限不对，InnoDB 初始化阶段就跪，error log 可能只留半行InnoDB: Initializing buffer pool就断了 - 使用
!include或!includedir时，子配置文件里有语法错误，主配置不会提示，得手动mysqld --print-defaults看最终生效值是否异常
systemd 环境下 mysql 启动失败的特殊排查点
Linux 发行版用 systemd 管理 mysqld 后，service mysql start 看似成功，其实可能只是“提交了启动请求”，真正失败藏在 unit 日志里。
- 别只信
systemctl status mysql的绿色 active，要看systemctl status mysql -l（带-l才显示最近 10 行日志） - 更准的是
journalctl -u mysql --since "2 minutes ago"，它包含 mysqld 自身 stdout/stderr 和 systemd 拦截的启动过程信息 - 常见陷阱：
ProtectHome=true或PrivateTmp=true在 unit 文件中启用后，会导致 mysqld 访问/home下的数据目录或临时 socket 失败，error log 可能完全不生成 - 若修改过
my.cnf，记得systemctl daemon-reload，否则 systemd 仍按旧环境变量和配置启动
真正麻烦的不是报错，是没报错——比如配置文件里某行末尾多了个不可见的 Unicode 字符，或者 SELinux 策略拦住了 mysqld 访问 data 目录，这些都不会在 error log 里明说，得结合 ausearch -m avc -ts recent 或 setenforce 0 临时验证。
