在日常數(shù)據(jù)庫運維中，“掃表風暴”數(shù)次悄然而至——某條未走索引的SQL突然執(zhí)行全表掃描，短短幾分鐘內吃光IO、拖高CPU，最終引發(fā)集群抖動甚至服務不可用。這樣的事故，你是否也曾經歷過？

全表掃描（Full Table Scan）是數(shù)據(jù)庫查詢中常見的性能殺手，尤其在數(shù)據(jù)量巨大的生產環(huán)境中，一條效率低下的SQL就足以引發(fā)連鎖性的系統(tǒng)故障。為從根本上防范此類風險，百度智能云數(shù)據(jù)庫在MySQL內核層面設計并實現(xiàn)了一套全表掃描動態(tài)管控機制，實現(xiàn)對低效SQL的實時檢測、靈活攔截與預警記錄，將運維控制權真正交到開發(fā)者以及DBA手中。

策略機制：雙模式切換、智能管控掃描行為

百度智能云數(shù)據(jù)庫通常提供如下兩種策略，可通過會話級變量動態(tài)切換，例如：

攔截模式：主動阻斷全表掃描類SQL，直接報錯，避免其執(zhí)行，防患于未然；

告警模式：放行執(zhí)行但記錄詳細日志，用于監(jiān)控、分析或審計，做到有跡可循。

用戶可根據(jù)業(yè)務時段、環(huán)境類型或運維策略，隨時開關相應模式，兼顧開發(fā)靈活性與生產安全性。

核心設計：變量控制+白名單機制

通常產品會引入兩個系統(tǒng)變量，用于控制全表掃描行為：

gaia_prevent_full_table_scans（默認 OFF）：一旦開啟，MySQL將在優(yōu)化階段識別全表掃描操作并直接拋出錯誤ER_TABLE_FULL_SCAN，同時中斷查詢。

gaia_full_table_scans_alarm_allowed（默認 ON）：開啟后雖不攔截執(zhí)行，但會向日志中寫入警告信息，說明發(fā)生全表掃描的SQL文本，輔助后續(xù)優(yōu)化。

為保障系統(tǒng)內部查詢不受干擾，產品內置了對系統(tǒng)庫（如mysql、sys、information_schema等）的白名單支持。

實現(xiàn)原理：深度鉤入查詢執(zhí)行流程

此項能力并非通過外圍腳本或中間件實現(xiàn)，而是以內核補丁的方式深度集成在 MySQL 查詢執(zhí)行流程中，例如在Query_expression::execute（）階段新增掃描檢查邏輯，優(yōu)化完成后檢查執(zhí)行計劃調用check_full_table_scan（）判斷當前 SQL 是否包含全表掃描。

其中攔截邏輯是這樣的：

如果gaia_prevent_full_table_scans=ON且存在全表掃描：

拋出ER_TABLE_FULL_SCAN錯誤；

中斷執(zhí)行

告警邏輯則是這樣的：

如果gaia_full_table_scans_alarm_allowed=ON且存在全表掃描：

在日志打印WARNING信息，記錄 SQL；

增加計數(shù)器table_full_scan_count。

正常執(zhí)行的情況如下，如果未命中限制條件則正常走執(zhí)行ExecuteIteratorQuery（thd）。

在check_full_table_scan（）中：

遍歷JOIN的qep_tab執(zhí)行計劃；

判斷qep_tab->type（）是否為JT_ALL（全表掃描）；

若表屬于白名單數(shù)據(jù)庫，則跳過檢查；

其他情況則標記 has_full_table_scan=true。

偽代碼示例：

switch （qep_tab->type（）） {

case JT_ALL:

if （非系統(tǒng)數(shù)據(jù)庫） {

has_full_table_scan = true；

break；

default:

// 非全表掃描

has_full_table_scan = false；

使用示例：明快的控制體驗

開啟攔截模式，如下：

// 將攔截模式開關打開。

SET SESSION gaia_prevent_full_table_scans =ON；

// 查詢一個全表掃描的語句。

SELECT * FROM t1；

// 查詢會被攔截，并且報錯。

--ERROR 12345 （HY000）: There is a full table scan in sql. You can modify gaia_prevent_full_table_scans to turn off the restriction

啟用告警模式，如下：

// 關閉攔截模式，并且打開報警開關。

SET SESSION gaia_prevent_full_table_scans = OFF；

SET SESSION gaia_full_table_scans_alarm_allowed =ON；

// 查詢一個全表掃描的語句。

SELECT*FROM t1；

// 查詢可以正常執(zhí)行，但是會在日志中，打印涉及全表掃描的sql。

--SQL正常執(zhí)行--日志打印: WARNING [Full table scan sql : SELECT * FROM t1；]

測試表現(xiàn)：精準識別、穩(wěn)定可控

我們對該機制進行了多場景驗證，分別是：

正常索引查詢暢通無阻；全表掃描在攔截模式下準確中斷。

設置 gaia_prevent_full_table_scans=ON，執(zhí)行全表掃描 SQL，確認報錯；

設置 gaia_full_table_scans_alarm_allowed=ON，確認日志輸出但 SQL 可執(zhí)行。

系統(tǒng)庫查詢不受影響。

在 mysql 數(shù)據(jù)庫執(zhí)行 SELECT * FROM user；，確認不會報錯。

雙變量沖突時以攔截為優(yōu)先策略，避免安全漏洞。

兩個變量都OFF時，全表掃描允許執(zhí)行且不告警；

兩個變量都ON時，以prevent優(yōu)先。

總結：運維新利器、性能守護者

這套全表掃描限制機制雖在實現(xiàn)上簡潔高效，卻可為數(shù)據(jù)庫系統(tǒng)帶來立竿見影的收益：

事前預防：攔截模式將風險查詢拒之門外，保障生產環(huán)境穩(wěn)定；

事中可見：告警模式記錄低效SQL，便于跟蹤與優(yōu)化；

靈活調度：動態(tài)開關策略，適配不同業(yè)務時段與環(huán)境類型；

無縫集成：內核級實現(xiàn)，無需修改業(yè)務SQL，零侵入。

對于具備中大規(guī)模MySQL集群的企業(yè)來說，這類細粒度、內核級的管控工具，無疑是提升數(shù)據(jù)庫可靠性與運維效率的關鍵一步。

責任編輯：張薇