第2章：查询受限的基本概念

这一章咱们来聊聊最核心的问题——到底什么是查询受限？

很多 DBA 一听到“权限控制”，第一反应就是 GRANT 和 REVOKE。嗯，这没错，但只是冰山一角。我做了这么多年数据安全，见过太多把“权限管理”等同于“用户授权”的项目。可实际上，真正的查询受限，远不止用户能不能看到表这么简单。

2.1 什么是查询受限

说白了，查询受限就是“管住 SQL 能干的事”。它的核心目标只有一个：让用户只能拿到他该拿的数据，多一丝都不行。

这里有个关键点——受限不仅仅是拒绝。我见过不少系统，一限制就直接报错，用户一看 403 就骂娘。真正的查询受限，应该是“无声无息地把不该给的挡掉，该给的正常返回”。

举个例子，客服人员查订单时，系统自动把同行的客户手机号中间四位换成 ****。这个替换动作，就是查询受限的一种实现。代码不会告诉客服“你权限不够”，而是悄悄地把数据脱了敏再给他。用户无感知，安全到位了。

2.2 查询受限的两个维度：逻辑受限 vs 物理受限

你可能会问：“那受限到底怎么分？” 我个人习惯把它分成两个维度——逻辑受限 和 物理受限。这两个概念，我在之前一个银行项目里吃过亏，所以印象特别深。

维度	定义	常见实现	例子
逻辑受限	在 SQL 执行逻辑层面，控制哪些行、哪些列、哪些聚合值能被看到	行级安全（RLS）、列级脱敏、视图、SQL 重写	“财务只能看到他部门报销单，不能看全公司”
物理受限	在资源／存储层面，控制数据访问的物理路径、速率、并发等	查询超时、资源组配额、连接池限制、数据隔离网络	“分析查询最多跑 30 秒，超时就 kill”

这两个维度不是二选一，而是叠加的。我在一个政务云项目里，曾见过两者搭配使用的情况：逻辑上，不同委办局只能看自己辖区的人口数据；物理上，每个租户的查询都有一个内存上限，防止一个慢查询拖垮整个集群。效果很好，值得借鉴。

2.3 受限策略的四大核心面向

实际落地时，我会把查询受限拆成四个具体层面来考虑。你想想看，每个 SQL 进来，实际上经过的就这四道关卡：

1. 谁能查？——身份认证与授权
2. 能查啥表？——对象级（库、表、视图）可见性
3. 查出来的数据能看多少？——行级与列级过滤
4. 查快了还是慢了？——运行时行为控制

我自己的经验是，大部分公司能做到 1 和 2，但 3 和 4 才是真正的深水区。尤其是行级过滤，一不小心就踩坑。比如，我记得有一次审核线上环境，发现一个开发人员居然能通过 WHERE department_id = xxx 遍历全公司的薪资数据——因为他权限是“能看到薪资表”，但没有行级控制。

2.4 典型受限场景速览

我列出了几个我实际遇到过的典型场景，你可以对照看看自己项目中有没有类似情况：

• 多租户系统：租户 A 不能看到租户 B 的任何数据。通常靠 tenant_id 字段做行级过滤。
  ——之前我在 SaaS 项目里，就因为忘了在 JOIN 子句里加租户过滤，导致数据跨租户泄露，修了好几个通宵。
• 敏感字段脱敏：身份证号只显示前 6 位和后 4 位，中间用 * 代替。一般通过数据库内置掩码函数或中间件完成。
• 查询超时熔断：OLAP 复杂查询最多跑 60 秒，超时自动 kill，防止影响生产库。很多公司做不够好，我就见过一个报表查询把整个主库拖死的惨案。
• 方言限制：禁止用户执行 DROP、TRUNCATE 等危险语句。通过 SQL 解析器校验后放行。

2.5 整体知识框架

说了这么多，来一张图把本章核心串起来。你看着这张图，就知道查询受限到底管了哪些事：

看完这张图，你应该已经清楚了。整个查询受限框架，就是围绕“用户进来一个 SQL，我们怎么既让他完成工作，又不让他越界”来设计的。逻辑受限管的是“数据本身”，物理受限管的是“访问行为”。

嗯，这一章把概念理清楚了。后面的章节，咱们会一个个深入，看看每种策略怎么落地、怎么选型、怎么避免一些常见的坑。别急，一步一个脚印来。