死锁日志仅记录在错误日志中，需开启innodb_print_all_deadlocks=on才生效；未开启则历史死锁不可查，开启后可通过awk等命令提取带时间戳的死锁块，sql无法直接解析非结构化日志。
死锁日志不在常规查询表里，得先确认是否开启了死锁记录功能
MySQL 默认不会把死锁信息写入任何可 SQL 查询的表中，INFORMATION_SCHEMA 或 performance_schema 里都没有现成的死锁历史表。真正记录死锁的是错误日志（error_log），而且前提是配置了 innodb_print_all_deadlocks = ON。没开这个选项，过去发生的死锁根本没被记录，查也白查。
检查方法：SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';
返回 ON 才有戏；如果是 OFF，现在改也没用——过去没记的，永远找不回来。
- 该变量是动态可设的，但只影响后续发生的死锁，不影响历史
- 日志路径由
log_error变量决定，常见位置如/var/log/mysql/error.log或/usr/local/mysql/data/hostname.err - 开启后，每次死锁会在错误日志里生成一段以
*** (1) TRANSACTION:开头、含事务ID、SQL、等待/持有锁等细节的块状日志
从错误日志中提取过去24小时的死锁块，用命令行最直接
死锁日志是纯文本，没有结构化时间戳字段，但每段开头都有类似 2024-05-20T14:23:18.123456Z 的 ISO 时间戳（取决于 log_timestamps 设置）。靠 MySQL 自身 SQL 无法高效解析这种非结构化日志，必须借助 shell 工具。
假设日志路径是 /var/log/mysql/error.log，且服务器时区为 UTC：
awk -v cutoff=$(date -d '24 hours ago' '+%Y-%m-%dT%H:%M:%S') '
/^\[.*\] \[Warning\] InnoDB:.*deadlock/ { in_deadlock=1; block="" }
in_deadlock { block = block $0 "\n" }
/^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}/ && !/deadlock/ {
if (in_deadlock && $1 >= cutoff) print block
in_deadlock = 0
}' /var/log/mysql/error.log | grep -A 20 -B 5 '*** (1) TRANSACTION'
- 这段
awk会匹配以时间戳开头的新日志行，作为上一个死锁块的结束标记 -
grep -A 20 -B 5是为了把关键上下文（事务、SQL、锁信息）一并捞出来，方便定位 - 注意：如果
log_timestamps = SYSTEM，时间格式可能是本地时区，需同步调整date命令的时区参数 - 日志滚动后（比如
error.log.1.gz），得先解压再查：zcat /var/log/mysql/error.log.1.gz | ...
想用 SQL 查？只能靠外部导入 + 临时表，但成本高、不推荐日常用
真要走 SQL 路线，得先把日志按块切分、提取时间戳和内容，存进一张临时表，再用 WHERE 过滤。但这个过程涉及文本解析、正则提取、时区转换，容易出错，且每次查都要重导一遍。
示例建表与导入思路（仅示意）：
CREATE TEMPORARY TABLE deadlock_log (
ts DATETIME,
content TEXT
);
然后用 LOAD DATA INFILE 或客户端脚本（Python/Perl）解析日志，提取每段开头的时间戳和完整块。但实际中：
-
LOAD DATA无法按空行或模式分隔，必须预处理成 CSV/TSV - MySQL 内置正则能力弱（
REGEXP_SUBSTR8.0+ 才有），难以可靠提取多行块 - 时区处理易错：日志时间 vs 会话时区 vs 系统时区可能不一致
- 性能差：1GB 日志文件导入+解析可能卡住连接，不适合线上环境
替代方案：用 performance_schema 监控正在发生的死锁，但不保留历史
performance_schema.data_lock_waits 和 performance_schema.events_transactions_current 可以在死锁发生瞬间抓到冲突事务和锁等待关系，但这些表只保留当前活跃状态，事务提交/回滚后数据就清空了，不存档。
若想实时捕获，可行做法是：
- 写个轻量级轮询脚本，每秒查一次
data_lock_waits，发现OBJECT_SCHEMA和LOCK_TRX_ID非空就立刻记录快照 - 配合触发器不可行——死锁发生在引擎层，SQL 层无法拦截
- Percona Toolkit 的
pt-deadlock-logger就是干这事的：它持续 tail 日志并入库，比自己写更稳
真正能回溯“过去24小时”的，只有错误日志本身——前提是开了 innodb_print_all_deadlocks，且日志没被轮转删掉。其他所有“SQL 可查”的方案，都是绕路，还容易漏或不准。
