<p>phpEnv中定位长事务需手动查询INNODB_TRX表，执行SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 5;，并关联PROCESSLIST分析线程状态；PHP层须在beginTransaction()前埋点计时、commit/rollback后记录超时日志，避免事务内阻塞操作。</p>
phpEnv 中的 MySQL 无法直接通过配置项“记录长事务日志”——它本身不提供 long_transaction_log 这类原生开关，必须靠外部手段主动识别和捕获。
如何在 phpEnv 环境中定位正在运行的长事务
phpEnv 是本地开发环境套件（含 Apache/Nginx + PHP + MySQL），其 MySQL 实例默认未启用性能监控视图（performance_schema）或慢日志对事务时长的专项跟踪。要发现长事务，得手动查：
- 连接 MySQL 后执行：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 5;—— 这是判断“是否超 5 秒”的最轻量方式 - 搭配
information_schema.PROCESSLIST查看对应线程的 SQL（注意：若事务未显式开启，可能只显示SLEEP或空INFO） - 确保 MySQL 已开启
innodb_status_output和innodb_status_output_locks，否则SHOW ENGINE INNODB STATUS输出里锁信息不全
PHP 层面记录事务起止与超时行为
不能依赖 MySQL 自动记，得在 PHP 业务代码里埋点。尤其在使用 PDO 或 mysqli 手动控制事务时：
- 调用
$pdo->beginTransaction()前，用microtime(true)记下开始时间，存入上下文（如$_SERVER['trx_start']或静态属性） - 在
commit()或rollback()后立即计算耗时，若超过阈值（比如 3 秒），写入自定义日志表long_transaction_log，字段至少含：start_time、duration_sec、sql_hint（可截取当前栈中最近的 SQL）、script_name - 避免在事务内做文件 I/O 或远程请求——这是导致长事务的最常见原因，日志记录动作本身也必须是非事务性（用独立连接或
INSERT DELAYED）
phpEnv 下启用 MySQL 通用日志不现实，换用二进制日志 + 定时分析
通用查询日志（general_log）在 phpEnv 的默认 MySQL 配置中是关闭的，且开启后极易拖慢本地环境响应；更可行的是启用 binlog 并配合脚本提取长时间未提交的事务痕迹：
立即学习“PHP免费学习笔记（深入）”；
- 修改 phpEnv 内 MySQL 的
my.ini（路径类似C:\phpEnv\MySQL\my.ini），添加：[mysqld] log_bin = C:/phpEnv/MySQL/binlog/mysql-bin binlog_format = ROW expire_logs_days = 3
- 重启 MySQL 服务（phpEnv 控制面板里操作即可）
- 用
mysqlbinlog解析最新 binlog 文件，搜索关键词BEGIN和后续长时间无COMMIT/ROLLBACK的区间——这不是实时方案，但能回溯出哪些 PHP 脚本启动了悬停事务
为什么 phpEnv 的长事务监控容易失效
根本矛盾在于：phpEnv 是单机轻量环境，而长事务的典型危害（锁等待、undo 日志膨胀、MVCC 快照滞留）在低并发本地场景下几乎不暴露。你看到的“长事务”，90% 是 PHP 脚本卡在 curl、sleep、文件读写或未 catch 的异常里，MySQL 本身早已空闲。所以重点不在 MySQL 日志配置，而在：
- 检查 PHP 脚本是否在
try...catch外遗漏了rollback() - 确认
max_execution_time没被设为 0（无限执行），否则事务会随脚本挂起而持续持有锁 - 禁用 phpEnv 自带的“自动重连”（
mysqli.reconnect=On），它可能掩盖连接中断后事务未清理的问题
