decode是个什么动作？

关于几个等待时间的疑问：

• NET_TIME：这个指的是当前实例上SQL在另外实例上远程执行时的时间吗？ 从本实例发出RPC后到对端ob server对rpc请求返回的一个回应间的时间(此时远端还未进入租户队列)？
• NET_WAIT_TIME: 本实例作为远程执行的执行实例时从接收到RPC请求后到进入租户队列间的等待时间？这部分时间长主要原因是什么？

• DECODE_TIME: decode是个什么动作？

• NET_TIME：这个指的是当前实例上SQL在另外实例上远程执行时的时间。从本实例发出RPC后到对端ob server对rpc请求返回的一个回应间的时间。

• NET_WAIT_TIME: 本实例作为远程执行的执行实例时从接收到RPC请求后到进入租户队列间的等待时间。这部分时间长主要原因可能是网络延迟、资源竞争等。
• DECODE_TIME: decode是一个SQL的解析过程，包括词法分析、语法分析、语义分析等步骤。

关于等待事件时间的描述
这里的当前等待事件、所有等待指的是什么？ 例如 一个SQL执行请求记录到sql_audit后物理他是何种类型的执行计划在初始的Observer是否是只会记录一条记录？ 如果只有一条记录，他在执行过程中会经历很多个等待，是每次等待时都会把sql_audit中当前等待事件和 wait_time_micro都update 然后将总时间累加到total_wait_time_micro??

• 当前等待事件：指的是在执行过程中正在经历的等待事件。
• 所有等待：指的是在执行过程中所有的等待的总和。
• 一个SQL执行请求记录到sql_audit是不止一条记录的。以下情况会单独记录一个sql audit记录：
  • 接收用户请求的处理线程；
  • 用户SQL触发的内部SQL执行(is_inner_sql = true)；
  • 远程执行(is_executor_rpc= true)；
  • 每个PX工作线程执行(is_executor = true)。

行锁的queue也是使用租户的请求队列吗？不通过lock表判断如何区分是行锁排队？

• 行锁的queue和租户的请求队列并不是一回事，不过队列等待时间这个指标上是包括了行锁的等待时间的。不通过lock表的话还可以结合sql_audit中的event字段来判断，不过建议是通过lock表去判断会更直接一点。

还有有疑问，sql_audit记录的用户申请了无非2种 is_executor_rpc=0 或1 ，假如一个SQL执行需要本地扫描一个分区、远端扫描一个分区，对于远端的扫描发送rpc后 是不是就处于等待远端返回的状态，按途中的表示 位置1 是本地的执行，位置2 及以后是远端的执行，那么远端执行的相应时间会累积到本地的sql audit记录里吗？ 如果是远端解释到rpc后完成2及之后的动作给本地发送rpc，如果是这样的话这个图的顺序看起来又不太对？

• 一条请求并不是只有一条sql_audit记录，远程执行的请求在远程机器上也会生成sql_audit记录，他们之间通过trace_id进行关联。
• sql_audit的记录是只有执行完（成功或者失败）才会记录，执行过程中是不记录的。
• 所以这张图并不是你所说的1是本地，2以后是远程。这张图是相对于一条sql_audit来说的，从发起请求到结束请求完整的时间记录。

关于当前等待事件，假如一个sql语句只在本地执行，他可能经历了多个latch事件、IO事件，在sqlaudit钟只有一条记录，是不是每次等待事件发生变化时更新audit记录的event相关字段？

• event字段是记录最长等待事件，所以我上面的回复中说到可以结合sql_audit中的event字段来判断行锁等待，不过建议是通过lock表去判断会更直接一点，就是因为event并不是全部都会记录，是记录最长的等待事件。