最准确的方法是执行SHOW VARIABLES LIKE 'log_error';，返回Value字段即绝对路径；若为空则查配置文件或默认路径；读日志时用tail -f、grep筛选关键信息。
直接问MySQL它自己：用SHOW VARIABLES LIKE 'log_error';
这是最准、最快、也最不依赖经验的方法——只要MySQL服务能连上，就立刻知道日志在哪。log_error变量就是它的“户籍登记”，不会骗人。执行后返回的Value字段就是绝对路径，比如/var/log/mysql/error.log或C:\ProgramData\MySQL\MySQL Server 8.0\Data\DESKTOP-ABC.err。
注意：如果返回空值（NULL），说明MySQL没配置该参数，也没写入默认位置，此时要转向配置文件或数据目录排查。
查配置文件里的log-error设置
配置文件是MySQL的“出生证明”，决定了日志的法定住址。Linux常见路径：/etc/my.cnf、/etc/mysql/my.cnf；Windows是安装目录下的my.ini。打开后在[mysqld]段找这一行：log-error = /path/to/your.log。
容易踩的坑：
• 路径写错权限（比如/var/log/mysql/目录不存在，或属主不是mysql用户）会导致MySQL启动失败，但错误日志反而写不出来——形成“死循环”；
• 配置文件可能有多个，优先级顺序是：命令行 > ~/.my.cnf > /etc/my.cnf，别只改了一个却忽略了更高优先级的；
• Docker容器里，my.cnf常被挂载进/etc/mysql/conf.d/，得进容器里ls /etc/mysql/conf.d/确认。
找不到配置？去默认路径和数据目录里翻
当MySQL连不上、配置又没设，就得靠系统常识“盲找”。Linux下优先试：/var/log/mysqld.log（RHEL/CentOS）、/var/log/mysql/error.log（Debian/Ubuntu）、/usr/local/mysql/data/$(hostname).err（源码编译）；Windows则去C:\ProgramData\MySQL\MySQL Server X.X\Data\找以主机名命名的.err文件（注意ProgramData是隐藏目录）。
实用技巧：
• 用sudo find /var -name "*.err" 2>/dev/null | head -5快速扫一遍；
• 查MySQL进程实际加载的参数：ps aux | grep mysqld | grep "log-error"，有时启动脚本里硬编码了路径；
• 如果连datadir都拿不到，先执行SHOW VARIABLES LIKE 'datadir';，再进那个目录找*.err文件。
看到日志后怎么高效读？别从头cat
生产环境的.err文件动辄几百MB，cat会卡死终端。真正有用的永远是最近几条：
• 实时盯住启动过程：sudo tail -f /var/log/mysql/error.log；
• 快速筛出致命问题：sudo grep -i "error\|crash\|fail\|access denied" /var/log/mysql/error.log | tail -15；
• 看InnoDB初始化是否成功（关键判断能否正常启动）：sudo grep -A 5 -B 5 "InnoDB initialization" /var/log/mysql/error.log。
特别提醒：日志里[ERROR]开头的行不一定代表服务挂了，有些是插件加载失败但不影响主流程；而[Warning]里出现Using unique option prefix这类提示，往往意味着配置项拼写错误（如log_error写成log-error），容易被忽略却导致配置不生效。
