从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://www.amazonaws.cn/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。 # 系统表和视图参考 Amazon Redshift 有许多包含系统运行方式相关信息的系统表和视图。您可以像查询任何其他数据库表那样查询这些系统表和视图。本部分提供一些系统表查询示例并予以讲解： + 生成的系统表和视图的类型有何不同 + 您可以从这些表中获得哪些类型的信息 + 如何将 Amazon Redshift 系统表联接到目录表 + 如何管理系统表日志文件的增长 某些系统表只能由 Amazon 人员用于诊断目的。以下部分讨论可供系统管理员或其他数据库用户查询有用信息的系统表。 **注意** 自动或手动集群备份（快照）中不包含系统表。STL 系统视图保留七天的日志历史记录。保留日志不要求客户执行任何操作，但如果需要将日志数据存储超过 7 天，则必须定期将日志数据复制到其他表，或将日志数据卸载到 Amazon S3。 **Topics** + [系统表和视图类型](#c_types-of-system-tables-and-views) + [系统表和视图中的数据可见性](#c_visibility-of-data) + [将仅预调配的查询迁移到 SYS 监控视图查询](#sys_view_migration-use_cases) + [使用 SYS 监控视图改进查询标识符跟踪](#sys_view_migration-query-id) + [系统表查询、进程和会话 ID](#system-table-query-process-session-ids) + [SVV 元数据视图](svv_views.md) + [SYS 监控视图](serverless_views-monitoring.md) + [用于迁移到 SYS 监控视图的系统视图映射](sys_view_migration.md) + [系统监控（仅已预置）](c_intro_system_views.md) + [系统目录表](c_intro_catalog_views.md) ## 系统表和视图类型 系统表和视图分为几种类型： + SVV 视图包含有关数据库对象的信息，并引用了临时 STV 表。 + SYS 视图用于监控预置集群和无服务器工作组的查询和工作负载使用情况。 + STL 视图从长久保存到磁盘的用于提供系统历史记录的日志生成。 + STV 表是虚拟系统表，包含当前系统数据的快照。它们基于临时的内存数据，不会长久保存到基于磁盘的日志或常规表中。 + SVCS 视图提供了有关主集群和并发扩展集群上的查询的详细信息。 + SVL 视图提供有关主集群查询的详细信息。 系统表及视图不使用与常规表相同的一致性模型。在查询它们时，特别是查询 STV 表和 SVV 视图时，一定要注意这个问题。例如，对于包含列 c1 的常规表 t1，下面的查询不会返回任何行： ``` select * from t1 where c1 > (select max(c1) from t1) ``` 但是，下面针对系统表的查询可能返回行： ``` select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state) ``` 该查询可能返回行的原因在于：currenttime 是临时的，查询中的两个引用在求值时可能返回不同的值。 另一方面，下面的查询也可能不返回行： ``` select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state) ``` ## 系统表和视图中的数据可见性 **注意** 在记录有关对 Data Catalog 视图执行的查询的信息时，Amazon Redshift 会自动屏蔽某些系统表列，以防止泄露敏感元数据。有关更多信息，请参阅《Amazon Redshift Management Guide》**中的 [Secure logging](https://docs.amazonaws.cn/redshift/latest/mgmt/db-auditing-secure-logging.html)。 系统表及视图中的数据有两类可见性：对用户可见和对超级用户可见。 只有具有超级用户权限的用户才能看到属于超级用户可见类别的表中的数据。普通用户可以查看对用户可见的表中的数据。要使普通用户能够访问对超级用户可见的表，请向普通用户授予对该表的 SELECT 权限。有关更多信息，请参阅 [GRANT](r_GRANT.md)。 默认情况下，在大多数对用户可见的表中，普通用户看不到其他用户生成的行。如果向普通用户授予 [SYSLOG ACCESS UNRESTRICTED](r_ALTER_USER.md#alter-user-syslog-access)，则该用户可以查看用户可见表中的所有行，包括由其他用户生成的行。有关更多信息，请参阅 [ALTER USER](r_ALTER_USER.md) 或 [CREATE USER](r_CREATE_USER.md)。SVV\_TRANSACTIONS 中的所有行都对所有用户可见。有关数据可见性的更多信息，请参阅 Amazon Web Services re:Post 知识库文章[如何允许 Amazon Redshift 数据库普通用户查看我的集群中其他用户系统表中的数据？](https://repost.aws/knowledge-center/amazon-redshift-system-tables)。 对于元数据视图，Amazon Redshift 不允许具有 SYSLOG ACCESS UNRESTRICTED 权限的用户查看。 **注意** 如果向用户授予对系统表的无限制访问权限，用户便可以看到由其他用户生成的数据。例如，STL\_QUERY 和 STL\_QUERY\_TEXT 包含 INSERT、UPDATE 和 DELETE 语句的完整文本 (其中可能包含敏感的用户生成数据)。 超级用户可以查看所有表中的所有行。要使普通用户能够访问对超级客户可见的表，[GRANT](r_GRANT.md)请向普通用户授予对该表的 SELECT 权限。 ### 筛选系统生成的查询 与查询有关的系统表和视图（如 SVL\_QUERY\_SUMMARY、SVL\_QLOG 等）通常包含大量自动生成的语句，Amazon Redshift 使用这些语句监控数据库的状态。这些系统生成的查询对超级用户可见，但用处不大。从使用 `userid` 列的系统表或视图中进行选择时，如果要过滤掉它们，则可在 WHERE 子句中添加条件 `userid > 1`。例如： ``` select * from svl_query_summary where userid > 1 ``` ## 将仅预调配的查询迁移到 SYS 监控视图查询 ### 从预调配集群迁移到 Amazon Redshift Serverless 如果您要将预调配集群迁移到 Amazon Redshift Serverless，则您可能具有使用以下系统视图的查询，而这些视图仅存储预调配集群中的数据。 + 所有 STL 视图 + 所有 STV 视图 + 所有 SVCS 视图 + 所有 SVL 视图 + 部分 SVV 视图 + 有关 Amazon Redshift Serverless 中不支持的 SVV 视图的完整列表，请参阅《Amazon Redshift 管理指南》**中的[使用 Amazon Redshift Serverless 监控查询和工作负载](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-monitoring.html)底部的列表。 要继续使用查询，请将它们重新调整为使用在 SYS 监控视图中定义的列，这些列与仅预调配视图中的列相对应。要查看仅预调配视图和 SYS 监控视图之间的映射关系，请转至[用于迁移到 SYS 监控视图的系统视图映射](sys_view_migration.md) ### 停留在预调配集群上时更新查询 如果您不迁移到 Amazon Redshift Serverless，则可能仍需要更新现有查询。SYS 监控视图专为易于使用和降低复杂性而设计，并提供了一系列完整的指标来进行有效的监控和故障排除。使用 SYS 视图（如 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 和 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)），其中整合了多个仅预调配视图的信息，可以简化查询。 ## 使用 SYS 监控视图改进查询标识符跟踪 诸如 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 和 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 之类的 SYS 监控视图包含 query\_id 列，该列包含用户的查询标识符。同样，诸如 [STL\_QUERY](r_STL_QUERY.md) 和 [SVL\_QLOG](r_SVL_QLOG.md) 之类的仅预置视图包含查询列，该列还包含查询标识符。但是，SYS 系统视图中记录的查询标识符与仅预置视图中记录的查询标识符不同。 SYS 视图的 query\_id 列值与仅预置视图的查询列值之间的区别如下： + 在 SYS 视图中，query\_id 列以原始形式记录用户提交的查询。为了提高性能，Amazon Redshift 优化器可能会将它们分解为子查询，但您运行的单个查询在 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 中仍然只有一行。如果您想查看各个子查询，可以在 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 中找到它们。 + 在仅预置视图中，查询列记录子查询级别的查询。如果 Amazon Redshift 优化器将您的原始查询重写为多个子查询，则对于您运行的单个查询，[STL\_QUERY](r_STL_QUERY.md) 中将有多行具有不同的查询标识符值。 将监控和诊断查询从仅预置视图迁移到 SYS 视图时，请考虑这种差异并相应地编辑查询。有关 Amazon Redshift 如何处理查询的更多信息，请参阅[查询计划和执行工作流程](c-query-planning.md)。 ### 示例 有关 Amazon Redshift 在仅预调配视图和 SYS 监控视图中如何以不同的方式记录查询的示例，请参阅以下示例查询。这是按照在 Amazon Redshift 中运行的方式编写的查询。 ``` SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.l_suppkey AND o_orderkey = l1.l_orderkey AND o_orderstatus = 'F' AND l1.l_receiptdate > l1.l_commitdate AND EXISTS (SELECT * FROM lineitem l2 WHERE l2.l_orderkey = l1.l_orderkey AND l2.l_suppkey <> l1.l_suppkey ) AND NOT EXISTS (SELECT * FROM lineitem l3 WHERE l3.l_orderkey = l1.l_orderkey AND l3.l_suppkey <> l1.l_suppkey AND l3.l_receiptdate > l3.l_commitdate ) AND s_nationkey = n_nationkey AND n_name = 'UNITED STATES' GROUP BY s_name ORDER BY numwait DESC , s_name LIMIT 100; ``` 在后台，Amazon Redshift 查询优化器将上述用户提交的查询重写为 5 个子查询。 第一个子查询创建一个临时表来实现一个子查询。 ``` CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey , l_suppkey , s_name ) AS SELECT l1.l_orderkey , l1.l_suppkey , public.supplier.s_name FROM public.lineitem AS l1, public.nation, public.orders, public.supplier WHERE l1.l_commitdate < l1.l_receiptdate AND l1.l_orderkey = public.orders.o_orderkey AND l1.l_suppkey = public.supplier.s_suppkey AND public.nation.n_name = 'UNITED STATES'::CHAR(8) AND public.nation.n_nationkey = public.supplier.s_nationkey AND public.orders.o_orderstatus = 'F'::CHAR(1); ``` 第二个子查询从临时表中收集统计数据。 ``` padb_fetch_sample: select count(*) from volt_tt_606590308b512; ``` 第三个子查询创建另一个临时表来实现另一个子查询，引用上面创建的临时表。 ``` CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey , l_suppkey) AS (SELECT volt_tt_606590308b512.l_orderkey , volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l2, volt_tt_606590308b512 WHERE l2.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l2.l_orderkey = volt_tt_606590308b512.l_orderkey) EXCEPT distinct (SELECT volt_tt_606590308b512.l_orderkey, volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l3, volt_tt_606590308b512 WHERE l3.l_commitdate < l3.l_receiptdate AND l3.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l3.l_orderkey = volt_tt_606590308b512.l_orderkey); ``` 第四个子查询再次收集临时表的统计数据。 ``` padb_fetch_sample: select count(*) from volt_tt_606590308c2ef ``` 最后一个子查询使用上面创建的临时表生成输出。 ``` SELECT volt_tt_606590308b512.s_name AS s_name , COUNT(*) AS numwait FROM volt_tt_606590308b512, volt_tt_606590308c2ef WHERE volt_tt_606590308b512.l_orderkey = volt_tt_606590308c2ef.l_orderkey AND volt_tt_606590308b512.l_suppkey = volt_tt_606590308c2ef.l_suppkey GROUP BY 1 ORDER BY 2 DESC , 1 ASC LIMIT 100; ``` 在仅预置系统视图 STL\_QUERY 中，Amazon Redshift 在子查询级别记录了五行，如下所示： ``` SELECT userid, xid, pid, query, querytxt::varchar(100); FROM stl_query WHERE xid = 48237350 ORDER BY xid, starttime; userid | xid | pid | query | querytxt --------+----------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058151 | CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey, l_suppkey, s_name) AS SELECT l1.l_orderkey, l1.l 101 | 48237350 | 1073840810 | 12058152 | padb_fetch_sample: select count(*) from volt_tt_606590308b512 101 | 48237350 | 1073840810 | 12058156 | CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey, l_suppkey) AS (SELECT volt_tt_606590308b512.l_or 101 | 48237350 | 1073840810 | 12058168 | padb_fetch_sample: select count(*) from volt_tt_606590308c2ef 101 | 48237350 | 1073840810 | 12058170 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1. (5 rows) ``` 在 SYS 监控视图 SYS\_QUERY\_HISTORY 中，Amazon Redshift 按如下方式记录查询： ``` SELECT user_id, transaction_id, session_id, query_id, query_text::varchar(100) FROM sys_query_history WHERE transaction_id = 48237350 ORDER BY start_time; user_id | transaction_id | session_id | query_id | query_text ---------+----------------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058149 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1. ``` 在 SYS\_QUERY\_DETAIL 中，可以使用来自 SYS\_QUERY\_HISTORY 的 query\_id 值查找子查询级详细信息。child\_query\_sequence 列显示子查询的执行顺序。有关 SYS\_QUERY\_DETAIL 中各列的更多信息，请参阅 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)。 ``` select user_id, query_id, child_query_sequence, stream_id, segment_id, step_id, start_time, end_time, duration, blocks_read, blocks_write, local_read_io, remote_read_io, data_skewness, time_skewness, is_active, spilled_block_local_disk, spilled_block_remote_disk from sys_query_detail where query_id = 12058149 and step_id = -1 order by query_id, child_query_sequence, stream_id, segment_id, step_id; user_id | query_id | child_query_sequence | stream_id | segment_id | step_id | start_time | end_time | duration | blocks_read | blocks_write | local_read_io | remote_read_io | data_skewness | time_skewness | is_active | spilled_block_local_disk | spilled_block_remote_disk ---------+----------+----------------------+-----------+------------+---------+----------------------------+----------------------------+----------+-------------+--------------+---------------+----------------+---------------+---------------+-----------+--------------------------+--------------------------- 101 | 12058149 | 1 | 0 | 0 | -1 | 2023-09-27 15:40:38.512415 | 2023-09-27 15:40:38.533333 | 20918 | 0 | 0 | 0 | 0 | 0 | 44 | f | 0 | 0 101 | 12058149 | 1 | 1 | 1 | -1 | 2023-09-27 15:40:39.931437 | 2023-09-27 15:40:39.972826 | 41389 | 12 | 0 | 12 | 0 | 0 | 77 | f | 0 | 0 101 | 12058149 | 1 | 2 | 2 | -1 | 2023-09-27 15:40:40.584412 | 2023-09-27 15:40:40.613982 | 29570 | 32 | 0 | 32 | 0 | 0 | 25 | f | 0 | 0 101 | 12058149 | 1 | 2 | 3 | -1 | 2023-09-27 15:40:40.582038 | 2023-09-27 15:40:40.615758 | 33720 | 0 | 0 | 0 | 0 | 0 | 1 | f | 0 | 0 101 | 12058149 | 1 | 3 | 4 | -1 | 2023-09-27 15:40:46.668766 | 2023-09-27 15:40:46.705456 | 36690 | 24 | 0 | 15 | 0 | 0 | 17 | f | 0 | 0 101 | 12058149 | 1 | 4 | 5 | -1 | 2023-09-27 15:40:46.707209 | 2023-09-27 15:40:46.709176 | 1967 | 0 | 0 | 0 | 0 | 0 | 18 | f | 0 | 0 101 | 12058149 | 1 | 4 | 6 | -1 | 2023-09-27 15:40:46.70656 | 2023-09-27 15:40:46.71289 | 6330 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 1 | 5 | 7 | -1 | 2023-09-27 15:40:46.71405 | 2023-09-27 15:40:46.714343 | 293 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 2 | 0 | 0 | -1 | 2023-09-27 15:40:52.083907 | 2023-09-27 15:40:52.087854 | 3947 | 0 | 0 | 0 | 0 | 0 | 35 | f | 0 | 0 101 | 12058149 | 2 | 1 | 1 | -1 | 2023-09-27 15:40:52.089632 | 2023-09-27 15:40:52.091129 | 1497 | 0 | 0 | 0 | 0 | 0 | 11 | f | 0 | 0 101 | 12058149 | 2 | 1 | 2 | -1 | 2023-09-27 15:40:52.089008 | 2023-09-27 15:40:52.091306 | 2298 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 0 | 0 | -1 | 2023-09-27 15:40:56.882013 | 2023-09-27 15:40:56.897282 | 15269 | 0 | 0 | 0 | 0 | 0 | 29 | f | 0 | 0 101 | 12058149 | 3 | 1 | 1 | -1 | 2023-09-27 15:40:59.718554 | 2023-09-27 15:40:59.722789 | 4235 | 0 | 0 | 0 | 0 | 0 | 13 | f | 0 | 0 101 | 12058149 | 3 | 2 | 2 | -1 | 2023-09-27 15:40:59.800382 | 2023-09-27 15:40:59.807388 | 7006 | 0 | 0 | 0 | 0 | 0 | 58 | f | 0 | 0 101 | 12058149 | 3 | 3 | 3 | -1 | 2023-09-27 15:41:06.488685 | 2023-09-27 15:41:06.493825 | 5140 | 0 | 0 | 0 | 0 | 0 | 56 | f | 0 | 0 101 | 12058149 | 3 | 3 | 4 | -1 | 2023-09-27 15:41:06.486206 | 2023-09-27 15:41:06.497756 | 11550 | 0 | 0 | 0 | 0 | 0 | 2 | f | 0 | 0 101 | 12058149 | 3 | 4 | 5 | -1 | 2023-09-27 15:41:06.499201 | 2023-09-27 15:41:06.500851 | 1650 | 0 | 0 | 0 | 0 | 0 | 15 | f | 0 | 0 101 | 12058149 | 3 | 4 | 6 | -1 | 2023-09-27 15:41:06.498609 | 2023-09-27 15:41:06.500949 | 2340 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 5 | 7 | -1 | 2023-09-27 15:41:06.502945 | 2023-09-27 15:41:06.503282 | 337 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 4 | 0 | 0 | -1 | 2023-09-27 15:41:06.62899 | 2023-09-27 15:41:06.631452 | 2462 | 0 | 0 | 0 | 0 | 0 | 22 | f | 0 | 0 101 | 12058149 | 4 | 1 | 1 | -1 | 2023-09-27 15:41:06.632313 | 2023-09-27 15:41:06.63391 | 1597 | 0 | 0 | 0 | 0 | 0 | 20 | f | 0 | 0 101 | 12058149 | 4 | 1 | 2 | -1 | 2023-09-27 15:41:06.631726 | 2023-09-27 15:41:06.633813 | 2087 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 5 | 0 | 0 | -1 | 2023-09-27 15:41:12.571974 | 2023-09-27 15:41:12.584234 | 12260 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 0 | 1 | -1 | 2023-09-27 15:41:12.569815 | 2023-09-27 15:41:12.585391 | 15576 | 0 | 0 | 0 | 0 | 0 | 4 | f | 0 | 0 101 | 12058149 | 5 | 1 | 2 | -1 | 2023-09-27 15:41:13.758513 | 2023-09-27 15:41:13.76401 | 5497 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 1 | 3 | -1 | 2023-09-27 15:41:13.749 | 2023-09-27 15:41:13.772987 | 23987 | 0 | 0 | 0 | 0 | 0 | 32 | f | 0 | 0 101 | 12058149 | 5 | 2 | 4 | -1 | 2023-09-27 15:41:13.799526 | 2023-09-27 15:41:13.813506 | 13980 | 0 | 0 | 0 | 0 | 0 | 62 | f | 0 | 0 101 | 12058149 | 5 | 2 | 5 | -1 | 2023-09-27 15:41:13.798823 | 2023-09-27 15:41:13.813651 | 14828 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 (28 rows) ``` ## 系统表查询、进程和会话 ID 在对系统表中显示的查询、进程和会话 ID 进行分析时，请注意以下几点： + 查询 ID 值（在 `query_id` 和 `query` 等列中）可在以后重复使用。 + 进程 ID 值或会话 ID 值（在 `process_id`、`pid` 和 `session_id` 等列中）可在以后重复使用。 + 事务 ID 值（在 `transaction_id` 和 `xid` 等列中）是唯一的。