摘要：在日常数据库运维中，“扫表风暴”数次悄然而至——某条未走索引的 SQL 突然执行全表扫描，短短几分钟内吃光 IO、拖高 CPU，最终引发集群抖动甚至服务不可用。这样的事故，你是否也曾经历过？全表扫描（Full Table Scan）是数据库查询中常见的性能杀手
在日常数据库运维中，“扫表风暴”数次悄然而至——某条未走索引的 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)。在中：遍历 JOIN 的qep_tab执行计划；判断qep_tab->type是否为JT_ALL（全表扫描）；若表属于白名单数据库，则跳过检查；其他情况则标记 has_full_table_scan=true。伪代码示例：开启拦截模式，如下：启用告警模式，如下：我们对该机制进行了多场景验证，分别是：正常索引查询畅通无阻；全表扫描在拦截模式下准确中断。设置，执行全表扫描 SQL，确认报错；设置，确认日志输出但 SQL 可执行。系统库查询不受影响。在mysql数据库执行SELECT * FROM user;，确认不会报错。双变量冲突时以拦截为优先策略，避免安全漏洞。两个变量都OFF时，全表扫描允许执行且不告警；两个变量都ON时，以prevent优先。对于具备中大规模 MySQL 集群的企业来说，这类细粒度、内核级的管控工具，无疑是提升数据库可靠性与运维效率的关键一步。
来源：晓加论科技