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

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

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

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

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

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

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

核心設(shè)計(jì)：變量控制+白名單機(jī)制

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

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

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

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

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

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

其中攔截邏輯是這樣的：

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

拋出ER_TABLE_FULL_SCAN錯(cuò)誤；

中斷執(zhí)行

告警邏輯則是這樣的：

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

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

增加計(jì)數(shù)器table_full_scan_count。

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

在check_full_table_scan（）中：

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

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

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

其他情況則標(biāo)記 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；

使用示例：明快的控制體驗(yàn)

開啟攔截模式，如下：

// 將攔截模式開關(guān)打開。

SET SESSION gaia_prevent_full_table_scans =ON；

// 查詢一個(gè)全表掃描的語句。

SELECT * FROM t1；

// 查詢會(huì)被攔截，并且報(bào)錯(cuò)。

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

啟用告警模式，如下：

// 關(guān)閉攔截模式，并且打開報(bào)警開關(guān)。

SET SESSION gaia_prevent_full_table_scans = OFF；

SET SESSION gaia_full_table_scans_alarm_allowed =ON；

// 查詢一個(gè)全表掃描的語句。

SELECT*FROM t1；

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

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

測(cè)試表現(xiàn)：精準(zhǔn)識(shí)別、穩(wěn)定可控

我們對(duì)該機(jī)制進(jìn)行了多場(chǎng)景驗(yàn)證，分別是：

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

設(shè)置 gaia_prevent_full_table_scans=ON，執(zhí)行全表掃描 SQL，確認(rèn)報(bào)錯(cuò)；

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

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

在 mysql 數(shù)據(jù)庫執(zhí)行 SELECT * FROM user；，確認(rèn)不會(huì)報(bào)錯(cuò)。

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

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

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

總結(jié)：運(yùn)維新利器、性能守護(hù)者

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

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

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

靈活調(diào)度：動(dòng)態(tài)開關(guān)策略，適配不同業(yè)務(wù)時(shí)段與環(huán)境類型；

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

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

責(zé)任編輯：張薇