MySQL HeatWave 实战：OLTP 与 OLAP 一体化的落地要点

预计阅读时间：10 分钟

传统架构里，交易系统（OLTP）和分析系统（OLAP）往往分属不同数据库——MySQL 跑业务，ClickHouse 或 Snowflake 做报表，中间再架一层 ETL。数据同步延迟、运维复杂度、安全策略割裂，都是老问题。MySQL HeatWave 的思路很直接：在同一个 MySQL 实例上加挂一个内存加速引擎，让分析查询直接在行存 + 列存的混合架构上跑，省掉数据搬运。

但"省掉搬运"不等于"直接开箱即用"。从实例选型、数据迁移到 HeatWave 集群加载，踩坑点不少。下面按实际落地顺序梳理关键决策和操作。

1. 实例选型：别在规格上欠账

HeatWave 的 MySQL 实例本身跑 OLTP，后面挂的 HeatWave 集群跑 OLAP。两者资源独立计费，但规格选择互相牵制：

MySQL 实例形状：OLTP 跑得稳，选 MySQL.VM.Standard.E3 或 MySQL.VM.Dense.E4；如果 OLTP 写入压力大，优先保证 CPU 和内存，不要为了省钱选过小规格导致查询排队。
HeatWave 集群节点数：分析性能取决于加载到内存的数据量和节点数。起步建议至少 2 节点（HeatWave.VM.Standard.E3），后续根据数据量线性扩容。一个经验值：1 个 HeatWave 节点大约能加载 1 TB 列存数据（压缩后），实际要看表结构和压缩率。
网络配置：MySQL 实例和 HeatWave 集群必须在同一个 VCN 的子网内，且端口 3306 和 3307（HeatWave 管理端口）的安全列表要放通。

用 OCI CLI 创建一个带 HeatWave 的 MySQL 实例，核心参数如下：

# 创建 MySQL 实例（OLTP 主库）
oci mysql db-system create \
  --display-name "heatwave-prod" \
  --compartment-id "ocid1.compartment.oc1..aaaa" \
  --shape-name "MySQL.VM.Standard.E3.8" \
  --configuration-id "ocid1.mysqlconfiguration.oc1..aaaa" \
  --admin-username "admin" \
  --admin-password "Str0ngP@ssw0rd!" \
  --subnet-id "ocid1.subnet.oc1..aaaa" \
  --data-storage-size-in-gbs 500

# 等实例 ACTIVE 后，附加 HeatWave 集群（2 节点起步）
oci mysql heat-wave-cluster create \
  --db-system-id "ocid1.mysqldb.oc1..aaaa" \
  --shape-name "HeatWave.VM.Standard.E3.16" \
  --cluster-size 2

注意：cluster-size 指的是 HeatWave 节点数量，不是 MySQL 实例数。扩容时用 update --cluster-size 即可在线加节点，不需要停库。

2. 数据迁移：从现有 MySQL 到 HeatWave

迁移分两步：先把 OLTP 数据搬到 OCI MySQL 实例，再把需要分析的表加载到 HeatWave 内存列存。

2.1 OLTP 数据搬迁

官方推荐 MySQL Shell 的 util.copyInstance 或 util.loadDump，比传统 mysqldump 快得多，且支持并行和一致性快照：

# 在源库导出（并行 8 线程，一致性快照）
mysqlsh --uri source_user@source_host:3306 \
  --util dump-instance \
  --output-dir ./dump \
  --threads 8 \
  --consistent

# 在目标 HeatWave MySQL 实例导入
mysqlsh --uri admin@heatwave-prod.mysql.oraclecloud.com:3306 \
  --util load-dump ./dump \
  --threads 8 \
  --updateGtidSet=replace

如果源库数据量大（>100 GB）或网络跨区域，考虑用 OCI Object Storage 做中转：dump-instance 直接写到 OSS，load-dump 从 OSS 读，省掉本地磁盘瓶颈。

2.2 关键迁移检查点

检查项	为什么重要
字符集一致性	源库如果是 `latin1`，目标默认 `utf8mb4`，乱码风险
外键和触发器	`load-dump` 默认跳过外键校验以加速导入，导入后要重新启用
自增列偏移	大表的自增 ID 在并行导入时可能冲突，需确认 `auto_increment_offset`
存储引擎	HeatWave 要求 InnoDB；MyISAM 表要先转换

3. HeatWave 加载：不是所有表都要进内存

HeatWave 的核心操作是把 InnoDB 行存表"加载"到内存列存。加载后，优化器自动判断：纯点查走 InnoDB，聚合分析走 HeatWave——不需要改 SQL。

