phpenv的mysql易现“假死循环”根本因三类场景被放大：while中无限制查同结果、触发器自改原表报error 1442但php未捕获、cte递归超默认深度；须调优my.ini参数并加php层超时与异常防护。
phpEnv 是 Windows 下轻量级 PHP 开发环境，自带 MySQL（通常为 5.7 或 8.0），但默认配置对循环查询、长事务、连接堆积等缺乏防护，容易因误写 SQL 或触发器逻辑失控导致“假死循环”——不是 CPU 占满，而是连接卡住、查询挂起、Workbench 无响应。
为什么 phpEnv 的 MySQL 容易陷入查询死循环
根本原因不是 MySQL 本身无限跑，而是三类典型场景在 phpEnv 小资源环境下被放大：
- 在
WHILE循环中反复执行未加限制的mysql_query("SELECT ... LIMIT 1")，结果集永远不变，循环永不退出 - 触发器里对同一张表做
UPDATE，触发ERROR 1442，但 PHP 没捕获异常，脚本继续执行下一轮循环 - CTE 递归查询没设
cte_max_recursion_depth，MySQL 8.0+ 默认是 1000，在低配机器上耗尽内存或超时后表现像“卡死”
phpEnv 中必须改的 MySQL 配置项
打开 phpEnv 安装目录下的 mysql\my.ini（不是 php.ini），在 [mysqld] 段落追加以下几行，重启 MySQL 服务生效：
max_connections = 100 wait_timeout = 30 interactive_timeout = 30 cte_max_recursion_depth = 100 max_sp_recursion_depth = 10
说明：
-
max_connections = 100：防止 PHP 脚本开太多连接把服务拖垮（phpEnv 默认常设为 151，对本机开发过重） -
wait_timeout = 30：空闲连接 30 秒自动断开，避免mysqli_connect()后忘了close()导致连接堆积 -
cte_max_recursion_depth = 100：CTE 递归层数从默认 1000 降到 100，既防误操作，又避免 8.0+ 环境下 CTE 查询“看起来卡住” -
max_sp_recursion_depth = 10：存储过程/触发器嵌套深度限制，配合ERROR 1442提前暴露问题
PHP 层要加的防护代码（不能只靠 MySQL 配置）
phpEnv 常搭配老式 mysqli 或 PDO，但无论哪种，都得在查询前主动设限：
- 用
mysqli时，在query()前加超时：mysqli_options($conn, MYSQLI_OPT_CONNECT_TIMEOUT, 5); mysqli_options($conn, MYSQLI_OPT_READ_TIMEOUT, 10); - 用
PDO时，DSN 加;timeout=10，并统一用try/catch捕获SQLSTATE[HY000]和错误码1213（死锁）、1442（触发器循环） - 所有循环取数据的逻辑，必须有明确退出条件，例如：
if ($i++ > 1000) { throw new Exception("Query loop exceeded 1000 iterations"); }
特别注意：phpEnv 自带的 MySQL 日志默认关闭，查不到 ERROR 1442 或死锁详情。务必手动开启：log_error = "mysql_error.log" 并确认该文件路径可写。
调试时最容易被忽略的点
你看到“页面白屏”或“请求超时”，第一反应常是 PHP 脚本卡了，但实际可能是 MySQL 连接池已满、某个慢查询占着连接不放、或者触发器失败后静默退出——而 phpEnv 的托盘图标不会报错，错误日志也不自动弹出。
真正有效的排查顺序是：
- 先看
mysql_error.log里有没有ERROR 1442或Lock wait timeout - 再运行
SHOW PROCESSLIST;，找State是Sleep但Time超过 30 秒的线程 - 最后检查 PHP 代码里是否漏了
mysqli_free_result()或$stmt->close()，导致结果集一直占用连接
这些细节在生产环境可能由 DBA 或运维兜底，但在 phpEnv 下，全得你自己盯住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
