活动专区

活动公告

上车！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 常用函数、表达式

业务报「SQL 卡住不动」，在 GBase 8a 上未必是执行计划慢，也可能是 **等锁、等元数据、或协调节点被长事务拖住**。8a 是 MPP：除了单会话里的锁，还要关注 **未提交事务** 对 DDL、统计信息、批量加载的阻塞，以及集群忙时误判为「单条 SQL 性能差」。

本文给一套在 **gccli** 侧可落地的排查顺序，并附常见止血动作。

## 一、先区分：算力慢 vs 等不到锁

接到「卡住」时，建议先记：**SQL 文本、开始时间、是否涉及 DDL/大表加载、同一时段是否有批量任务**。

| 现象 | 优先怀疑 | 建议动作 |
|------|----------|----------|
| `SHOW PROCESSLIST` 状态含 `Locked` / 等待表 | 行锁、元数据锁、长事务 | 查阻塞链，先处理持锁会话 |
| 状态 `Sending data` / `Executing` 很久 | 执行计划、Motion、资源 | 转慢 SQL 排查（EXPLAIN） |
| 仅 DDL 慢（`ALTER`/`ANALYZE`） | 长查询未结束、未提交事务 | 查 PROCESSLIST + 持锁事务 |
| 集群时段性全体变慢 | 并发加载、备份、网络 | 看 DN 监控与作业窗口 |

**不要**在未确认锁等待前，对大表盲目 `CREATE INDEX` 或改分布键。

## 二、gccli 里先看什么

在协调节点用 **gccli**（语法以现场版本为准）：

```sql
SHOW PROCESSLIST;
-- 部分版本支持更细字段，关注：Id、User、Host、db、Command、Time、State、Info
```

阅读时建议标出：

1. **Time 很大** 且 **State 含 Locked / Waiting** 的会话 → 候选受害者
2. **Info** 为 `NULL` 或空，但 **Time 很大** → 常见为 **空闲未提交事务**（持锁不放）
3. 同一 **db** 下多条会话同时等待 → 可能同一热点表或 DDL 冲突

若有 `information_schema` 类视图（以文档为准），可辅助查 InnoDB 风格锁；8a 现场以 **PROCESSLIST + 运维工具** 为主。

```sql
SELECT DATABASE();
SELECT @@autocommit;   -- 若应用误关 autocommit，易留下长事务
```

## 三、案例：批量加载后报表「一直转圈」

**场景**：夜间 ETL 向事实表 `fact_sales` 加载，白天 BI 查询同表，上午 10 点起多条报表超时；PROCESSLIST 里多条 `Locked`，Info 指向 `SELECT ... FROM fact_sales`。

**排查摘要**：

- 加载会话 **Id=2105**，`Time=38000`，`State` 正常但 **未 COMMIT**
- 报表会话 **State=Locked**，等待 `fact_sales` 相关元数据/行锁

**根因**：加载程序在异常分支未提交/回滚，**长事务占锁**，白天查询排队。

**止血（择一，需变更窗口与权限）**：

1. 与业务确认后 **KILL 加载会话**（`KILL `，语法以版本为准）
2. 应用侧修复：加载结束 **显式 COMMIT**；失败路径 **ROLLBACK**
3. 大加载与查询 **错峰**；加载库与查询库隔离（若架构允许）

处理后重跑一条简单 `SELECT COUNT(*)` 验证是否秒回。

## 四、DDL 与 ANALYZE 被挡：元数据锁

在 8a 上对大数据表做 `ANALYZE TABLE`、`ALTER` 时，若长期无响应，常见原因是 **仍有查询或事务引用该表**。

建议顺序：

1. `SHOW PROCESSLIST` 找 **Time 长** 且访问同表的会话
2. 协调与业务确认能否终止非关键会话
3. 在维护窗口执行 DDL/ANALYZE，并 **限制并发加载**

**避免**在业务高峰对核心事实表做全表 DDL；可拆分为 **分区级** 或 **从库/副本** 上操作（视版本能力）。

## 五、应用侧预防清单

```text
[1] 批量写入：每批 COMMIT；异常必 ROLLBACK
[2] 连接池：空闲超时回收；避免借出「已开事务」连接
[3] 报表与 ETL：时间窗错开；大表加载前通知
[4] 上线前：对核心表跑 PROCESSLIST 基线（忙时/闲时）
[5] 卡住时：先 PROCESSLIST 再 EXPLAIN，先锁后计划
```

## 六、与慢 SQL 排查的衔接

| 若 PROCESSLIST 显示 | 下一步 |
|---------------------|--------|
| Locked / Waiting 为主 | 本文锁与事务路径 |
| Executing 且无锁 | 慢 SQL：EXPLAIN、分布键、Motion |
| 两者兼有 | 先清锁，再对残留慢 SQL 做计划优化 |

## 小结

GBase 8a 上「卡住」的第一眼，应落在 **PROCESSLIST 的 State 与 Time**，而不是直接改 SQL。长事务、未提交加载、DDL 与查询撞车，在 MPP 现场非常常见。建议团队沉淀 **阻塞会话截图 + 持锁 SQL + 处理动作**，与慢 SQL 案例库分开管理，避免重复踩坑。




性能调优

GBase 8a 锁等待与长事务排查：从 PROCESSLIST 到止血

GBase 8a 锁等待与长事务排查：从 PROCESSLIST 到止血

评论

热门帖子