但内存有限，加载策略要精打细算：

-- 查看当前 HeatWave 内存使用情况
CALL sys.heatwave_mem_show();

-- 只加载需要做分析的表和列（排除不参与聚合的冗余列）
ALTER TABLE orders SECONDARY_ENGINE = HEATWAVE;
ALTER TABLE orders SECONDARY_LOAD;
-- 如果 orders 表有 50 列，但分析只用 8 列，可以指定列加载
ALTER TABLE orders MODIFY COLUMN order_comment SECONDARY_ENGINE = NONE;
-- order_comment 不进 HeatWave，节省内存

几个实操建议：

先加载核心事实表（订单、交易流水），维度表（用户、商品）如果数据量小可以后加载。
用 SECONDARY_ENGINE = NONE 排除大文本列：VARCHAR(2000) 的备注字段进列存几乎没有分析价值，却吃内存。
增量加载：表数据更新后，用 ALTER TABLE ... SECONDARY_LOAD 重新加载，HeatWave 会做增量同步而非全量重刷。高频更新的表可以设置自动 SECONDARY_UNLOAD/LOAD 定时任务。

4. 查询验证：确认 SQL 真的走了 HeatWave

加载完不代表查询一定走列存。优化器有成本模型，某些场景仍会选 InnoDB。验证方法：

-- 开启 EXPLAIN 的 HeatWave 扩展信息
SET SESSION use_secondary_engine = FORCED;

-- 查看执行计划
EXPLAIN SELECT region, SUM(amount) AS total
FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-06-30'
GROUP BY region;

-- 结果中 "Secondary engine: HeatWave" 表示走列存
-- 如果显示 "Secondary engine: off"，说明优化器判断 InnoDB 更优

use_secondary_engine 有三个值：

值	行为
`OFF`	强制走 InnoDB，调试基线性能时用
`ON`	让优化器自动选择（默认）
`FORCED`	强制走 HeatWave，用于验证列存是否可用

生产环境保持 ON。如果某条 SQL 在 ON 下不走 HeatWave 但你期望它走，检查：表是否已加载、查询是否包含 HeatWave 不支持的语法（如某些子查询、窗口函数的早期限制版本）。

5. OLTP 与 OLAP 共存的调优平衡

同一实例跑两类负载，最大的风险是 OLAP 大查询抢 OLTP 的连接和 CPU。HeatWave 本身把分析计算卸载到内存集群，MySQL 实例只做查询调度和结果回传，压力比传统架构小很多。但仍需注意：

连接池隔离：OLTP 应用和 BI 报表用不同的连接池，设置不同的 max_connections 限额。报表连接池上限可以卡在 20-30，避免并发分析把连接打满。
资源组（MySQL 8.0 特性）：给报表用户分配低优先级资源组，OLTP 用户高优先级：

-- 创建资源组
CREATE RESOURCE GROUP oltp_group
  TYPE = USER
  VCPU_PRIORITY = HIGH
  THREAD_PRIORITY = 10;

CREATE RESOURCE GROUP olap_group
  TYPE = USER
  VCPU_PRIORITY = LOW
  THREAD_PRIORITY = 1;

-- 把报表用户绑定到低优先级组
ALTER USER bi_reader RESOURCE GROUP olap_group;

慢查询阈值分开看：OLTP 的慢查询阈值设 100ms，OLAP 设 10s，不要用同一个 long_query_time 混着判断。

6. 上线前的检查清单

步骤	验证内容
实例规格	MySQL 实例 CPU/内存是否满足 OLTP 峰值；HeatWave 节点数是否覆盖分析数据量
网络与安全	VCN 子网、安全列表放通 3306/3307；ACL 限制报表用户只读
数据迁移完整性	行数校验、字符集校验、外键一致性
HeatWave 加载覆盖率	核心分析表全部 `SECONDARY_LOAD`；冗余列排除
查询路由验证	`EXPLAIN` 确认关键报表 SQL 走 HeatWave
负载隔离	连接池分离、资源组绑定、慢查询阈值分级
回退方案	保留源库只读副本至少 2 周，确认无数据差异后再切换写入

HeatWave 的价值不是"跑得更快"这么简单——它消除的是 OLTP 和 OLAP 之间的数据鸿沟和运维割裂。但消除鸿沟的前提是你在规格、加载、路由、隔离四个环节都做了对的决策。上面这些操作不是理论推演，而是每一步都有对应的 CLI 或 SQL 可以直接跑。建议在非生产环境先完整走一遍迁移 + 加载 + EXPLAIN 验证流程，再决定正式上线节奏。