问题1 gv$ob_sql_audit视图的两个字段，摘录自官文
TRACE_ID: 这条语句的 Trace ID
FLT_TRACE_ID: 记录全链路诊断的 Trace ID。
如果为空，则说明没有被全链路诊断监控。
该字段是UUID，有别于Trace，其表示形式示例 为:000600d6-5de-038c-6c80-df07e4e79149
我的问题是，对指定TRACE_ID进行全链路诊断之后，FLT_TRACE_ID字段才有值 ？
问题2
举例说明，使用ob_tenant_trace_enable开启租户级别的全链路诊断之后，FLT_TRACE_ID字段才有值 ？
gv$ob_sql_audit 里的 每一个在 observer 运行过的 SQL 记录，都会有对应的 trace_id 。但是 flt_trace_id 不一定会，通常这是 OB 抽样决定的。
但是如果客户端会话链路上所有组件都开通了 全链路诊断对应的能力，那么这个会话发出的所有 sql 的 flt_trace_id 都有值 （这个有性能损失代价，所以不是默认行为）。
这个规则将来还可能改变。
全链路性能诊断只是对链路上某个环节性能怀疑比较大的时候才有用，如果性能问题的主要根源还是 sql 在 observer上运行的慢，那么直接分析这个 sql 的 执行计划以及 trace_id对应的日志通常也够了。
其他方法参考：
需要先打开全链路诊断的功能，打开了之后全链路的flt_trace_id会记录到sql_audit中。参见文档：https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573983
这里需要注意，打开的时候会设置采样率，这里的采样率指的是打印到trace.log的概率。
但有时候你会发现你并没有租户级别或者session级别的设置，但是sql_audit中有些flt_trace_id是存在的，这是因为默认情况下全链路的采集是开了的，采样概率是一百万分之一(非常低)，之所以设置的概率比较低是因为全量打印全链路的信息会对性能有一定的影响。所以一般来说推荐的用法就是在用的时候临时开一下session级别的，用完关闭。
这个采纳按钮太少了，应该每个回答，分别设置一个采纳按钮。 因为可能多个人的回答，都很优秀，我都可以采纳，建议该讲一下。
你的回答，也很优秀，可是只有一个采纳按钮。
你的连接丢失了，打不开了
可以打开的，我错了
