在日常数据库运维中，“扫表风暴”数次悄然而至——某条未走索引的SQL突然执行全表扫描，短短几分钟内吃光IO、拖高CPU，最终引发集群抖动甚至服务不可用。这样的事故，你是否也曾经历过？
全表扫描（Full Table Scan）是数据库查询中常见的性能杀手，尤其在数据量巨大的生产环境中，一条效率低下的SQL就足以引发连锁性的系统故障。为从根本上防范此类风险，百度智能云数据库在MySQL内核层面设计并实现了一套全表扫描动态管控机制，实现对低效SQL的实时检测、灵活拦截与预警记录，将运维控制权真正交到开发者以及DBA手中。
策略机制：双模式切换、智能管控扫描行为
百度智能云数据库通常提供如下两种策略，可通过会话级变量动态切换，例如：
拦截模式：主动阻断全表扫描类SQL，直接报错，避免其执行，防患于未然；
告警模式：放行执行但记录详细日志，用于监控、分析或审计，做到有迹可循。
用户可根据业务时段、环境类型或运维策略，随时开关相应模式，兼顾开发灵活性与生产安全性。
核心设计：变量控制+白名单机制
通常产品会引入两个系统变量，用于控制全表扫描行为：
gaia_prevent_full_table_scans（默认 OFF）：一旦开启，MySQL将在优化阶段识别全表扫描操作并直接抛出错误ER_TABLE_FULL_SCAN，同时中断查询。
gaia_full_table_scans_alarm_allowed（默认 ON）：开启后虽不拦截执行，但会向日志中写入警告信息，说明发生全表扫描的SQL文本，辅助后续优化。
为保障系统内部查询不受干扰，产品内置了对系统库（如mysql、sys、information_schema等）的白名单支持。
实现原理：深度钩入查询执行流程
此项能力并非通过外围脚本或中间件实现，而是以内核补丁的方式深度集成在 MySQL 查询执行流程中，例如在Query_expression::execute()阶段新增扫描检查逻辑，优化完成后检查执行计划调用check_full_table_scan()判断当前 SQL 是否包含全表扫描。
其中拦截逻辑是这样的：
如果gaia_prevent_full_table_scans=ON且存在全表扫描：
抛出ER_TABLE_FULL_SCAN错误；
中断执行
告警逻辑则是这样的：
如果gaia_full_table_scans_alarm_allowed=ON且存在全表扫描：
在日志打印WARNING信息，记录 SQL；
增加计数器table_full_scan_count。
正常执行的情况如下，如果未命中限制条件则正常走执行ExecuteIteratorQuery(thd)。
在check_full_table_scan()中：
遍历 JOIN 的qep_tab执行计划；
判断qep_tab->type()是否为JT_ALL（全表扫描）；
若表属于白名单数据库，则跳过检查；
其他情况则标记 has_full_table_scan=true。
伪代码示例：
switch (qep_tab->type()) {
case JT_ALL:
if (非系统数据库) {
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;
// 查询可以正常执行，但是会在日志中，打印涉及全表扫描的sql。
-- SQL 正常执行-- 日志打印: WARNING [Full table scan sql : SELECT * FROM t1;]
测试表现：精准识别、稳定可控
我们对该机制进行了多场景验证，分别是：
正常索引查询畅通无阻；全表扫描在拦截模式下准确中断。
设置 gaia_prevent_full_table_scans=ON，执行全表扫描 SQL，确认报错；
设置 gaia_full_table_scans_alarm_allowed=ON，确认日志输出但 SQL 可执行。
系统库查询不受影响。
在 mysql 数据库执行 SELECT * FROM user;，确认不会报错。
双变量冲突时以拦截为优先策略，避免安全漏洞。
两个变量都 OFF 时，全表扫描允许执行且不告警；
两个变量都 ON 时，以 prevent 优先。
总结：运维新利器、性能守护者
这套全表扫描限制机制虽在实现上简洁高效，却可为数据库系统带来立竿见影的收益：
事前预防：拦截模式将风险查询拒之门外，保障生产环境稳定；
事中可见：告警模式记录低效 SQL，便于跟踪与优化；
灵活调度：动态开关策略，适配不同业务时段与环境类型；
无缝集成：内核级实现，无需修改业务 SQL，零侵入。
对于具备中大规模MySQL集群的企业来说，这类细粒度、内核级的管控工具，无疑是提升数据库可靠性与运维效率的关键一步。
