在数据库日常运维和开发中，存储过程是一段预编译的SQL语句集合，很多时候我们只需要让存储过程执行查询类操作，不允许其进行插入、更新、删除等DML操作，避免数据被意外修改。要实现这个需求，可以从多个层面入手，下面逐一介绍具体实现方式。
一、通过事务隔离级别实现只读访问
可以将存储过程内部的事务隔离级别设置为只读模式，这样整个存储过程执行过程中都无法执行DML操作，是最直接的限制方式之一。以SQL Server为例，我们可以在存储过程开头设置事务隔离级别为READ_ONLY。
-- 创建只读存储过程示例
CREATE PROCEDURE Get_User_Info
@UserId INT
AS
BEGIN
-- 设置事务隔离级别为只读
SET TRANSACTION ISOLATION LEVEL READ ONLY;
-- 仅执行查询操作
SELECT user_id, user_name, user_age
FROM user_info
WHERE user_id = @UserId;
END
这种方式的优点是配置简单，不需要额外做权限或者逻辑校验，缺点是如果存储过程内部需要临时执行一些辅助的DML操作（比如临时表写入）就不适用，会直接报错。
二、通过权限控制限制DML操作
可以给存储过程的执行用户仅授予查询相关表的SELECT权限，不授予INSERT、UPDATE、DELETE权限，从权限层面杜绝DML操作的可能。假设我们有一个存储过程Query_Order_List，只需要查询order_table表的数据。
首先收回用户对该表的DML权限：
-- 收回用户test_user的INSERT、UPDATE、DELETE权限 REVOKE INSERT, UPDATE, DELETE ON order_table FROM test_user; -- 仅授予SELECT权限 GRANT SELECT ON order_table TO test_user;
之后用户执行存储过程时，即使存储过程内部有DML语句，也会因为没有对应权限而执行失败。这种方式的管控粒度是表级别，适合存储过程只需要访问固定几张表的场景。
三、在存储过程内部添加DML操作校验
如果无法修改事务隔离级别或者权限配置，也可以在存储过程内部主动校验，禁止执行DML操作。可以在存储过程开头添加判断逻辑，检查当前会话是否有执行DML的权限，或者直接禁止出现DML相关关键字。不过这种方式需要人工保证存储过程内部没有DML语句，也可以结合系统视图判断当前操作类型。
-- 存储过程内部校验示例
CREATE PROCEDURE Query_Product_Info
@ProductId INT
AS
BEGIN
-- 校验当前会话是否允许写操作，不允许则直接返回错误
IF (SELECT SESSIONPROPERTY('ARITHABORT')) = 0
BEGIN
RAISERROR('该存储过程仅支持只读访问，不允许执行DML操作', 16, 1);
RETURN;
END
-- 执行查询操作
SELECT product_id, product_name, product_price
FROM product_info
WHERE product_id = @ProductId;
END
四、不同方案的对比
我们可以根据实际需求选择合适的方案，以下是不同方案的对比：
| 方案类型 | 实现难度 | 管控粒度 | 适用场景 |
|---|---|---|---|
| 事务隔离级别设置 | 低 | 存储过程级别 | 存储过程完全不需要DML操作 |
| 权限控制 | 中 | 表级别 | 存储过程仅访问固定表，且用户权限可管控 |
| 内部逻辑校验 | 高 | 语句级别 | 无法修改隔离级别和权限的特殊场景 |
五、注意事项
- 设置事务隔离级别为只读时，要注意不同数据库的支持情况，比如MySQL需要在事务开始时设置，不能单独在存储过程内部设置。
- 权限控制方案需要定期核查用户权限，避免后续新增权限导致限制失效。
- 内部逻辑校验无法完全避免动态SQL拼接带来的DML操作风险，需要配合代码 review 使用。
通过以上几种方式，我们可以有效实现SQL存储过程的只读访问，限制DML操作，保障数据库数据的安全。实际使用中可以根据业务场景和数据库类型选择最合适的方案，也可以组合多种方案提升管控效果。