ThinkPHP无内置数据库连接池和慢查询归档，监控需手动配置：开启debug、log_sql/trace_sql及log.level包含'sql'；Db::listen()可获取SQL、耗时与EXPLAIN（仅SELECT）；EXPLAIN需显式启用且禁用于生产；活跃连接数须直查MySQL；轻量埋点应记录句柄ID、操作类型与耗时而非完整SQL。
ThinkPHP 没有内置的数据库连接池，也没有开箱即用的慢查询自动归档或连接数实时仪表盘——所有有效监控都得靠你手动打开开关、绕过框架封装、直连 MySQL 服务端查数据。
怎么开启 SQL 执行耗时与参数记录
光设 debug => true 不够，log_sql => true（6.0+）或 trace_sql => true（5.1）也必须显式开启，且 log.level 得包含 'sql'。否则日志里只有一堆 INFO 和 ERROR，SQL 字符串压根不会落盘。
-
debug => false时，log_sql和trace_sql直接失效——这不是 bug，是框架硬性逻辑 -
Db::getLastSql()只返回最后一条 SQL 的字符串，没耗时、没绑定参数、没错误上下文，事务中极易误判目标语句 - 真正可用的是
Db::listen()回调，它在每次查询结束后触发（包括INSERT/UPDATE），参数含$sql、$time（毫秒）、$explain（仅 SELECT 且db.explain => true时非空）
为什么不能只靠 EXPLAIN 自动分析
EXPLAIN 是诊断索引缺失和全表扫描的关键，但 ThinkPHP 默认不执行它，必须手动配 'explain' => true。这个开关一开，每个 SELECT 都会额外跑一次 EXPLAIN，QPS 明显下降，生产环境严禁长期开启。
- 只有
SELECT触发EXPLAIN，UPDATE/DELETE即使带WHERE也不会解释 -
$explain在 MySQL 8.0+ 可能为空，需确认是否支持EXPLAIN FORMAT=JSON，否则降级为传统格式 - 框架启动、路由解析、配置加载阶段会执行大量内部 SQL（如读
system_config表），这些和业务无关，但混在日志里会掩盖真问题；建议在Db::listen()回调里加过滤：debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 1)[0]['class'] ?? ''跳过think\开头的调用栈
怎么查真实的活跃连接数
ThinkPHP 的 Db::getConnect() 或 Db::getPdo() 返回的是当前请求绑定的 PDO 实例，不是全局连接状态。所谓“连接池监控”是误用概念——TP 根本没有跨请求的连接池，只有 PDO 层的长/短连接复用。
立即学习“PHP免费学习笔记（深入）”；
- 必须直连 MySQL 查：
SHOW PROCESSLIST或SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' - 执行用户需有
PROCESS权限，线上常被禁用，得提前申请 - 别依赖
SHOW PROCESSLIST的Time字段判断“慢连接”——TP 事务未提交时，状态可能是Query，但实际卡在 PHP 层 - 高并发下频繁查
information_schema.PROCESSLIST会锁表，拖慢性能，只应在低频调试或定时脚本中使用
如何轻量埋点连接开销而不拖慢服务
想定位谁在滥用连接，最有效的是记录每次查询的 PDO 句柄 ID、是否复用、是否在事务中，而不是记完整 SQL——大文本或敏感字段会撑爆日志。
- 监听
think\db\Connection的connect事件，用spl_object_hash($pdo)记录句柄唯一标识 - 给
think\db\Query::execute()加 AOP（通过中间件或重写 Query 类），记录$this->connection->getPdo()的 hash 值 +microtime(true)+ 当前内存占用 - 日志只存：表名、操作类型（
select/insert）、耗时、是否 in transaction；避免全 SQL - 单次查询增加约 0.02ms，但日志 I/O 是瓶颈，建议异步写入 Redis 或本地文件缓冲
真正卡住系统的，往往不是某条慢 SQL，而是事务没提交导致连接长期挂起、或多个数据库配置（mysql 和 mysql_slave）各自建连却没配好 max_connections。监控不是堆工具，是先理清 TP 和 PDO、MySQL 三层之间谁管什么、谁不管什么。
