活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8a 存储过程的执行身份与权限链风险

我最近看 GBase 8a 相关资料时，越来越明显的一个感受是：很多现场里存储过程出问题，并不是语法没写对，而是对象能创建、也能编译通过，等真正交给业务账号调用时，才开始暴露出权限链、执行身份和对象变更带来的连锁问题。

这类问题很容易被误判成“数据库偶发异常”或者“用户授权没生效”。但我自己整理下来觉得，GBase 8a 里存储过程最难缠的地方，不在过程体本身，而在它背后的执行上下文。尤其是多人协作、测试库向生产迁移、账号改名、对象归属调整这几类场景，只要前面设计得不规整，后面就特别容易出现“过程看得到但不能调”“能调过程却查不到表”“改了用户名后过程失效”这类现场问题。

真正落到现场时，我一般不会上来就反复 grant。我更关注三件事：过程是谁定义的、调用时到底按谁的权限执行、过程依赖的对象和账号后来有没有变更过。把这三件事拆清楚，排查效率会高很多。

## 先把问题拆开看

GBase 8a 里的存储过程问题，表面现象经常很像，但根因并不一样。按我自己的排查习惯，至少要先分成下面几类。

| 现场现象 | 常见根因 | 第一优先检查点 |
| --- | --- | --- |
| 过程创建成功，但业务账号 `CALL` 失败 | 缺少 `EXECUTE` 权限，或执行身份不是预期 | `GRANT EXECUTE`、`SQL SECURITY` |
| 调过程能进入，但过程内访问表报权限错误 | 定义者/调用者权限边界没理顺 | 过程定义、依赖表授权 |
| 测试正常，换账号或迁移后失效 | `DEFINER` 失配、依赖对象归属变化 | `SHOW CREATE PROCEDURE`、系统表 |
| 用户名修改后，过程不可见或不可用 | 过程中的定义者仍指向旧账号 | `gbase.proc` |
| 同样一套脚本，不同环境执行结果不同 | 默认库、调用入口、权限模型不一致 | 过程归属库、调用方式 |

我最近整理下来觉得，这类问题最容易踩坑的误区，是把“谁创建了过程”和“谁在执行过程”当成同一件事。实际上这两件事在 GBase 8a 里是可以分开的，而且一旦分开，就会牵出完整的权限链问题。

## 我更关注的其实是 SQL SECURITY

从落地角度看，存储过程真正容易埋雷的点不是 `BEGIN ... END`，而是 `SQL SECURITY`。GBase 8a 支持 `SQL SECURITY DEFINER` 和 `SQL SECURITY INVOKER`，默认是 `DEFINER`。这意味着，过程跑起来时，到底按定义者权限还是调用者权限执行，行为可能完全不同。

### DEFINER 和 INVOKER 的区别

| 选项 | 执行时采用的权限主体 | 适合场景 | 风险点 |
| --- | --- | --- | --- |
| `SQL SECURITY DEFINER` | 过程定义者 | 固化统一的数据访问入口 | 定义者变更、账号失效、环境迁移后容易出问题 |
| `SQL SECURITY INVOKER` | 过程调用者 | 权限边界清晰、便于分环境控制 | 调用账号需要具备过程访问对象的权限 |

我自己更倾向于把这两个模式分开使用：

- 面向业务应用的标准化查询入口，如果希望屏蔽底层表结构，可以考虑 `DEFINER`。
- 面向运维脚本、批处理任务或者多租户隔离场景，我个人更倾向于 `INVOKER`，因为后续排障更直接。

很多问题恰恰出在这里：开发阶段用 DBA 或高权限账号建了过程，测试时一切正常；上线后换成业务账号调用，表面上过程有 `EXECUTE` 权限，但过程体里访问的对象实际上还是靠定义者权限兜底。一旦定义者账号被调整、禁用、改名，问题就全冒出来了。

## 一类很容易忽略的风险：账号变了，过程没跟着变

我看到社区里就有一个很典型的例子：用户通过 rename 改了账号名，但原账号创建的存储过程在新账号下无法正常查看和使用，最后定位到系统表里的 `definer` 仍然是旧值。

