如何将服务表restrictions列作为SQL查询WHERE条件匹配用户资格

完全可以实现只传入单个user_id，就返回对应用户可享服务的单条SQL查询，整体性能会远优于你现在用JS在应用层做规则匹配的逻辑。
但有个关键误区要先澄清：绝对不能直接把services表中存储的纯规则文本嵌到WHERE子句里用，这种做法不仅逻辑走不通，还有严重的安全风险。

很多人第一反应是把存的规则文本动态拼到SQL里，但这种方式有两个绕不开的硬伤：

• 数据库执行SQL时，只会把规则文本当成普通字符串做值比较，不会自动把它解析成判断逻辑。比如直接写SELECT * FROM services WHERE restrictions，本质是判断这段字符串是不是非空，和你预期的“用户属性是否满足规则”完全是两回事。
• 如果直接把可被修改的规则文本拼到SQL语句中，一旦规则内容被篡改嵌入恶意SQL，会直接造成数据泄露甚至破坏，安全风险极高。

方案1：调整规则存储结构，实现零动态的高性能静态SQL（强烈推荐） #

这是目前最安全、性能最高的实现方式，本质是把现在存在restrictions字段里的纯文本规则，拆成结构化的关联规则表，全程不需要动态SQL拼接，数据库可以生成固定执行计划，查询效率远高于应用层JS判断。
具体调整步骤：

1. 新建结构化服务规则表service_restrictions，包含4个核心字段：
   • service_id：关联services表的服务ID
   • field_name：规则对应的用户表字段名（比如gender、age）
   • operator：规则判断运算符（比如=、>、<）
   • field_value：规则比较的目标值
2. 把现有restrictions字段里的纯规则文本拆解导入新表，比如：
   • service_id=1的原规则'gender' = 'male', 'age' > 18，拆解为2条规则：

     service_id	field_name	operator	field_value
     1	gender	=	male
     1	age	>	18

   • service_id=2的原规则'gender' = 'female'，拆解为1条规则：

     service_id	field_name	operator	field_value
     2	gender	=	female

3. 单条查询的SQL写法（只需要传入目标user_id参数）：

WITH target_user AS (
    -- 单次查询拿到目标用户的全部属性
    SELECT age, gender, lvl
    FROM user_table
    WHERE user_id = :target_user_id
),
rule_match_stat AS (
    SELECT
        s.service_id,
        s.name,
        -- 统计每个服务下匹配通过的规则数
        SUM(
            CASE
                WHEN r.field_name = 'gender' AND r.operator = '=' THEN (tu.gender = r.field_value)
                WHEN r.field_name = 'age' AND r.operator = '>' THEN (tu.age > CAST(r.field_value AS UNSIGNED))
                -- 后续新增的规则字段，只需要在这里加对应判断分支即可
                ELSE 0
            END
        ) AS passed_rule_count,
        -- 统计每个服务的总规则数
        COUNT(*) AS total_rule_count
    FROM services s
    JOIN service_restrictions r ON s.service_id = r.service_id
    CROSS JOIN target_user tu
    GROUP BY s.service_id, s.name
)
-- 所有规则都匹配通过的服务，就是用户可享的服务
SELECT service_id, name
FROM rule_match_stat
WHERE passed_rule_count = total_rule_count;

这个方案的优势非常明显：没有任何动态执行逻辑，所有判断都在数据库层完成，只需要传user_id就能返回最终结果，网络传输的数据量极小，比在JS层拉全量服务规则再做内存匹配的方案，查询延迟通常能下降一个数量级。

方案2：不调整现有表结构，利用数据库内置表达式能力实现 #

如果你暂时无法修改现有表结构，可以用部分数据库自带的动态表达式求值能力实现，比如PostgreSQL的动态PL/pgSQL、SQL Server的sp_executesql、DuckDB的eval函数等，但必须给存储的restrictions规则加严格的安全校验：

• 只允许规则中出现预先定义好的用户表字段名（user_id、name、age、gender、lvl）
• 只允许规则中出现预先定义的安全运算符（=、>、<、>=、<=、!=）
• 禁止规则中出现任何能触发SQL执行的关键字，从根源上避免注入风险

这种方案因为每次查询都需要动态解析规则文本，无法生成固定的执行计划，性能比结构化规则表的方案差，只适合规则格式多变、无法提前结构化的特殊场景。

内容的提问来源于stack exchange，提问作者Augusto Coelho Henriques