应优先使用 docker logs -t --tail=all 获取完整日志，因mysql崩溃过快导致标准输出截断；若仍无有效错误，需进容器查实际 log_error 配置路径并检查对应文件。
docker logs 看不到有效错误信息怎么办
很多情况下 docker logs <container_name></container_name> 只显示几行启动日志就中断，或者反复刷出“Starting...”后直接退出，根本看不到具体报错。这不是日志没输出，而是 MySQL 进程崩溃太快，标准输出被截断或缓冲未刷新。
这时候必须加 -t（显示时间戳）和 --tail=all 强制拉取全部历史输出：
docker logs -t --tail=all mysql-container
如果容器刚崩溃完还没被 Docker 清理掉状态，这条命令大概率能捞到最后一段关键错误——比如 [ERROR] Found 1 prepared transactions! 这类致命恢复失败提示。
- 不要只依赖
docker logs -f：它只追新日志，旧崩溃记录已丢失 - 若返回空或只有启动头几行，说明容器根本没完成初始化就挂了，需立刻进容器查配置和文件系统
- MySQL 8.0+ 默认关闭
log_error_verbosity，部分错误不打到 stdout，必须查文件日志
进容器后找不到 /var/log/mysql/error.log
Debian/Ubuntu 系统镜像（如官方 mysql:8.0）默认把错误日志写在 /var/log/mysql/error.log；但 Alpine 或某些定制镜像可能压根不启用该路径，甚至删掉了 rsyslog。更可靠的方式是查 MySQL 实际加载的配置：
docker exec -it mysql-container mysql --help | grep "log-error"
或直接读配置文件：
docker exec -it mysql-container cat /etc/mysql/my.cnf 2>/dev/null || cat /etc/my.cnf 2>/dev/null
重点找 log_error 参数值。常见 fallback 路径包括：
-
/var/lib/mysql/$(hostname).err（CentOS/RHEL 风格，尤其 MariaDB 容器） -
/dev/stderr（某些精简镜像直接重定向到标准错误，此时docker logs就是唯一来源） - 完全未配置时，MySQL 会退回到
/var/lib/mysql/mysqld.err
容器反复 restarting 且日志显示事务恢复失败
典型错误：[ERROR] Found 1 prepared transactions! ... start mysqld with --tc-heuristic-recover。这说明上一次非正常终止（如 docker kill、宿主机宕机），导致 InnoDB 的事务协调日志（tc.log）损坏或丢失。
容器里不能直接加启动参数，必须改配置文件：
- 先确认配置文件位置：
docker exec mysql-container find /etc -name "*.cnf" 2>/dev/null - 拷贝出来修改：
docker cp mysql-container:/etc/mysql/conf.d/docker.cnf ./ - 在
[mysqld]段落下新增一行：tc-heuristic-recover=rollback（或commit，取决于业务容忍度） - 拷回并重启：
docker cp ./docker.cnf mysql-container:/etc/mysql/conf.d/→docker restart mysql-container
注意：tc-heuristic-recover 是一次性修复开关，成功启动后建议删掉，避免后续误用。
挂载了数据卷却仍看不到日志文件
如果你挂载了 -v mysql-data:/var/lib/mysql，但发现 /var/log/mysql 下空空如也，别慌——日志目录和数据目录是两回事。MySQL 默认不把错误日志写进 /var/lib/mysql，除非你显式配置了 log_error = /var/lib/mysql/error.log。
真正影响日志可见性的，是 /var/log/mysql 是否也被挂载。没挂载时，它只是容器内的临时文件系统（tmpfs 或 overlay），容器删除即消失。
- 临时查看：用
docker exec进去后立即ls -l /var/log/mysql，看是否为 root:root 权限（未挂载）还是 mysql:mysql（挂载后被 MySQL 初始化过） - 长期方案：启动时加
-v ./mysql-logs:/var/log/mysql，确保日志落盘可追溯 - 最省事办法：放弃文件日志，全程靠
docker logs -t --since="2h"定向排查最近两小时异常
真正容易被忽略的是：MySQL 容器崩溃时，InnoDB 崩溃恢复过程本身不记入 error.log，只在 stdout 输出。所以哪怕你挂载了日志目录，第一条线索永远是 docker logs ——别跳过它，哪怕要加 --tail=all 和 -t。