这个现象特别像现场常见的“授权明明加了，为什么还是不行”。如果只盯着库级权限和表级权限，很容易转半天都找不到根因。因为过程对象本身保存的定义者信息并不会自动跟着用户改名同步。

我实际排查时一般先看：

```sql
SHOW CREATE PROCEDURE app_core.proc_sync_order;
```

如果输出里能明确看到 `DEFINER`，那后面的方向就清楚了。再进一步，可以核对系统表中的过程元数据。

```sql
SELECT db, name, definer
FROM gbase.proc
WHERE db = 'app_core'
  AND name = 'proc_sync_order';
```

如果已经确认是账号改名或归属迁移造成的失配，处理思路通常有两种：

| 处理方式 | 适合场景 | 风险 |
| --- | --- | --- |
| 重新按目标账号重建过程 | 规范治理、适合正式修复 | 需要重新发版或执行 DDL |
| 修正系统表中的 `definer` 信息 | 应急恢复、时间窗口很紧 | 必须严格评估，变更前后都要校验 |

应急处理时，有些现场会直接调整系统表，例如：

```sql
UPDATE gbase.proc
SET definer = 'svc_app@%'
WHERE db = 'app_core'
  AND name = 'proc_sync_order';
```

我个人更关注的是，这种动作一定不能只停留在“改完能跑就行”。后面至少还要补三步：

```sql
FLUSH PRIVILEGES;
SHOW CREATE PROCEDURE app_core.proc_sync_order;
CALL app_core.proc_sync_order(...);
```

同时要补做依赖对象校验，否则过程本身恢复了，里面引用的表、视图、函数如果还挂在旧权限链上，业务一样会报错。

## 过程能执行，不代表权限链完整

还有一类问题也很常见：业务账号已经拿到了过程的 `EXECUTE` 权限，但执行到过程内部语句时还是报权限不足。这个时候我不会只看过程授权，而是会把权限链按“入口权限”和“对象权限”分开检查。

### 先看入口权限

```sql
GRANT EXECUTE ON PROCEDURE app_core.proc_sync_order TO 'svc_job'@'%';
```

### 再看过程内部依赖对象

如果过程定义为 `SQL SECURITY INVOKER`，那么调用账号本身必须具备过程体里涉及对象的访问权限，例如：

```sql
GRANT SELECT, INSERT, UPDATE ON app_core.order_stage TO 'svc_job'@'%';
GRANT SELECT ON app_core.dim_store TO 'svc_job'@'%';
```

如果过程是 `SQL SECURITY DEFINER`，那就要确认定义者账号是否仍然有效、是否还保留对象权限。

我自己更喜欢用一张表把现场逻辑先摊开：

| 检查层级 | 具体内容 | 常见误判 |
| --- | --- | --- |
| 过程级 | 是否有 `EXECUTE` 权限 | 只授过程执行权限，忽略对象访问链 |
| 对象级 | 表、视图、函数是否已授权 | 误以为定义者权限一定长期可用 |
| 账号级 | 定义者账号是否存在、是否改名 | 账号重命名后遗漏过程归属 |
| 环境级 | 当前库、VC、调用方式是否一致 | 测试脚本省略库名，上线后跑偏 |

## 现场里更稳的写法，我一般这样收敛

如果一个过程要长期在线上跑，我自己更倾向于让它的归属、权限和依赖关系尽量“可读、可迁移、可审计”。下面这种写法虽然不花哨，但现场稳定性通常更好。

```sql
DELIMITER //
CREATE DEFINER = 'svc_proc'@'%'
PROCEDURE app_core.proc_sync_order(IN p_batch_id VARCHAR(32))
SQL SECURITY DEFINER
BEGIN
    INSERT INTO app_core.order_stage_hist
    SELECT *
    FROM app_core.order_stage
    WHERE batch_id = p_batch_id;

    UPDATE app_core.order_stage
       SET sync_flag = 'Y'
     WHERE batch_id = p_batch_id;
END //
DELIMITER ;
```

配套授权不要省：

```sql
GRANT EXECUTE ON PROCEDURE app_core.proc_sync_order TO 'svc_job'@'%';
GRANT SELECT, INSERT, UPDATE ON app_core.order_stage TO 'svc_proc'@'%';
GRANT INSERT ON app_core.order_stage_hist TO 'svc_proc'@'%';
```

