由 dawei MySQL分布式追踪不是简单地记录SQL执行时间，而是将数据库请求嵌入整个微服务调用链中，还原“哪次HTTP请求、经由哪个服务、在哪个线程、触发了哪条慢查询、关联了哪些上游上下文”的完整路径。
创意图AI设计，仅供参考
实现的关键在于统一上下文透传：应用层需通过OpenTelemetry或SkyWalking SDK注入trace_id、span_id，并在JDBC连接建立时，将这些ID以注释形式附加到SQL语句前，例如/ trace_id=abc123,span_id=def456 / SELECT FROM users WHERE id=1001。MySQL自身不解析注释，但代理层（如ShardingSphere-Proxy）或APM探针可提取并关联。
采集侧需避免全量日志冲击。推荐采用采样策略——对耗时超过阈值（如500ms）的查询强制记录，同时对含错误码、事务超时、死锁回滚等关键事件100%捕获。配合慢日志解析工具（如pt-query-digest）与链路系统打通，实现从trace视图一键跳转到对应SQL的执行计划与历史耗时分布。
运维诊断时，不再孤立看slow_log。当业务反馈“订单提交变慢”，可先在追踪平台按业务标识（如order_id）搜索链路，定位到MySQL节点Span，查看其DB.WaitTime（连接等待）、DB.ExecuteTime（实际执行）、RowsAffected等原生指标，并叠加该时刻的MySQL内部状态：InnoDB buffer pool hit rate、thread running count、锁等待队列长度——所有数据时空对齐，源自同一毫秒级时间戳。
安全与性能需同步考量。追踪注入的SQL注释必须白名单校验，禁止用户可控字段参与拼接；高并发场景下，避免在连接池每次获取连接时重复注入，宜在首条SQL中写入，后续复用同一Span上下文。代理层应支持自动剥离注释再发往MySQL，确保兼容性与审计合规。
手册落地价值不在功能堆砌，而在闭环：开发用trace快速归因，DBA用关联指标精准调优，SRE用链路异常模式训练告警规则。一次跨库事务失败，可同时看到Spring事务管理器的rollback动作、Seata分支注册日志、MySQL binlog写入延迟、以及中间件连接断开瞬间的网络RTT突增——真正实现代码、SQL、系统、网络的可观测融合。