SQL Server 存储过程中禁止 INSERT/UPDATE/DELETE 的最简可靠方法是：使用 EXECUTE AS 切换至仅具 SELECT 权限的专用用户，并配以运行时 TRY...CATCH 检测 DML 异常，同时严格审查所有依赖过程权限。
SQL Server 存储过程中禁止 INSERT/UPDATE/DELETE 的最简方法
直接结论：SQL Server 没有内置的「只读存储过程」开关，但可通过 SET NOCOUNT ON + 权限控制 + 运行时检查三者配合实现强约束。单靠语法或权限都不够可靠。
用 EXECUTE AS 和最小权限隔离 DML 能力
很多人以为给用户只授 EXECUTE 权限就能防 DML，其实不行——只要存储过程里写了 UPDATE，且调用者对目标表有权限，照样执行成功。真正有效的是让存储过程以无 DML 权限的上下文运行：
- 在存储过程开头加
EXECUTE AS USER = 'readonly_user'（该用户对所有业务表只有SELECT） - 必须配
REVERT或显式EXECUTE AS CALLER结尾，避免权限泄漏 - 注意：
readonly_user不能是dbo或sysadmin角色成员，否则无效 - 若过程需访问系统视图（如
sys.tables），要额外给VIEW DEFINITION权限
运行时检测并中断非法 DML 操作
权限控制是第一道防线，但开发阶段可能误写 DML；上线后也需主动拦截。SQL Server 提供 @@OPTIONS 和 CONTEXT_INFO 不够用，更直接的是捕获执行流：
- 在存储过程顶部插入检查逻辑：
IF EXISTS (SELECT 1 FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t WHERE r.session_id = @@SPID AND t.text LIKE '%[[:space:]](INSERT|UPDATE|DELETE)[[:space:]]%') THROW 50000, 'DML statement detected in read-only procedure', 1; - 实际不推荐正则匹配 SQL 文本（易误判、性能差），更稳妥的是用
TRY...CATCH包裹所有可能 DML，并在CATCH中检查ERROR_NUMBER()是否为 3902（事务被回滚）、3621（影响行数为 0 但非预期）等信号 - 真正可靠的运行时防护是启用 SQL Server 的FIPS flavor 模式（极少用）或借助扩展事件（XEvent）监听
sql_batch_completed事件，但成本高，适合审计而非拦截
PostgreSQL / MySQL 用户注意兼容性差异
如果你实际用的是 PostgreSQL 或 MySQL，别套用 SQL Server 方案——它们机制完全不同：
- PostgreSQL 支持
SECURITY DEFINER函数，默认以定义者权限运行，可创建只带SELECT权限的专用角色，再用CREATE FUNCTION ... SECURITY DEFINER封装查询逻辑，天然隔离 DML - MySQL 8.0+ 可通过
SQL SECURITY DEFINER+ 严格权限分配实现类似效果，但要注意DEFINER用户必须存在且权限明确，否则函数会因权限不足而静默失败 - MySQL 的
READ ONLY模式（super_read_only=ON）会影响整个实例，不能按存储过程粒度控制
最易被忽略的一点：哪怕所有技术手段都加上了，只要存储过程里调用了另一个未受控的存储过程（比如 EXEC @other_proc），整条链路就失效。必须逐层审查依赖关系，不能只盯住入口过程。
