活动专区

活动公告

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

&gt; 国产化替代背景下，MySQL 迁移到 GBase 8a 是最常见的场景之一。两者虽然都兼容 MySQL 协议，但在事务模型、SQL 语法、数据类型上存在关键差异，忽视这些差异会导致应用上线后出现各种问题。


---

## 一、迁移前必须了解的核心差异

### 1.1 事务模型：最重要的差异

GBase 8a 是**分析型 MPP 数据库，不支持 OLTP 事务**。

| 特性 | MySQL (InnoDB) | GBase 8a |
|------|---------------|---------|
| 事务（BEGIN/COMMIT/ROLLBACK） | ✅ 完整支持 | ❌ 不支持 |
| 行级锁 | ✅ | ❌（表级锁） |
| MVCC 多版本并发 | ✅ | ❌ |
| autocommit | 可关闭 | **强制开启，不可关闭** |
| 外键约束 | ✅ | ❌ |

**迁移影响**：

- 应用代码中所有 `BEGIN / COMMIT / ROLLBACK` 语句必须删除
- JDBC 代码中的 `conn.setAutoCommit(false)` 必须移除或改为 `true`
- 依赖外键约束保证数据完整性的逻辑，需要在应用层实现

```java
// MySQL 代码（需要改造）
conn.setAutoCommit(false);
try {
    stmt.execute("INSERT INTO orders ...");
    stmt.execute("UPDATE inventory ...");
    conn.commit();           // GBase 8a 不支持
} catch (Exception e) {
    conn.rollback();         // GBase 8a 不支持
}

// GBase 8a 适配后
conn.setAutoCommit(true);   // 强制
stmt.execute("INSERT INTO orders ...");
stmt.execute("UPDATE inventory ...");
// 两条语句各自独立提交，无原子性保证
```

### 1.2 存储引擎

GBase 8a 只有一种存储引擎：`EXPRESS`（列存引擎）。

```sql
-- MySQL 建表
CREATE TABLE t (id INT) ENGINE=InnoDB;

-- GBase 8a 建表（ENGINE=EXPRESS 可省略，默认即是）
CREATE TABLE t (id INT) ENGINE=EXPRESS DISTRIBUTED BY HASH(id);
```

迁移时所有 `ENGINE=InnoDB`、`ENGINE=MyISAM` 都需要替换（或直接删除 ENGINE 子句）。

### 1.3 分布键：必须新增

MySQL 没有分布键的概念，但 GBase 8a 的每张表都需要指定 `DISTRIBUTED BY HASH(列名)` 或 `REPLICATED`。

迁移时需要为每张表设计分布键（参考前文《表设计实战》），这是迁移中最需要人工判断的步骤。

---

## 二、DDL 语法差异

### 2.1 建表语句改造

**MySQL 原表：**

```sql
CREATE TABLE `orders` (
  `order_id`    bigint(20) NOT NULL AUTO_INCREMENT,
  `customer_id` int(11) NOT NULL,
  `amount`      decimal(18,2) DEFAULT NULL,
  `status`      tinyint(4) NOT NULL DEFAULT '0',
  `order_date`  date NOT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`order_id`),
  KEY `idx_customer` (`customer_id`),
  KEY `idx_date` (`order_date`),
  CONSTRAINT `fk_customer` FOREIGN KEY (`customer_id`) REFERENCES `customers` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
```

**GBase 8a 适配后：**

```sql
CREATE TABLE orders (
  order_id    BIGINT       NOT NULL,   -- AUTO_INCREMENT 改为普通列（见下文）
  customer_id INT          NOT NULL,
  amount      DECIMAL(18,2),
  status      TINYINT      NOT NULL DEFAULT 0,
  order_date  DATE         NOT NULL,
  create_time DATETIME              -- DEFAULT CURRENT_TIMESTAMP 支持
) ENGINE=EXPRESS DEFAULT CHARSET=utf8mb4
DISTRIBUTED BY HASH(customer_id)    -- 新增分布键
PARTITION BY RANGE(order_date) (    -- 按需新增分区
  PARTITION p2024 VALUES LESS THAN ('2025-01-01'),
  PARTITION pmax  VALUES LESS THAN MAXVALUE
);
-- PRIMARY KEY 保留写法但 GBase 8a 不强制唯一约束
-- KEY (索引) 在 GBase 8a 中语法支持但列存引擎的索引作用不同
-- FOREIGN KEY 删除（不支持）
```

### 2.2 AUTO_INCREMENT 处理

GBase 8a 支持自增列，但有限制：

```sql
-- GBase 8a 中自增列的写法
CREATE TABLE orders (
  order_id BIGINT AUTO_INCREMENT,
  ...
) DISTRIBUTED BY HASH(order_id);

-- 查看和设置自增起始值
SHOW CREATE TABLE orders;
ALTER TABLE orders AUTO_INCREMENT = 10000000;
```

