MySQL无禁止全表扫描开关，需权限控制（列级授权）、代理层拦截（ProxySQL规则）和应用层兜底（ORM校验WHERE）三者结合，缺一不可。
MySQL本身没有“禁止全表扫描”的开关，也不能直接拦截 SELECT 语句是否走索引。所谓“禁止全表扫描”，本质是**阻止用户执行不带有效 WHERE 条件、或明显会触发 type=ALL 的查询**——这只能靠权限控制 + 应用层约束 + 运行时监控三者结合，缺一不可。
限制用户 SELECT 权限粒度到字段级
MySQL 8.0+ 支持列级权限（SELECT(col1, col2)），但不支持“禁止 SELECT *”这种语义。真正能落地的做法是：只授予用户访问必要字段的权限，同时拒绝 SELECT 全表权限。
- 先回收该用户的全局
SELECT权限：REVOKE SELECT ON db.table FROM 'user'@'%'; - 再按需授权具体字段：
GRANT SELECT(id, name, status) ON db.table TO 'user'@'%'; - 注意：如果应用代码里写了
SELECT *，此时会报错ERROR 1142 (42000): SELECT command denied to user，强制开发者显式列出字段 - 该方式对 ORM 自动生成
SELECT *的场景特别有效，但无法防住已授权字段上的WHERE 1或WHERE id > 0类无过滤查询
用 SQL Firewall 或代理层拦截高风险查询
MySQL 官方企业版提供 SQL Firewall，社区版可用 ProxySQL 或 MaxScale 在代理层做规则匹配。这是目前最接近“禁止全表扫描”的实操方案。
- 在 ProxySQL 中配置
mysql_query_rules，匹配SELECT且不含WHERE、LIMIT或明确使用索引提示的语句： match_pattern = '^SELECT[[:space:]]+\*[^[:alnum:]]+FROM[[:space:]]+[a-zA-Z0-9_]+[[:space:]]*;?$'- 动作设为
OK→block或重写为带LIMIT 1000的语句 - 注意：正则不能覆盖所有情况（如换行、别名、子查询），需配合
digest指纹持续优化规则 - 该层拦截对 DBA 可见、可审计，但增加了架构复杂度，且无法阻止用户绕过代理直连
强制要求 WHERE 条件 + 索引检查（应用层兜底）
数据库层做不到的事，必须由应用框架承担。尤其在 ORM 场景下，这是最可控的一环。
- Spring Data JPA 可自定义
JpaRepository实现，在findAll()方法里抛出异常：throw new UnsupportedOperationException("findAll() is disabled in production"); - MyBatis Plus 提供
ISqlInjector，可重写selectList方法，检查Wrapper是否为空或仅含last()等无过滤条件 - 关键点：这类校验必须在生产环境
spring.profiles.active=prod下强制开启，开发环境可关闭 - 容易被忽略的是 JOIN 查询——即使主表有 WHERE，若关联表没 ON 条件或条件未命中索引，仍可能触发被关联表的全表扫描；需在 DAO 层统一检查执行计划（如调用
EXPLAIN并解析type=ALL）
真正难的不是技术方案，而是让所有查询路径都经过同一道校验：直连 MySQL 的脚本、定时任务、管理后台、甚至 DBA 自己跑的诊断语句。只要有一处绕过，就等于没禁住。所以最终防线其实是人——把 EXPLAIN 检查纳入上线 checklist，比任何自动机制都可靠。
