版本：5.7.25-OceanBase_CE-v4.2.0.0
MYSQL存储过程,大概两百行内容。
测试调用存储存储过程会有延时，在存储过程开始和末段都insert一条记录。结果开始调用存过到插入第1条insert记录，中间就有几十秒的延时。即call开始到存储过程的最开始的第1个insert语句，中间就有几十秒的延时。
不管是用工具连接调用还是接口调用，都有这个问题，存储过程调用另外一个存储过程，另外一个存储过程也会有调用延时问题。
第一次调用都有这个问题，第2次调用则快很多
可以使用全链路诊断方法获取下对应的调用链信息，看下是哪一步骤出现了延迟问题。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000218369
另外，预告下1.5版本的obdiag会支持全链路诊断的功能
实际是存储过程CALL到真正运行起来，中间就花了几十秒，我看不少人都遇到这种问题，能查查你们数据库的问题吗？
你好，应该是第一次编译慢,可以收集下trace日志看下执行存储过程的耗时
每次慢都是隔几分钟后。我觉得是几分钟后存储过程的执行计划缓存没了，重新调用又要生成新的执行计划耗了时间，重新调用后，第一次也是花费很长时间，然后调用就快了。如此循环！
存储过程没有多次编译，现象是每隔一会（几分钟）首次调用就慢，然后调用才快。我猜测是几分钟后存储过程的执行计划缓存没了，重新调用又要生成新的执行计划耗了时间，重新调用后，第一次也是花费很长时间，然后调用就快了。如此循环！
如果是这样，存储过程调用生成执行计划要花费几十秒效率也太慢了，而且执行计划缓存几分钟就会失效
带参数不会那么容易穿线缓存失效的问题，ddl会导致缓存失效，是不是中间有过ddl?
没有，存储过程就只有update、delete、insert操作而已，
麻烦确认下
1.是否使用了临时表
2.是否切换了session
3.收集下trace日志
1、未使用临时表
2、未切换session
收集到trace日志发上来吗
是的
老师,获取的observer日志应该不全,麻烦让重新执行下,取下完整的observer日志和trace_id
https://mijuguanjia.wehufu.cn:1088/files/suyh/observer.zip
https://mijuguanjia.wehufu.cn:1088/files/suyh/trace.zip
老师，您看下日志，存储过程PRO_SET_SCORE
已转发给相关老师帮忙确认
老师，当前首次调用慢应该是符合预期的吧，没有命中plan_cache，走了完整的sql解析过程，当前日志内并没有明显可以看到报错的地方，慢的sql和快的sql的物理执行计划和sql_audit信息是否存在呢，对比分析一下会更好
测试存储过程.txt (4.1 KB)
老师，你看下我附件这个测试的很简单存储过程，
每次首次调用call PRO_SET_SCORE123();都会很慢（这个可以通过删除重新创建存储过程测试）
隔一段时间再调用也很慢，接着调用就好了。
已经转发给相关的研发老师进行判断
DROP TABLE IF EXISTS table1;
CREATE TABLE table1 (
col1 varchar(200),
col2 varchar(200),
col3 varchar(200)
) ENGINE = oceanbase CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci
INSERT INTO table1 VALUES (‘11’, ‘11’, ‘11’);
INSERT INTO table1 VALUES (‘22’, ‘22’, ‘22’);
INSERT INTO table1 VALUES (‘33’, ‘33’, ‘33’);