webman中pdo/mysqli同步阻塞导致worker卡死：一个慢查询会使整个进程无法响应其他请求，引发接口变慢、cpu飙升，必须切换异步客户端并定位慢sql。
Webman 应用里 MySQL 慢查询不报错，但接口变慢、CPU 持续飙高——这基本不是数据库本身扛不住，而是 PHP Worker 被同步阻塞卡死了。必须立刻切到异步客户端 + 慢查定位双线并行。
Webman 里为什么 PDO/MySQLi 一慢就拖垮整个 Worker
Webman 基于 Workerman，是常驻内存的事件驱动模型。但默认的 PDO 和 mysqli 是同步阻塞 I/O：一个慢查询执行期间，当前 Worker 进程完全无法处理其他请求，相当于“一人感冒，全队停工”。
- 现象：
top看到某个php进程 CPU 占用 99%，strace -p $pid显示卡在recvfrom或poll - 根源：没用
swoole_mysql、co\mysql或适配 Workerman 的异步 MySQL 客户端（如spiral/database+amphp/mysql） - 后果：哪怕只有 1% 的请求触发慢查，QPS 也会断崖下跌，且
SHOW PROCESSLIST看不到堆积，因为连接早被 PHP 层“挂起”了
如何快速确认是不是 MySQL 慢查询导致 Webman 响应延迟
别等用户投诉再动手。先看三处最轻量、最直接的证据：
- 打开 MySQL 慢查询日志：
SET GLOBAL slow_query_log = ON；SET GLOBAL long_query_time = 0.5；然后查/var/lib/mysql/slow.log，重点找Rows_examined超过 10000 或Query_time> 0.3s 的语句 - 在 Webman 控制器里加一行打点：
error_log('SQL start: ' . microtime(true), 3, '/tmp/webman-sql.log')，配合慢日志时间戳比对，确认是否同一时刻触发 - 检查
php-fpm状态页（如果用了 Nginx + FPM 中转）或 Webman 自带的/status，若active processes长期接近max_children，且state列大量显示Running但无新响应，大概率是 SQL 卡住
Webman 生产环境安全启用 MySQL 慢查监控的实操配置
不能只开日志就完事。要能关联到具体请求、方便回溯、不拖慢服务：
- MySQL 端：在
my.cnf加上log_queries_not_using_indexes = ON，避免漏掉“快但不该快”的隐性慢查（比如走了索引但回表太多） - PHP 端：用
pdo_mysql的PDO::ATTR_STATEMENT_CLASS注入执行耗时记录逻辑，或更推荐——改用spiral/database，它原生支持 query hook，可统一记录sql、bindings、duration到monolog，并带上request_id - Webman 中间件层：写一个轻量中间件，在
$response发送前检查本次请求中所有 DB 查询总耗时是否超阈值（如 200ms），超则自动记录到独立日志，并附上$_SERVER['REQUEST_URI']和debug_backtrace()片段
EXPLAIN 看懂就敢动手优化的关键字段
拿到慢 SQL 后，EXPLAIN 输出里真正该盯死的只有三个字段，其他都是干扰项：
-
type出现ALL：百分百全表扫描，优先加索引。别信“数据少没关系”，Webman 高并发下，10 行表扫 1000 次 = 1 万行扫描 -
key是NULL：说明压根没走索引。检查WHERE条件字段是否在联合索引最左匹配，或是否存在隐式类型转换（比如user_id是字符串，却用整数查询） -
Extra含Using temporary或Using filesort：GROUP BY / ORDER BY 没命中索引排序，必须建覆盖索引，例如INDEX(status, created_at)要比单列索引有效得多
复杂 JOIN 不用硬啃执行计划。先把 EXPLAIN FORMAT=JSON 输出粘贴进 https://explain.dalibo.com，它会直接标红瓶颈节点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