注意：**自增列不能作为 HASH 分布键**（自增列的分配在 gcluster 端，每次写入时才分配，不适合做数据分布依据）。建议改用业务 ID（如外部生成的 UUID 或雪花 ID）作为分布键。

如果原 MySQL 表的主键是 AUTO_INCREMENT，迁移到 GBase 8a 时可以保留自增，但分布键应选择另一个高基数业务列（如 `customer_id`）。

同时，GBase 8a 默认不允许手动向自增列插入值，若需要允许，配置：

```ini
# gbase.cnf
_gbase_auto_increment_allow_insert = 1
```

### 2.3 不支持的 DDL 语句

| MySQL DDL | GBase 8a 处理方式 |
|-----------|-----------------|
| `ALTER TABLE t MODIFY COLUMN c VARCHAR(200)` | ❌ 不支持，需重建表 |
| `ALTER TABLE t ADD INDEX idx (col)` | ⚠️ 语法接受但效果有限 |
| `ALTER TABLE t ADD FOREIGN KEY ...` | ❌ 不支持，删除 |
| `CREATE VIEW v AS SELECT ...` | ✅ 支持 |
| `CREATE TEMPORARY TABLE ...` | ❌ 不支持，改用普通表 |
| `TRUNCATE TABLE t` | ✅ 支持 |

---

## 三、DML 语法差异

### 3.1 支持与不支持

| SQL 语句 | GBase 8a 支持情况 |
|---------|-----------------|
| `SELECT ... FROM` | ✅ |
| `INSERT INTO ... VALUES` | ✅ |
| `INSERT INTO ... SELECT` | ✅ |
| `UPDATE ... SET` | ✅（但性能远低于 OLTP，避免大量单行 UPDATE） |
| `DELETE FROM ... WHERE` | ✅（同上） |
| `REPLACE INTO` | ✅ |
| `INSERT IGNORE` | ✅ |
| `SELECT ... FOR UPDATE` | ❌ 不支持（没有行锁） |
| `LOCK TABLES ... WRITE` | ⚠️ 有限支持 |
| `SELECT ... INTO @var` | ✅ 用户变量支持 |

### 3.2 UPDATE / DELETE 的注意事项

GBase 8a 的 UPDATE 和 DELETE 是**全表扫描后批量操作**，不像 MySQL 那样走索引点查。大量单行 UPDATE（如逐行更新 10 万条记录）会非常慢。

**迁移改造建议**：

- 高频更新场景考虑改为**先 DELETE 对应分区，再批量 INSERT**
- 或改用全量覆盖写入的设计（每次写入一个时间分区的完整数据）

```sql
-- 低效（避免）：逐行 UPDATE
UPDATE orders SET status = 2 WHERE order_id IN (1001, 1002, 1003, ...);

-- 高效替代：先删后写（如果有分区）
DELETE FROM orders WHERE order_date = '2024-06-01';
-- 批量插入最新数据...
```

### 3.3 不支持 CTE 的版本处理

低版本 GBase 8a 默认不开启 WITH AS（CTE）。如果源库有 CTE 语法，需要：

1. 开启 CTE 支持参数：`_t_gcluster_support_cte = 1`
2. 或将 CTE 改写为子查询（兼容性更强）

```sql
-- MySQL（CTE 写法）
WITH recent_orders AS (
    SELECT * FROM orders WHERE order_date &gt;= '2024-01-01'
)
SELECT customer_id, COUNT(*) FROM recent_orders GROUP BY customer_id;

-- 改写为子查询（GBase 8a 全版本兼容）
SELECT customer_id, COUNT(*)
FROM (
    SELECT * FROM orders WHERE order_date &gt;= '2024-01-01'
) t
GROUP BY customer_id;
```

### 3.4 函数兼容性

大部分 MySQL 函数在 GBase 8a 中兼容，以下是常见的差异：

| MySQL 函数 | GBase 8a 情况 | 备注 |
|-----------|--------------|------|
| `NOW()` / `SYSDATE()` | ✅ | |
| `DATE_FORMAT()` | ✅ | |
| `IF()` / `IFNULL()` | ✅ | |
| `GROUP_CONCAT()` | ✅ | 长度限制参数不同：`group_concat_max_len` |
| `FIND_IN_SET()` | ✅ | |
| `JSON_*` 系列 | ⚠️ 部分支持 | 版本相关，测试确认 |
| `REGEXP` | ✅ | |
| `STR_TO_DATE()` | ✅ | |
| `CONVERT(x USING charset)` | ⚠️ | 字符集转换支持有限 |
| `ROW_NUMBER() OVER()` | ✅ | |

---

## 四、数据迁移方案

### 4.1 小表（&lt; 1 亿行）：mysqldump + LOAD DATA