如果要走调用者权限，那过程定义我会改成更显式：

```sql
DELIMITER //
CREATE PROCEDURE app_core.proc_check_batch(IN p_batch_id VARCHAR(32))
SQL SECURITY INVOKER
BEGIN
    SELECT batch_id, COUNT(*) AS row_cnt
    FROM app_core.order_stage
    WHERE batch_id = p_batch_id
    GROUP BY batch_id;
END //
DELIMITER ;
```

这样谁能查、谁不能查，边界更清楚。代价是调用账号授权要提前设计好，不能临时糊。

## 我实际排查时常用的一组核对动作

很多时候，问题不是不会处理，而是现场时间紧，动作顺序一乱就容易漏。按我自己的经验，下面这组检查顺序比较稳。

### 1. 先确认过程定义

```sql
SHOW CREATE PROCEDURE app_core.proc_sync_order;
SHOW CREATE FUNCTION app_core.fn_calc_amt;
```

重点看这些信息：

- 是否带 `DEFINER`
- `SQL SECURITY` 是 `DEFINER` 还是 `INVOKER`
- 过程归属的数据库是否正确
- 是否存在跨库调用

### 2. 再确认系统元数据

```sql
SELECT db, name, type, definer
FROM gbase.proc
WHERE db = 'app_core';
```

### 3. 最后再检查授权链

```sql
SHOW GRANTS FOR 'svc_job'@'%';
SHOW GRANTS FOR 'svc_proc'@'%';
```

如果现场没有统一命名，我还会额外核对过程名和调用库名，避免因为不同环境脚本写法不一致导致误判。

## 这类问题最容易留下的坑

我最近整理下来觉得，GBase 8a 里存储过程相关问题，真正麻烦的不是报错本身，而是“修好了这次，却没修治理方式”。下面这些坑基本都值得单独留意。

| 常见坑 | 现场表现 | 我个人更倾向的处理方式 |
| --- | --- | --- |
| 用高权限个人账号创建过程 | 测试正常，生产迁移后权限混乱 | 使用专门的过程定义账号 |
| 过程依赖跨库对象 | 不同环境库名不同，迁移后失效 | 统一命名，显式写全限定名 |
| 改账号名不重建过程 | 过程不可见或不可调用 | 统一重建或集中核对 `definer` |
| 只做 `GRANT EXECUTE` | 过程进入后对象访问报错 | 同步核对对象级授权 |
| 环境脚本不保留 DDL | 故障后只能手工补过程 | 过程定义纳入版本管理 |

## 我自己更看重的不是“能不能跑”，而是后面还能不能维护

说到底，GBase 8a 的存储过程并不只是一个 SQL 封装壳。它本质上是对象定义、执行身份和权限模型绑在一起后的产物。现场里一旦发生账号调整、环境迁移、对象归属变化，这几部分任何一处没收口，后面都可能变成隐患。

我最近看资料时最深的一个感受是，存储过程治理做得好不好，不取决于你会不会写循环、条件和变量，而取决于你有没有把“谁创建、谁执行、谁拥有底层对象权限”这条链条提前讲清楚。真正落到现场时，很多问题都不是临时多加一条授权能解决的。

我自己现在更倾向于把存储过程当成“可运维对象”去管理：

- 过程定义账号单独规划；
- `SQL SECURITY` 明确写出，不依赖默认值；
- 过程 DDL 纳入版本管理；
- 账号改名、对象迁移后，补做一次过程元数据校验；
- 上线前不只测“能创建”，还要测“业务账号能不能按预期执行”。

这样做看起来前期多花一点时间，但后面真遇到问题，排查路径会清楚很多。

## 参考资料

```text
[1] 创建存储过程/函数
https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/dm-database-management-guide/dm-procedures-functions/dm-procedures-functions-create

[2] GBase 8a 存储过程的赋权
https://www.gbase.cn/community/post/6198

[3] 用户名修改导致存储过程无法识别
https://www.gbase.cn/community/post/8232

[4] GBase 8a
https://www.gbase.cn/community/section/11
```





运维管理

 GBase 8a 存储过程的执行身份与权限链风险

GBase 8a 存储过程的执行身份与权限链风险

评论

热门帖子