在做 SAP HANA 性能分析时，很多团队都会遇到一种很典型的尴尬：业务侧只给你一句CALL，比如CALL P1('TA')，但真正耗时、真正吃内存、真正导致锁等待的，往往是这个存储过程内部被展开、被改写、被优化器重排后的多条 SQL 语句。你在监控视图里看到的，可能只是一个CALL的总耗时；你在代码里看到的，可能只是几段看似简单的SELECT；可线上告警给你的，是 CPU 飙升、内存压力、批处理超时，甚至偶发 OOM。这个时候，SQL Trace的价值会立刻显现出来：它把执行过程拆开到语句级别，告诉你每一条 SQL 的整体执行时间、影响记录数、潜在错误信息、连接信息等，让你能够从CALL的黑盒里把真正的热点语句拉出来逐条审视。更关键的是，在针对 SQLScript 过程时，SQL Trace还能采集过程内部的inner statements，并且可以把内部查询的中间结果记录下来，帮助你在不反复执行整个过程的情况下复现问题查询、做最小化实验与修复验证。(SAP Help Portal)下面我用一