GV$OB_SQL_AUDIT视图中是记录所有请求的sql吗？
根据文档库中的信息，GV$OB_SQL_AUDIT 视图确实记录了所有 OBServer 节点上每一次 SQL 请求的来源、执行状态等统计信息。无论是 SQL 执行成功还是失败，该视图都会记录相关信息，包括 SQL 文本、执行计划等关键信息。因此，可以认为 GV$OB_SQL_AUDIT 视图记录了所有请求的 SQL。
具体依据如下：
-
片段标题: GV$OB_SQL_AUDIT → 功能描述
视图GV$OB_SQL_AUDIT用于展示所有 OBServer 节点上每一次 SQL 请求的来源、执行状态等统计信息。 -
片段标题: 分析 SQL 监控视图 → SQL Audit 监控视图
GV$OB_SQL_AUDIT是最常用的 SQL 监控视图，能够记录每一次 SQL 请求的来源、执行状态、资源消耗及等待事件，无论 SQL 执行是成功还是失败。
综上所述，GV$OB_SQL_AUDIT 视图中记录的是所有请求的 SQL。
具体信息可参考以下文档:
如果observer实例的吞吐量(TPS+QPS)很高，记录所有的请求SQL 会不会影响性能呢？
根据文档库中的信息，GV$OB_SQL_AUDIT 视图确实会记录所有 SQL 请求的详细信息，包括执行计划、资源消耗等。如果 Observer 实例的吞吐量（TPS+QPS）很高，记录所有的请求 SQL 确实可能会对性能产生一定影响。以下是具体分析：
1. 性能影响因素
- 写入开销：每次 SQL 请求都会在 GV$OB_SQL_AUDIT 中生成一条记录，这需要一定的内存和磁盘 I/O 资源来存储这些数据。
- 查询开销：如果需要频繁查询 GV$OB_SQL_AUDIT 视图以进行性能分析或问题排查，可能会进一步增加系统的负载。
- 内存占用：为了保证快速访问，部分审计数据可能缓存在内存中，高吞吐量场景下可能导致内存使用率上升。
2. 优化建议
尽管记录所有 SQL 请求可能会带来性能开销，但 OceanBase 数据库提供了一些机制来降低这种影响：
(1) 调整审计级别
- OceanBase 支持通过配置参数
ob_sql_audit来控制是否记录 SQL 审计信息。如果性能压力较大，可以考虑关闭不必要的审计功能。 - 示例代码：
-- 查看当前审计状态 SHOW VARIABLES LIKE 'ob_sql_audit'; -- 关闭 SQL 审计功能 SET GLOBAL ob_sql_audit = OFF;
(2) 限制记录范围
- 可以通过设置
ob_sql_audit_filter参数，仅记录特定类型的 SQL 请求（如耗时较长的 SQL 或错误 SQL），从而减少记录量。 - 示例代码：
-- 设置仅记录耗时超过 1 秒的 SQL SET GLOBAL ob_sql_audit_filter = 'ELAPSED_TIME>1000000';
(3) 定期清理审计数据
- GV$OB_SQL_AUDIT 的数据会随着时间增长而累积，建议定期清理或归档历史数据，避免其占用过多存储空间。
- 示例代码：
-- 删除指定时间范围内的审计记录 DELETE FROM oceanbase.__all_virtual_sql_audit WHERE request_time < time_to_usec(now() - INTERVAL 1 DAY);
(4) 优化系统资源配置
- 如果吞吐量非常高，可以通过增加租户内存配额或调整计划缓存大小（
ob_plan_cache_percentage）来缓解性能压力。 - 示例代码：
-- 增加计划缓存占比 SET GLOBAL ob_plan_cache_percentage = 10;
3. 总结
虽然记录所有请求 SQL 在高吞吐量场景下可能会对性能产生一定影响，但通过合理配置审计参数、限制记录范围以及优化系统资源配置，可以有效降低这种影响。如果性能压力过大且不需要完整的 SQL 审计信息，建议适当关闭或调整审计功能。
以上内容基于文档库中的信息及 OceanBase 社区版的最佳实践。如果仍有疑问，建议参考官方文档或联系 OceanBase 技术支持团队获取更多帮助。
更多信息请查看:
您好，您提到的问题似乎与 OceanBase 没有关联，我无法回答，敬请谅解! 如果您有其他 OceanBase 相关问题，欢迎继续提问。
这个数据是记录在内存中的，TPS和QPS很高的情况对性能影响也很小，当然你要是追求极致的性能，还是建议关闭SQL_AUDIT