先查错误日志定位问题：执行SHOW VARIABLES LIKE 'log_error'获取路径，或查my.cnf中log_error配置；Linux常见路径为/var/log/mysql/error.log或/var/log/mysqld.log，Windows在my.ini指定路径或C:\ProgramData\MySQL\MySQL Server X.X\data\hostname.err；用tail -n 50查看末尾，重点关注[ERROR]行。
MySQL服务无法启动，90%以上是配置文件改错或没被加载——先看错误日志，再验证配置，别急着改回原样。
怎么看MySQL错误日志位置和内容
错误日志是唯一可信的线索，MySQL不会在终端直接告诉你哪行配置错了，但日志里一定有蛛丝马迹。
- Linux常见路径：
/var/log/mysqld.log（RHEL/CentOS）、/var/log/mysql/error.log（Debian/Ubuntu）、/usr/local/mysql/data/主机名.err（源码安装） - Windows下优先查
my.ini里log_error指定的路径，或去C:\ProgramData\MySQL\MySQL Server X.X\data\找*.err文件 - 用
tail -n 50 /path/to/error.log看末尾最新几条，重点关注带[ERROR]或[Warning]的行 - 典型提示举例：
unknown variable 'query_cache_size'（8.0+已移除）、Can't start server: Bind on TCP/IP port: Address already in use（端口被占）、World-writable config file '/etc/my.cnf' is ignored（权限太宽）
为什么改了my.cnf却没生效或报错
MySQL只认第一个存在的配置文件，且对语法、位置、权限极其敏感；你以为改的是它，其实它根本没读。
- 运行
mysqld --verbose --help | grep "Default options"，输出类似Default options are read from following files : /etc/my.cnf /etc/mysql/my.cnf ...——它只加载列表中第一个存在的文件，后面的全忽略 -
[client]段里写datadir、log_error等参数无效，这些只在[mysqld]段起作用 - 参数大小写敏感：MySQL 8.0+要求
innodb_buffer_pool_size = 2G，写成2g或2GB会被静默忽略 - 废弃参数如
query_cache_size、max_connect_errors（8.0.27+移除）会直接导致启动失败，日志报unknown variable
如何快速验证my.cnf语法是否合法
别重启服务试错，用内置校验命令秒级定位问题。
- 确保MySQL版本 ≥ 5.7.20 或 ≥ 8.0.14，执行：
mysqld --defaults-file=/etc/my.cnf --validate-config - 若报错，会直接输出类似
unknown variable 'innodb_log_files_in_group'，说明参数名拼错或已弃用 - 更轻量方式：
mysqld --defaults-file=/etc/my.cnf --verbose --help | head -20，出错时也会立即中断并提示 - 注意：
--validate-config只检查语法和参数存在性，不验证datadir路径是否存在、权限是否正确——这些得靠后续人工确认
配置文件权限不对会导致MySQL直接跳过它
这是最隐蔽也最常被忽略的问题：文件权限过宽，MySQL出于安全考虑主动拒绝加载。
- 错误提示典型为：
World-writable config file '/etc/my.cnf' is ignored - 只要
my.cnf权限含w（如664、644允许，666、777、755均被拒），MySQL就跳过该文件，退回到内置默认值 - 修复命令：
chmod 644 /etc/my.cnf（Linux）或右键属性 → 安全 → 去掉“写入”给“Everyone”的权限（Windows） - 改完权限后仍不生效？再确认一次
mysqld --verbose --help输出的加载路径，避免编辑了错误文件
真正卡住人的，往往不是参数设多大，而是my.cnf压根没被读、读了但被跳过、或者参数放在了错误的段落里——日志和--validate-config是唯二值得信任的判断依据。
