不能，general_log仅记录独立语句，不关联事务上下文；真正追踪需performance_schema.events_transactions_*表+gtid+应用层标记。
MySQL 的 general_log 能否记录事务全过程？
不能直接记录事务的“开启—执行—提交”逻辑流。general_log 只记录每条独立语句（如 BEGIN、INSERT、COMMIT），不关联它们属于同一个事务，也不记录事务 ID 或会话上下文。开启后日志量爆炸，且无法回溯某次事务的完整路径。
实操建议：
- 仅在调试单个会话时临时开启：
SET GLOBAL general_log = ON;，并搭配SET GLOBAL log_output = 'TABLE';避免写文件干扰； - 查完立刻关掉：
SET GLOBAL general_log = OFF;，否则影响性能； - 查表时加
WHERE argument REGEXP '^BEGIN|^INSERT|^UPDATE|^COMMIT|^ROLLBACK'过滤，但依然无法确认这些语句是否同属一个事务。
真正能追踪事务生命周期的是 binlog + GTID + performance_schema
MySQL 8.0+ 中，performance_schema.events_transactions_current 表提供每个活跃事务的实时快照，包含状态、开始时间、事务 ID（TRANSACTION_ID）、GTID（如果启用）以及关联的线程 ID。
实操建议：
- 确保已启用：
performance_schema = ON（默认开启），且events_transactions_history_long消费器已打开：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_transactions_history_long';； - 开启事务后立即查：
SELECT THREAD_ID, EVENT_ID, STATE, TRX_ID, GTID, TIMER_START FROM performance_schema.events_transactions_current WHERE STATE = 'ACTIVE';； - 事务提交后，它会移入
events_transactions_history_long，可按THREAD_ID和时间范围回溯完整链路； - 若用 GTID 模式（
gtid_mode = ON），GTID字段就是全局唯一标识，可在 binlog 中用mysqlbinlog --base64-output=DECODE-ROWS -v搜索该 GTID，看到原始 SQL 和时间戳。
为什么 slow_query_log 对事务追踪基本没用？
slow_query_log 只记录执行时间超阈值的单条语句，而事务中多数语句（如 INSERT）本身很快，COMMIT 的耗时又常被归因于刷盘或锁等待，不体现为“慢查询”。更关键的是：它不记录 BEGIN，也不把多条语句聚合成一次事务事件。
常见错误现象：
- 开了
long_query_time = 0强制记录所有语句，结果日志里只有零散的INSERT和COMMIT，找不到起始点； - 误以为
SET long_query_time = 0后就能看到事务边界 —— 实际上BEGIN默认不记日志（除非显式执行SELECT SLEEP(0)类触发语句）； - 在从库上查 slow log，却发现事务被合并重写（如 MTS 并行回放后时间戳错乱），根本对不上主库行为。
最实用的线上追踪方案：结合 connection_id + performance_schema + 应用层打点
纯数据库侧无法 100% 还原事务上下文，必须依赖应用层配合。核心是让每次事务开启时，应用主动注入可识别的标记（如注释），再通过 performance_schema 关联。
实操建议：
- 应用在
BEGIN前执行：/* tx_id=abc123 */ SELECT 1;，确保该注释出现在同一连接后续所有语句的events_statements_history的SQL_TEXT字段中； - 查事务链路时，先定位该
connection_id对应的THREAD_ID：SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = ?;； - 再查该线程的事务事件：
SELECT * FROM performance_schema.events_transactions_history_long WHERE THREAD_ID = ? ORDER BY TIMER_START;； - 最后用
THREAD_ID关联语句历史：SELECT SQL_TEXT FROM performance_schema.events_statements_history WHERE THREAD_ID = ? AND SQL_TEXT LIKE '%tx_id=abc123%';； - 注意：
events_transactions_history_long是环形缓冲区，默认只存 10000 条，高并发下可能被覆盖，需及时采集。
真正难的不是查哪张表，而是保证事务标记不被 ORM 拦截、不被连接池复用污染、不在分布式调用中丢失上下文 —— 这些都得在应用代码里做防御性设计。
