TP6 的 trigger_sql 设为 true 在生产环境是明确的性能风险开关，会显著增加 SQL 执行开销、引发日志 I/O 瓶颈、连接耗尽及排查误导，应禁用全局配置并按需使用异步或专业 APM 方案。
TP6 的 trigger_sql 设为 true 在生产环境会显著放大 SQL 执行开销，尤其在高并发或复杂查询场景下，可能引发日志写入瓶颈、连接资源耗尽和监控误判，不是“可选功能”，而是明确的性能风险开关。
触发 SQL 监听本身就有固定开销
开启后，TP6 会对每一条执行的 SQL（包括 prepare、execute、fetch 等阶段）做拦截、格式化、拼接上下文（如 trace_id、文件行号），并写入日志或调试缓冲区。这个过程：
- 每次 SQL 执行都新增 0.2–1.5ms 的 CPU 和内存开销（实测 PHP 8.2 + MySQL 8.0 场景）
- 日志内容含完整 SQL 文本、绑定参数、执行耗时、堆栈，单条日志体积常超 2KB
- 若配置为写文件（默认行为），高频写入会触发磁盘 I/O 阻塞，
fwrite()调用可能成为瓶颈 - 若启用了
think\log\driver\File并未配置 rotate，则日志文件持续膨胀，fopen()和fseek()开销随文件增大而上升
与数据库触发器（MySQL Trigger）无关，但容易混淆
trigger_sql 是 ThinkPHP 框架层的日志开关，和 MySQL 的 DML 触发器完全无关。但它名字带 “trigger”，常被误认为“启用数据库触发器”，导致两个问题：
- 运维人员看到配置名，误以为是数据库功能开关，忽略其实际是应用层日志行为
- 当线上出现慢 SQL 或连接堆积时，排查方向容易跑偏——先查 MySQL 触发器，却没意识到是 TP6 日志逻辑拖慢了整个请求生命周期
- 部分团队在压测中发现 TPS 上不去，最终定位到是
trigger_sql=true导致单请求多出 3–5 次同步日志写入，占总耗时 12% 以上
高并发下易引发资源雪崩
该配置在生产环境最危险的表现不是“变慢一点”，而是资源不可控地级联恶化：
- 每个请求平均执行 8 条 SQL？开启后就多出 8 次日志写入；QPS 达到 500，即每秒 4000+ 次日志操作
- 若日志驱动未做异步封装（TP6 默认 File 驱动是同步阻塞），PHP-FPM worker 会卡在
fwrite()上，导致可用 worker 快速耗尽，新请求排队等待 - 错误日志中可能出现大量
PHP Warning: fwrite(): Write of N bytes failed，实则是磁盘满或 inode 耗尽，根源却是日志无节制累积 - 某些云环境（如阿里云轻量应用服务器）对小文件 I/O 限频严格，开启后直接触发平台级限流告警
替代方案：按需开启，而非全局常开
生产环境不等于“完全不能用”，关键是控制粒度和落地方式：
- 禁用全局配置：
'trigger_sql' => false，这是生产环境的标准基线 - 临时诊断时，改用
Log::record()手动记录关键路径 SQL，避免全量捕获 - 如需长期审计，应接入专业 APM 工具（如 SkyWalking、Zipkin），它们通过扩展钩子采集，支持采样率控制、异步上报、结构化存储
- 若必须保留框架日志，建议切换为
think\log\driver\Socket或自定义 Swoole Channel 异步驱动，彻底剥离日志 I/O 对主流程的影响
