Amazon Redshift unterstützt die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zum Ende der Lebensdauer von Python und zu den Migrationsoptionen finden Sie im [ Blogbeitrag](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/), der am 30. Juni 2025 veröffentlicht wurde. Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # SYS\_QUERY\_HISTORY Verwenden Sie SYS\_QUERY\_HISTORY, um Details zu Benutzerabfragen anzuzeigen. Jede Zeile stellt eine Benutzerabfrage mit akkumulierten Statistiken für einige der Felder dar. Diese Ansicht enthält viele Arten von Abfragen, wie Data Definition Language (DDL), Data Manipulation Language (DML), Kopieren, Entladen und Amazon Redshift Spectrum. Sie enthält sowohl ausgeführte als auch abgeschlossene Abfragen. SYS\_QUERY\_HISTORY ist für alle Benutzer sichtbar. Superuser können alle Zeilen sehen; reguläre Benutzer können nur ihre eigenen Daten sehen. Weitere Informationen finden Sie unter [Sichtbarkeit der Daten in Systemtabellen und Ansichten](cm_chap_system-tables.md#c_visibility-of-data). **Anmerkung** Um zu überprüfen, ob eine Transaktion, die die ausgeführte Abfrage enthält, erfolgreich festgeschrieben wurde, müssen Sie einen Join-Vorgang zwischen Systemtabellen und der `sys_transaction_history`-Tabelle ausführen. Beispiel: ``` SELECT qh.transaction_id, qh.query_id, qh.status AS query_status, qh.query_type, TRIM(qh.query_text) AS query_text, th.status AS transaction_status FROM sys_query_history qh LEFT JOIN sys_transaction_history th ON qh.transaction_id = th.transaction_id; ``` ## Tabellenspalten | Spaltenname | Datentyp | Beschreibung | | --- | --- | --- | | user\_id | integer | Die ID des Benutzers, der die Abfrage gesendet hat. | | query\_id | bigint | Die Abfrage-ID. | | query\_label | Zeichen (320) | Der Kurzname für die Abfrage. | | transaction\_id | bigint | Die Transaktions-ID. | | session\_id | integer | Die ID des Prozesses, der die Abfrage ausführt. | | database\_name | character(128) | Der Name der Datenbank, mit der der Benutzer verbunden war, als die Abfrage ausgegeben wurde. | | query\_type | character(32) | Die Art der Abfrage, wie SELECT, INSERT, UPDATE, UNLOAD COPY, COMMAND, DDL, UTILITY, CTAS und OTHER. | | Status | character(10) | Der Status der Abfrage. Gültige Werte: planning (Planung), queued (In Warteschlange), running (In Ausführung), returning (Wird zurückgegeben), failed (Fehlgeschlagen), canceled (Abgebrochen) und success (Erfolgreich). | | result\_cache\_hit | Boolesch | Gibt an, ob die Abfrage mit dem Ergebnis-Cache übereinstimmt. | | start\_time | timestamp | Der Zeitpunkt, zu dem die Abfrage begann. | | end\_time | timestamp | Der Zeitpunkt, an dem die Abfrage abgeschlossen wurde. | | elapsed\_time | bigint | Die gesamte Zeit (Mikrosekunden), die für die Abfrage aufgewendet wurde. | | queue\_time | bigint | Die Gesamtzeit (Mikrosekunden), die für die Abfragewarteschlange der Serviceklasse aufgewendet wurde. | | execution\_time | bigint | Die Gesamtdauer (Mikrosekunden) der Ausführung in der Serviceklasse. | | error\_message | character(512) | Der Grund, warum eine Abfrage fehlgeschlagen ist. | | returned\_rows | bigint | Die Anzahl der von der Abfrage zurückgegebenen Zeilen. | | returned\_bytes | bigint | Die Anzahl der von der Abfrage zurückgegebenen Bytes. | | query\_text | character(4000) | Die Abfragezeichenfolge. Diese Zeichenfolge wird möglicherweise abgeschnitten. | | redshift\_version | character(256) | Die Amazon-Redshift-Version, als die Abfrage ausgeführt wurde. | | usage\_limit | character(150) | Liste der von der Abfrage erreichten Nutzungslimit-IDs. | | compute\_type | varchar(32) | Gibt an, ob die Abfrage auf dem Haupt-Cluster oder einem Nebenläufigkeitsskalierungs-Cluster ausgeführt wird. Mögliche Werte sind primary (Abfrage wird auf dem Haupt-Cluster ausgeführt), secondary (Abfrage wird auf dem sekundären Cluster ausgeführt) oder primary-scale (Abfrage wird auf dem Parallelitäts-Cluster ausgeführt). Dies gilt nur für bereitgestellte Cluster. | | compile\_time | bigint | Die Gesamtzeit (Mikrosekunden), die für die Kompilierung der Abfrage aufgewendet wurde. | | planning\_time | bigint | Die Gesamtzeit (Mikrosekunden), die für die Planung der Abfrage aufgewendet wurde. | | lock\_wait\_time | bigint | Die Gesamtzeit (Mikrosekunden), die für das Warten auf die Sperrbeziehung aufgewendet wurde. | | service\_class\_id | Ganzzahl | Die ID der Serviceklasse. Eine Liste von Serviceklassen-IDs finden Sie unter [WLM-Serviceklassen-IDs](cm-c-wlm-system-tables-and-views.md#wlm-service-class-ids).
Diese Spalte wird nur für Abfragen verwendet, die auf bereitgestellten Clustern ausgeführt werden. Für Abfragen, die auf Redshift Serverless ausgeführt werden, enthält diese Spalte -1. | | service\_class\_name | character(64) | Der Name der Serviceklasse.
Diese Spalte wird nur für Abfragen verwendet, die auf bereitgestellten Clustern ausgeführt werden. Für Abfragen, die auf Amazon Redshift Serverless ausgeführt werden, ist diese Spalte leer. | | query\_priority | character(20) | Die Priorität der Warteschlange, in der die Abfrage ausgeführt wurde. Die möglichen Werte lauten wie folgt:+ NULL
+ Am niedrigsten
+ low
+ normal
+ high
+ Am höchsten
NULL bedeutet, dass die Abfragepriorität für die Abfrage nicht unterstützt wird.
Diese Spalte wird nur für Abfragen verwendet, die auf bereitgestellten Clustern ausgeführt werden. Bei Abfragen, die auf Redshift Serverless ausgeführt werden, ist diese Spalte leer. | | short\_query\_accelerated | character(10) | Ob die Abfrage mit Short Query Acceleration (SQA) beschleunigt wurde. Die möglichen Werte lauten wie folgt:+ true
+ false
+ NULL
Diese Spalte wird nur für Abfragen verwendet, die auf bereitgestellten Clustern ausgeführt werden. Bei Abfragen, die auf Redshift Serverless ausgeführt werden, ist diese Spalte leer. | | user\_query\_hash | character(40) | Der aus der Abfrage generierte Abfrage-Hash, einschließlich der Abfrageliterale. Wiederholte Abfragen mit demselben Abfragetext haben dieselben user\_query\_hash-Werte. | | generic\_query\_hash | character(40) | Der aus der Abfrage generierte Abfrage-Hash, mit Ausnahme der Abfrageliterale. Wiederholte Abfragen mit demselben Abfragetext, aber unterschiedlichen Abfrageliteralen haben dieselben generic\_query\_hash-Werte. | | query\_hash\_version | Ganzzahl | Die Versionsnummer für den aus der Abfrage generierten Abfrage-Hash. | | result\_cache\_query\_id | Ganzzahl | Wenn für die Abfrage Ergebniszwischenspeicherung verwendet wird, ist dieser Feldwert die Abfrage-ID der Abfrage, anhand derer die zwischengespeicherten Ergebnisse erstellt wurden. Wenn keine Ergebniszwischenspeicherung verwendet wird, ist dieser Feldwert `0`. | | username | character(128) | Die ID des Benutzers, der die Abfrage übermittelt hat. | | query\_uuid | character(36) | Ein global eindeutiger Bezeichner (UUID) der Abfrage. | ## Beispielabfragen Die folgende Abfrage gibt laufende und in der Warteschlange stehende Abfragen zurück. ``` SELECT user_id, query_id, transaction_id, session_id, status, trim(database_name) AS database_name, start_time, end_time, result_cache_hit, elapsed_time, queue_time, execution_time FROM sys_query_history WHERE status IN ('running','queued') ORDER BY start_time; ``` Beispielausgabe. ``` user_id | query_id | transaction_id | session_id | status | database_name | start_time | end_time | result_cache_hit | elapsed_time | queue_time | execution_time ---------+----------+----------------+------------+---------+---------------+---------------------------+----------------------------+------------------+--------------+------------+---------------- 101 | 760705 | 852337 | 1073832321 | running | tpcds_1t | 2022-02-15 19:03:19.67849 | 2022-02-15 19:03:19.739811 | f | 61321 | 0 | 0 ``` Die folgende Abfrage gibt Startzeit, Endzeit, Warteschlangenzeit, verstrichene Zeit, Planungszeit und andere Metadaten für eine bestimmte Abfrage zurück. ``` SELECT user_id, query_id, transaction_id, session_id, status, trim(database_name) AS database_name, start_time, end_time, result_cache_hit, elapsed_time, queue_time, execution_time, planning_time, trim(query_text) as query_text FROM sys_query_history WHERE query_id = 3093; ``` Beispielausgabe. ``` user_id | query_id | transaction_id | session_id | status | database_name | start_time | end_time | result_cache_hit | elapsed_time | queue_time | execution_time | planning_time | query_text --------+----------+----------------+------------+------------+---------------+----------------------------+----------------------------+------------------+--------------+------------+----------------+---------------+------------------------------------- 106 | 3093 | 11759 | 1073750146 | success | dev | 2023-03-16 16:53:17.840214 | 2023-03-16 16:53:18.106588 | f | 266374 | 0 | 105725 | 136589 | select count(*) from item; ``` Die folgende Abfrage listet die 10 neuesten SELECT-Abfragen auf. ``` SELECT query_id, transaction_id, session_id, start_time, elapsed_time, queue_time, execution_time, returned_rows, returned_bytes FROM sys_query_history WHERE query_type = 'SELECT' ORDER BY start_time DESC limit 10; ``` Beispielausgabe. ``` query_id | transaction_id | session_id | start_time | elapsed_time | queue_time | execution_time | returned_rows | returned_bytes ----------+----------------+------------+----------------------------+--------------+------------+----------------+---------------+---------------- 526532 | 61093 | 1073840313 | 2022-02-09 04:43:24.149603 | 520571 | 0 | 481293 | 1 | 3794 526520 | 60850 | 1073840313 | 2022-02-09 04:38:27.24875 | 635957 | 0 | 596601 | 1 | 3679 526508 | 60803 | 1073840313 | 2022-02-09 04:37:51.118835 | 563882 | 0 | 503135 | 5 | 17216 526505 | 60763 | 1073840313 | 2022-02-09 04:36:48.636224 | 649337 | 0 | 589823 | 1 | 652 526478 | 60730 | 1073840313 | 2022-02-09 04:36:11.741471 | 14611321 | 0 | 14544058 | 0 | 0 526467 | 60636 | 1073840313 | 2022-02-09 04:34:11.91463 | 16711367 | 0 | 16633767 | 1 | 575 511617 | 617946 | 1074009948 | 2022-01-20 06:21:54.44481 | 9937090 | 0 | 9899271 | 100 | 12500 511603 | 617941 | 1074259415 | 2022-01-20 06:21:45.71744 | 8065081 | 0 | 7582500 | 100 | 8889 511595 | 617935 | 1074128320 | 2022-01-20 06:21:44.030876 | 1051270 | 0 | 1014879 | 1 | 72 511584 | 617931 | 1074030019 | 2022-01-20 06:21:42.764088 | 609033 | 0 | 485887 | 100 | 8438 ``` Die folgende Abfrage zeigt die tägliche Anzahl ausgewählter Abfragen und die durchschnittlich verstrichene Abfragezeit. ``` SELECT date_trunc('day',start_time) AS exec_day, status, COUNT(*) AS query_cnt, AVG(datediff (microsecond,start_time,end_time)) AS elapsed_avg FROM sys_query_history WHERE query_type = 'SELECT' AND start_time >= '2022-01-14' AND start_time <= '2022-01-18' GROUP BY exec_day, status ORDER BY exec_day, status; ``` Beispielausgabe. ``` exec_day | status | query_cnt | elapsed_avg ---------------------+---------+-----------+------------ 2022-01-14 00:00:00 | success | 5253 | 56608048 2022-01-15 00:00:00 | success | 7004 | 56995017 2022-01-16 00:00:00 | success | 5253 | 57016363 2022-01-17 00:00:00 | success | 5309 | 55236784 2022-01-18 00:00:00 | success | 8092 | 54355124 ``` Die folgende Abfrage zeigt die Leistung der täglich verstrichenen Abfragezeit. ``` SELECT distinct date_trunc('day',start_time) AS exec_day, query_count.cnt AS query_count, Percentile_cont(0.5) within group(ORDER BY elapsed_time) OVER (PARTITION BY exec_day) AS P50_runtime, Percentile_cont(0.8) within group(ORDER BY elapsed_time) OVER (PARTITION BY exec_day) AS P80_runtime, Percentile_cont(0.9) within group(ORDER BY elapsed_time) OVER (PARTITION BY exec_day) AS P90_runtime, Percentile_cont(0.99) within group(ORDER BY elapsed_time) OVER (PARTITION BY exec_day) AS P99_runtime, Percentile_cont(1.0) within group(ORDER BY elapsed_time) OVER (PARTITION BY exec_day) AS max_runtime FROM sys_query_history LEFT JOIN (SELECT date_trunc('day',start_time) AS day, count(*) cnt FROM sys_query_history WHERE query_type = 'SELECT' GROUP by 1) query_count ON date_trunc('day',start_time) = query_count.day WHERE query_type = 'SELECT' ORDER BY exec_day; ``` Beispielausgabe. ``` exec_day | query_count | p50_runtime | p80_runtime | p90_runtime | p99_runtime | max_runtime ---------------------+-------------+-------------+-------------+-------------+--------------+-------------- 2022-01-14 00:00:00 | 5253 | 16816922.0 | 69525096.0 | 158524917.8 | 486322477.52 | 1582078873.0 2022-01-15 00:00:00 | 7004 | 15896130.5 | 71058707.0 | 164314568.9 | 500331542.07 | 1696344792.0 2022-01-16 00:00:00 | 5253 | 15750451.0 | 72037082.2 | 159513733.4 | 480372059.24 | 1594793766.0 2022-01-17 00:00:00 | 5309 | 15394513.0 | 68881393.2 | 160254700.0 | 493372245.84 | 1521758640.0 2022-01-18 00:00:00 | 8092 | 15575286.5 | 68485955.4 | 154559572.5 | 463552685.39 | 1542783444.0 2022-01-19 00:00:00 | 5860 | 16648747.0 | 72470482.6 | 166485138.2 | 492038228.67 | 1693483241.0 2022-01-20 00:00:00 | 1751 | 15422072.0 | 69686381.0 | 162315385.0 | 497066615.00 | 1439319739.0 2022-02-09 00:00:00 | 13 | 6382812.0 | 17616161.6 | 21197988.4 | 23021343.84 | 23168439.0 ``` Die folgende Abfrage zeigt die Abfragetypverteilung. ``` SELECT query_type, COUNT(*) AS query_count FROM sys_query_history GROUP BY query_type ORDER BY query_count DESC; ``` Beispielausgabe. ``` query_type | query_count ------------+------------- UTILITY | 134486 SELECT | 38537 DDL | 4832 OTHER | 768 LOAD | 768 CTAS | 748 COMMAND | 92 ``` Im folgenden Beispiel werden die Unterschiede der Abfrage-Hash-Ergebnisse zwischen mehreren Abfragen dargestellt. Beachten Sie die folgenden Abfragen: ``` CREATE TABLE test_table (col1 INT); INSERT INTO test_table VALUES (1),(2); SELECT * FROM test_table; SELECT * FROM test_table; SELECT col1 FROM test_table; SELECT * FROM test_table WHERE col1=1; SELECT * FROM test_table WHERE col1=2; SELECT query_id, TRIM(user_query_hash) AS user_query_hash, TRIM(generic_query_hash) AS generic_query_hash, TRIM(query_text) AS text FROM sys_query_history ORDER BY start_time DESC LIMIT 10; ``` Dies ist eine Beispielausgabe. ``` query_id | user_query_hash | generic_query_hash | text ---------+-----------------+--------------------+---------- 24723049 | oPuFtjEPLTs= | oPuFtjEPLTs= | select query_id, trim(user_query_hash) as user_query_hash, trim(generic_query_hash) as generic_query_hash, query_hash_version, trim(query_text) as text from sys_query_history order by start_time\r\ndesc limit 20 24723045 | Gw2Kwdd8m2I= | IwfRu8/XAKI= | select * from test_table where col1=2 limit 100 24723041 | LNw2vx0GDXo= | IwfRu8/XAKI= | select * from test_table where col1=1 limit 100 24723036 | H+qep/c82Y8= | H+qep/c82Y8= | select col1 from test_table limit 100 24723033 | H+qep/c82Y8= | H+qep/c82Y8= | select * from test_table limit 100 24723029 | H+qep/c82Y8= | H+qep/c82Y8= | select * from test_table limit 100 24723023 | 50sirx9E1hU= | uO36Z1a/QYs= | insert into test_table values (1),(2) 24723021 | YSVnlivZHeo= | YSVnlivZHeo= | create table test_table (col1 int) ``` `SELECT * FROM test_table;` und `SELECT col1 FROM test_table;` haben denselben user\_query\_hash-Wert, da test\_table nur eine Spalte hat. `SELECT * FROM test_table WHERE col1=1;` und `SELECT * FROM test_table WHERE col1=2;` haben unterschiedliche user\_query\_hash-Werte, aber identische generic\_query\_hash-Werte, da die beiden Abfragen außerhalb der Abfrageliterale 1 und 2 identisch sind.