```bash
# 步骤 1：MySQL 端导出 CSV
mysql -h source_host -u root -p source_db -e \
  "SELECT * INTO OUTFILE '/tmp/orders.csv'
   FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\"'
   LINES TERMINATED BY '\n'
   FROM orders"

# 或使用 mysqldump 导出 SQL（需手动改造 DDL）
mysqldump --no-create-info --tab=/tmp/ source_db orders

# 步骤 2：GBase 8a 端建表（改造后的 DDL）
gccli -u gbase -p -e "source /tmp/gbase_ddl.sql"

# 步骤 3：LOAD DATA 导入
gccli -u gbase -p target_db -e "
LOAD DATA INFILE '/tmp/orders.csv'
INTO TABLE orders
CHARACTER SET utf8
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\"'
LINES TERMINATED BY '\n';
"
```

### 4.2 大表（&gt; 1 亿行）：DataX 并行迁移

参考前文《DataX 与 GBase 8a 集成实战》，使用 DataX 的 mysqlreader + mysqlwriter，设置合理的 channel 数和 splitPk 实现并行迁移。

### 4.3 迁移顺序建议

```
1. 先迁维度表（小表，数据量少，验证快）
      ↓
2. 建为复制表（REPLICATED）
      ↓
3. 再迁事实表（大表，按分区分批迁移）
      ↓
4. 每张表迁完后验证：COUNT(*) 对比，抽样数据对比
      ↓
5. 应用层切流（先读流量，再写流量）
```

---

## 五、应用层改造检查清单

```
SQL 层面
  □ 删除所有 BEGIN / COMMIT / ROLLBACK
  □ 删除 LOCK TABLES / SELECT FOR UPDATE
  □ 删除或注释掉 FOREIGN KEY 约束
  □ 将 CREATE TEMPORARY TABLE 改为普通表（用完手动 DROP）
  □ 检查 AUTO_INCREMENT 列是否适合做分布键（通常不适合）
  □ ALTER TABLE MODIFY COLUMN 改为重建表
  □ 测试所有 GROUP_CONCAT 长度是否足够

JDBC / 应用代码层面
  □ 移除 conn.setAutoCommit(false)
  □ 移除 conn.commit() / conn.rollback()
  □ JDBC URL 补充 socketTimeout（分析查询耗时更长）
  □ 移除依赖外键的级联删除逻辑，改到应用层处理
  □ 批量写入改用 rewriteBatchedStatements=true

性能优化
  □ 高频 UPDATE 改为 DELETE + INSERT 模式
  □ 全表扫描类查询确认走了分区裁剪
  □ 频繁 JOIN 的小维度表改为 REPLICATED
  □ 大表确认分布键选择合理（高基数、与 JOIN 键对齐）
```

---

## 六、迁移后的验证方案

```sql
-- 1. 行数对比
-- MySQL：
SELECT COUNT(*) FROM orders;
-- GBase 8a：
SELECT COUNT(*) FROM orders;

-- 2. 关键字段 SUM 对比（金额等数值字段）
-- MySQL：
SELECT SUM(amount), MAX(order_date), MIN(order_date) FROM orders;
-- GBase 8a：同样查询，结果应一致

-- 3. 抽样数据对比（取最近 100 条）
-- 在两边各执行，手动比对
SELECT * FROM orders ORDER BY order_id DESC LIMIT 100;

-- 4. 字符集验证（中文字段）
SELECT order_id, customer_name FROM orders WHERE customer_name LIKE '%张%' LIMIT 10;
```

---

## 七、常见迁移坑汇总

| 坑 | 现象 | 解决方式 |
|----|------|---------|
| 保留了事务代码 | 应用报错 `Transaction not supported` | 删除所有事务相关代码 |
| 分布键选了低基数列 | 部分 gnode 数据量是其他节点的几十倍 | 重建表，换高基数分布键 |
| 大量单行 UPDATE | 更新 10 万行耗时数小时 | 改为 DELETE 分区 + 批量 INSERT |
| AUTO_INCREMENT 做分布键 | 数据分布不均，第一个 gnode 承担所有写入 | 改用业务 ID 做分布键 |
| 忘记改 socketTimeout | 长查询触发 JDBC 超时报错 | JDBC URL 补充 `socketTimeout=3600000` |
| 外键约束未删除 | 建表报错 | 删除所有 FOREIGN KEY 语句 |
| 临时表 | 报错不支持 | 改为普通表，用完 DROP |
| `INSERT IGNORE` 未测试 | 部分版本行为与 MySQL 略有差异 | 单独测试验证 |



MySQL 迁移到 GBase 8a 实战：SQL 差异、数据迁移与应用适配完全指南

MySQL 迁移到 GBase 8a 实战：SQL 差异、数据迁移与应用适配完全指南

评论

热门帖子