摘要：智能把控大數據量查詢，防患系統奔潰于未然

什么是最大讀取行

一直以來，大數據量查詢是數據庫 DBA 們調優的重點，DBA 們通常十八般武藝輪番上陣以期提升大數據查詢的性能：例如分庫分表、給表增加索引、設定合理的 WHERE 查詢條件、限定單次查詢的條數……

然而，DBA 再厲害，應用程序千千萬，寫代碼的程序員萬碼奔騰，大數據量的查詢像地雷，不定什么時候就爆了。比如隱藏在某段代碼里的查詢，因為一個新手程序員的經驗不足，查詢代碼寫得欠佳，沒有 WHERE 子句或缺少索引引發了不必要的多行讀取，甚至全表掃描，給服務器帶來了過度的壓力，導致業務執行緩慢，甚至最后服務器 OOM 崩潰。

為了避免這種“爆雷”，GaussDB(for MySQL)近期上線了最大讀取行特性。優化器產生執行計劃后，如果優化器預估的讀取行數超過了所設置的最大讀取行閾值，則自動中止查詢，將雷的導火索切斷。

這種機制的優點在于：執行計劃階段就對查詢進行了干預，而不是語句開始執行后在執行過程中進行中斷。既杜絕了劣質查詢對服務器和業務運行造成的風險，又大大節省了時間和資源。

如何設置最大讀取行

在 GaussDB(for MySQL)中，設置 rds_max_row_read，指定查詢允許讀取的最大行數。GaussDB(for MySQL)收到查詢指令，執行查詢之前，會對查詢要讀取的行數進行估計。當估值超過所設置的最大讀取行時，將中止查詢，即查詢沒有機會運行，提前規避不必要的資源消耗。

下面是一份測試數據，說明了開啟最大讀取行前后的差異。

假設表 t1 有 4M 大小的行，當開發人員或應用程序嘗試運行以下查詢時，運行需要 7 分鐘。

mysql> SELECT * FROM t1;

WHERE 子句的缺失致使需要全表掃描，查詢耗時長。對于更大的表，這類查詢將需要更多的耗時，使服務器消耗更多資源，查詢耗時甚至可能高達數小時。

最大讀取行特性的使用，可以節省寶貴的時間和資源。比如假設將最大讀取行數指定為 1000000：

mysql> set rds_max_row_read =1000000;

Query OK, 0 rows affected (0.00 sec)

修改后，重新運行不含 WHERE 子句的查詢，收到了讀取行超限的提示，查詢被停止。

mysql> SELECT * FROM t1;

ERROR HY000: Expected number of read rows exceeds the maximum allowed (see @@rds_max_row_read)

通過最大讀取行，相當于擁有了一個工具，DBA 或者軟件工程師根據業務情況可以自如設置和調整限制規則，保證業務正常運行的同時，限制次優查詢，避免性能異常。

適用范圍

適用于 SELECT、CREATE SELECT 和 INSERT SELECT。

功能開啟

默認情況下，該功能是禁用的，只有當 rds_max_row_read 設置了值時，該功能才會被激活。

為了功能的穩定，避免無心的錯誤設置對業務造成不必要的影響，rds_max_row_read 做了最低值限制，不允許用戶設置比最低值更低的值。

實現原理

GaussDB(for MySQL)通過遍歷每個查詢塊并聚合各查詢塊的貢獻來整體評估查詢的讀取行數：也就是對各 join 對象的讀取行數評估后累加。

如果在累加評估過程中的某一刻，估計值超過了所設置的限制，查詢將被終止。

對于關聯子查詢，評估辦法為：評估子查詢的讀取行數，然后乘以查詢被執行的次數。

需要特別說明的是，對每個 JOIN 對象的估計是執行計劃預估返回的行數，可能與真實執行返回的行數有偏差。這雖然是一個相對簡單的評估模型，但是我們堅信其具有足夠的魯棒性。

對于復雜查詢，GaussDB(for MySQL)還通過 optimizer trace 提供了更多信息以幫助您確定優化器做決策的原因及如何優化查詢。

示例

示例 1

mysql> EXPLAIN format=tree SELECT * FROM table_1, table_2;

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| EXPLAIN |

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

| -> Inner hash join (no condition) (cost=6.50 rows=54)

-> Table scan on table_1 (cost=0.19 rows=9)

-> Hash

-> Table scan on table_2 (cost=0.85 rows=6)

|

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)

mysql> SET rds_max_row_read =20;

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM table_1, table_2;

ERROR 1888 (HY000): The expected number of read rows exceeds the allowed maximum (see @@rds_max_row_read)

查詢讀取的行太多，我們嘗試在 optimizer trace 的幫助下尋找原因：

SET optimizer_trace="enabled=on";

SELECT * from table_1, table_2;

SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;

在 optimizer trace 中，可以找到：

{

"Max_row_read": {

"select#": 1,

"current_estimate_of_rows": 54,

"rows_contributed_by_this_query_block": 54

}

}

這表示此查詢中的唯一查詢塊，行讀取數為 54。

執行計劃中的這個評估有多準確呢？

執行如下查詢查看語句實際被執行的次數：

mysql> show status like "handler_read_rnd_next";

+----------------------------+-------+

| Variable_name | Value |

+----------------------------+-------+

| Handler_read_rnd_next | 17 |

+----------------------------+-------+

1 rows in set (0.00 sec)

handler_read_rnd_next 顯示實際上的讀取是 17 行，而不是 54 行。

這個 17 是怎么來的呢？

這是一個哈希連接：

-遍歷整張表時，左表有 9 行數據+1 行額外行。

-右表有 6 行+1 行額外行。

優化器中會預估返回讀取行，例如，54。在這個示例中，它并沒有很好地猜測到返回的行數，它高估了行讀取的數量。在大多數情況下，讀取行數的估計不夠精確，但可以肯定的是，它是足夠穩健的，能達到相應的目的。

示例 2

創建例表 t1：

mysql> CREATE TABLE t1(a INT);

在表中填充 1536 行數據后。將 rds_max_row_read 設置為 500，進行以下測試查詢：

mysql> SELECT * FROM t1 WHERE a>6;

ERROR HY000: Expected number of read rows exceeds the maximum allowed (see @@rds_max_row_read)

在 optimizer trac 的幫助下，可以看到優化器估計的讀取行數是 512 行，因此查詢被終止。如果在 a 字段上添加索引（這是一件明智的事情），同一查詢的估計讀取行數是 1，查詢檢測順利通過。

這個簡單的示例說明：最大讀取行能幫助您編寫更加優質的查詢語句。

結論

最大讀取行特性針對讀取過多行的查詢，識別和過濾出效率低下的查詢。用戶可以為讀取行數設置閾值，超過該閾值則終止查詢。為了識別此類查詢，GaussDB(for MySQL)在優化器中進行了讀取總行數的粗略估計。當查詢終止時，可以檢查 optimizer trace，從中收集線索，以幫助重寫更高效的查詢。

簡而言之，最大讀取行為用戶提供了一個工具，使他們可以更充分地利用手上的資源。

審核編輯 黃宇