MySQL on 吾爱主机

OceanBase 从零开始：核心概念、上手路径，以及和 MySQL 的关键差异

Fri, 17 Jul 2026 01:00:00 +0800

如果你已经会 MySQL，第一次接触 OceanBase 时，最容易卡住的不是“SQL 怎么写”，而是：

它看起来很像 MySQL，为什么连接方式、资源模型、高可用和运维概念完全不是一回事？

本文面向零基础到 MySQL 初中级同学，用一条从概念到上手的路径讲清楚：

OceanBase 是什么
和 MySQL 在架构、租户、连接、兼容性上的核心差异
从连接、建库建表到基础 SQL 的最小实践
什么场景该把 OceanBase 当“更强的 MySQL”，什么场景不能这么想

说明：本文以 OceanBase 社区版（MySQL 模式） 为主。官方文档明确：社区版仅提供 MySQL 模式；企业版还支持 Oracle 模式。

一、先建立正确心智模型

1. MySQL 的常见心智模型

很多人对 MySQL 的默认理解是：

一台机器 / 一个 mysqld 实例
 └── 多个 database
 └── 多个 table

连接通常很直接：

mysql -h127.0.0.1 -P3306 -uroot -p

你连上的，基本就是“这个实例本身”。

2. OceanBase 的心智模型

OceanBase 更接近：

一个集群（Cluster）
 └── 多个节点（OBServer）
 └── 多个可用区（Zone）
 └── 多个租户（Tenant） ← 应用视角下更像“数据库实例”
 └── 多个 database
 └── 多个 table / 分区

关键变化只有一句话：

在 OceanBase 里，应用通常不是“连一台 MySQL 机器”，而是“连某个租户”。

官方文档把租户定义为：集群内互相隔离的数据库“实例”。对应用来说，一个租户近似一个独立数据库实例；租户之间数据、权限、资源隔离。

二、OceanBase 是什么

OceanBase 是蚂蚁集团开源的分布式关系型数据库，基于 Paxos 类共识协议与分布式架构，提供高可用和水平扩展能力，可运行在普通服务器集群上。

官方强调的关键能力包括：

水平扩展
高可用（RPO=0、RTO 秒级恢复目标）
MySQL 兼容，便于迁移
HTAP（同一套系统同时服务事务与分析负载）
多租户资源隔离

你可以把“上手阶段”理解成两层：

层	你感受到的
SQL 层	很像 MySQL：`CREATE DATABASE` / `CREATE TABLE` / `SELECT`
系统层	更像分布式数据库：集群、Zone、租户、Unit、副本、OBProxy

三、和 MySQL 的核心差异总览

维度	MySQL（常见单机/主从）	OceanBase
基本部署单元	实例（mysqld）	集群 + 租户
应用连接对象	实例	租户（经直连或 OBProxy）
默认端口（常见）	`3306`	直连 `2881`，经 ODP/OBProxy 常见 `2883`
用户写法	`root`	`root@tenant` 或 `user@tenant#cluster`
扩展方式	垂直扩容 / 读写分离 / 分库分表	原生分区、多节点、副本扩展
高可用机制	主从复制、MGR 等	基于 Multi-Paxos 的多副本日志流
多业务隔离	多实例 / 多库 + 权限	原生多租户 + 资源池
存储引擎模型	InnoDB 等可插拔引擎	自研分布式存储与事务体系
SQL 兼容	原生 MySQL	MySQL 模式兼容 5.7/8.0 大部分能力，但非 100%
社区版模式	MySQL	仅 MySQL 模式

一句话：

MySQL 更像“一台关系库”；OceanBase 更像“一个可多租户的分布式数据库平台”。

四、架构差异：为什么它不像单机 MySQL

1. Shared-Nothing 集群

官方系统架构文档指出，OceanBase 常用无共享（Shared-Nothing）模式：

节点对等
每个节点都有自己的 SQL / 存储 / 事务能力
表可水平拆分为多个分区（Partition）
分区数据落在 Tablet，修改通过日志流（Log Stream）持久化
主从副本通过 Multi-Paxos 保持一致性

这意味着：

数据天然可分布到多节点
故障切换依赖副本选举，而不是简单“切到另一台 mysqld”
建表时的分区设计，会直接影响数据分布与扩展性

2. 多租户：最容易被 MySQL 同学忽略的概念

在 OceanBase 中：

集群初始化后会有系统租户 sys
sys 保存集群元数据，本身也是 MySQL 兼容模式租户
业务一般应在普通租户里建库建表，而不是把所有业务都堆在 sys

创建业务租户的典型顺序是：

Unit Config（资源规格）
 → Resource Pool（资源池）
 → Tenant（租户）

这和 MySQL 里“直接 CREATE DATABASE”完全不同。
MySQL 的 database 更像命名空间；OceanBase 的 tenant 更像独立实例边界。

3. OBProxy / ODP：应用如何“像访问单机库一样”访问分布式库

为了让应用尽量少感知分区和副本分布，OceanBase 提供 ODP（OceanBase Database Proxy，又称 OBProxy）：

应用通常连代理
代理把 SQL 路由到合适节点
对应用更接近“连一个入口地址”

这对应 MySQL 生态里的 proxy / 中间件角色，但在 OceanBase 里它更常作为标准访问路径出现。

五、连接差异：最容易踩坑的地方

1. Docker 体验环境（最简单）

快速体验可用官方镜像：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce | tail -1 # 期望 boot success!

连接示例：

# 系统租户 root
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

# 或宿主机 mysql 客户端
mysql -h127.0.0.1 -P2881 -uroot
mysql -h127.0.0.1 -P2881 -uroot@test

2. 正式连接写法：用户名里有租户

官方文档给出两类常见连接：

直连 OBServer（默认端口常为 2881）

mysql -h<observer_ip> -P2881 -u用户名@租户名 -p

注意：

直连时 -u 应是 用户名@租户名
不要在直连用户名里带集群名，否则可能报错
普通租户直连时，目标节点上需要有该租户资源

通过 ODP/OBProxy（默认端口常为 2883）

mysql -h<odp_ip> -P2883 -u用户名@租户名#集群名 -p

用户名还可能写成：

集群名:租户名:用户名
集群名-租户名-用户名
集群名.租户名.用户名

这和 MySQL 的 root@'%' 完全不是同一套语义。

3. 客户端选择

可用 obclient
也可用 MySQL 客户端连接 MySQL 模式租户
官方文档提到当前支持的 MySQL 客户端版本包括 5.5 / 5.6 / 5.7（以你使用版本的文档为准）

六、从零上手：MySQL 同学 10 分钟路径

下面假设你已经能连上一个 MySQL 模式租户。

1. 看有哪些库

SHOW DATABASES;

体验环境里常见会看到 oceanbase、test、information_schema、mysql 等。

2. 创建业务库

CREATE DATABASE demo DEFAULT CHARACTER SET utf8mb4 READ WRITE;
USE demo;

这和 MySQL 非常像。

3. 建表、写入、查询

CREATE TABLE users (
 id INT PRIMARY KEY,
 name VARCHAR(64) NOT NULL,
 created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (id, name) VALUES
 (1, 'alice'),
 (2, 'bob');

SELECT id, name FROM users WHERE id = 1;
UPDATE users SET name = 'alice2' WHERE id = 1;
DELETE FROM users WHERE id = 2;

官方 MySQL 模式基础文档也覆盖了：

CREATE DATABASE / SHOW DATABASES
CREATE TABLE / SHOW TABLES / SHOW CREATE TABLE
ALTER TABLE
INSERT / UPDATE / DELETE / TRUNCATE
多表查询、聚合、EXPLAIN 等

4. 看建表细节时的“OceanBase 味道”

在 OceanBase 里执行：

SHOW CREATE TABLE users\G

你可能会看到比 MySQL 更“重”的表属性，例如副本数、压缩、Tablet 相关参数等。
这说明：SQL 表面兼容，元数据与存储参数并不等同于 InnoDB。

七、兼容性：像 MySQL，但不是 100% MySQL

官方《与 MySQL 兼容性对比》说明：

OceanBase 的 MySQL 模式兼容 MySQL 5.7/8.0 的绝大部分功能和语法；因架构差异或需求优先级，部分功能未支持。

1. 相似度高的部分

通常对应用最友好的部分：

常见数值 / 时间 / 字符 / JSON 等数据类型
SELECT / INSERT / UPDATE / DELETE
多表连接、子查询、聚合分组
存储过程、函数、触发器等大部分 PL 能力
information_schema、mysql 中的大量视图（但不是逐列完全等价）

因此：

很多基于 MySQL 协议的驱动可直接连
简单 CRUD 业务迁移门槛较低
你会有“这不就是 MySQL 吗”的错觉

2. 必须注意的差异

官方明确提到的差异方向包括：

类别	差异点
SQL 语法	例如不支持 `SELECT ... FOR SHARE ...`
TRUNCATE	不支持在事务处理与表锁定过程中操作
系统视图	不保证所有视图/列含义都与 MySQL 相同
存储引擎	不是 InnoDB 插件体系，而是自研分布式存储事务体系
优化器	执行计划与优化策略不同
分区 / 备份恢复	能力模型与操作路径不同
架构相关功能	因分布式架构，部分单机 MySQL 习惯不能照搬

3. 实战迁移建议

从 MySQL 迁到 OceanBase 时，不要只做“能不能连上”：

先验证协议层：驱动、连接池、ORM
再验证 SQL 层：慢 SQL、锁、事务边界、分页、HINT
再验证运维层：备份恢复、监控指标、扩缩容、租户资源
最后验证边界语法：冷门函数、系统表、复制相关特性、特定锁语法

一句话：

兼容的是“MySQL 使用体验”，不是“MySQL 内核实现”。

八、对象模型对比：database 相同，边界不同

MySQL

Instance
 └── Database
 └── Table / View / Procedure

权限、连接、资源，常常都围绕“实例 + 账号”展开。

OceanBase

Cluster
 └── Tenant（资源与权限边界更强）
 └── Database
 └── Table / Index / Procedure
 └── sys 租户（集群元数据）

对 MySQL 同学最实用的迁移记忆：

你在 MySQL 想做的事	在 OceanBase 更常见的对应
新建一个业务实例	新建一个业务租户
在实例里建库	在租户里 `CREATE DATABASE`
给业务分配 CPU/内存	调整 Unit Config / Resource Pool
连业务库	连 `user@tenant`
做高可用	规划 Zone / 副本 / 主备切换，而不是只配主从

九、一个最小对比实验（帮助真正理解差异）

实验 A：同一套 CRUD

在 OceanBase MySQL 模式租户执行：

CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4;
USE shop;

CREATE TABLE orders (
 order_id BIGINT PRIMARY KEY,
 user_id BIGINT NOT NULL,
 amount DECIMAL(10,2) NOT NULL,
 status VARCHAR(16) NOT NULL
);

INSERT INTO orders VALUES
 (1001, 1, 19.90, 'PAID'),
 (1002, 2, 39.00, 'CREATED');

SELECT * FROM orders WHERE status = 'PAID';

你会发现：
如果只看 SQL，这和 MySQL 几乎没区别。

实验 B：连接串差异

MySQL：

mysql -h127.0.0.1 -P3306 -uroot -p shop

OceanBase 直连某租户：

mysql -h127.0.0.1 -P2881 -uroot@test -p shop

OceanBase 经 ODP：

mysql -h127.0.0.1 -P2883 -uroot@test#cluster_name -p shop

你会发现：
真正拉开差距的，是“你连到了哪里”和“资源边界在哪里”。

实验 C：多租户隔离

在 sys 中创建两个业务租户后：

root@tenant1 里建表
root@tenant2 里看不到那张表

官方多租户示例正是用这种方式证明：
租户之间资源、数据、权限隔离。

这比 MySQL 里“两个 database 互相授权”要更接近“两个实例”。

十、什么时候适合用 OceanBase，什么时候继续 MySQL

更适合考虑 OceanBase 的场景

需要水平扩展，单机 MySQL + 分库分表成本高
需要更强的金融级高可用与多副本一致性
希望一套系统兼顾 TP 与部分 AP
多业务要强隔离，但又想统一运维平台（多租户）
已有大量 MySQL 协议应用，希望降低改造成本

更适合继续 MySQL 的场景

单机或轻量业务，数据量和可用性要求不高
团队只熟悉传统 mysqld 运维，短期不想引入分布式复杂度
深度依赖某些 MySQL 专有行为 / 插件 / 生态工具且未验证兼容
本地开发只需要极轻量依赖（虽然也可用 OceanBase Docker，但 MySQL 更轻）

十一、学习路线建议

如果你是 MySQL 背景，建议按这个顺序学：

先跑起来：Docker / obd demo
先会连：user@tenant、2881 / 2883
先当 MySQL 用：建库建表 CRUD
再学租户与资源：Unit / Resource Pool / sys 与普通租户
再学分布式：分区、副本、Zone、OBProxy 路由
最后做迁移评估：兼容性清单 + 压测 + 备份恢复演练

配套阅读：

本站另一篇：OceanBase 多平台搭建教程
官方 MySQL 兼容性文档
官方系统架构与多租户文档

十二、速查对照表

主题	MySQL	OceanBase
默认连接	`root@host:3306`	`root@tenant@host:2881` 或经 ODP `2883`
业务隔离	database / 多实例	tenant
管理入口	实例管理员	常先登 `sys` 做集群与租户管理
扩展	加配 / 分库分表	分区 + 多节点 + 资源单元
高可用	复制拓扑	Multi-Paxos 多副本
SQL 习惯	原生 MySQL	高度兼容，但要做差异验证
社区版模式	MySQL	仅 MySQL 模式

总结

OceanBase 对 MySQL 同学并不“难在 SQL”，而难在换模型：

把“实例”理解升级成“集群 + 租户”
把“连上 mysqld”升级成“连上正确的租户入口”
把“兼容 MySQL”理解成“协议与常用 SQL 友好，不等于内核相同”
先用 CRUD 建立信心，再用租户、分区、副本理解它的分布式能力

掌握这四步后，你就不会再把 OceanBase 误当成“换了皮的 MySQL”，也能更准确判断它该用在什么地方。

参考资料

OceanBase 官方仓库 README（中英文，MySQL 兼容与快速开始）：https://github.com/oceanbase/oceanbase
OceanBase 官方文档：系统架构（oceanbase-doc / V4.3.5）
OceanBase 官方文档：与 MySQL 兼容性对比
OceanBase 官方文档：SQL 基础操作（MySQL 模式）
OceanBase 官方文档：体验多租户特性
OceanBase 官方文档：通过 MySQL 客户端连接 OceanBase 租户
OceanBase Docker 镜像：https://hub.docker.com/r/oceanbase/oceanbase-ce
OceanBase 中文文档中心：https://www.oceanbase.com/docs/oceanbase-database-cn

MySQL InnoDB 事务隔离级别与 MVCC：原理、可见性与工程实践

Tue, 14 Jul 2026 00:00:00 +0800

在业务代码里，很多人把「开事务」当成理所当然：BEGIN → 几条 SQL → COMMIT。线上一旦出现脏数据、重复扣减、偶发死锁，第一反应却是「加锁」或「把隔离级别调高」。其实 InnoDB 的默认行为已经是一套完整的 多版本并发控制（MVCC）+ 行级锁 组合；真正关键的是：读走快照还是走加锁读、当前隔离级别如何决定可见性与间隙锁。

本文基于 MySQL 官方手册中的隔离级别、多版本、一致性非锁定读、间隙锁/next-key 与死锁说明，梳理可复用的原理与工程实践，而不是版本变更清单。

问题背景：并发事务到底在“打架”什么

SQL 标准用隔离级别描述并发下的异常现象（脏读、不可重复读、幻读）。InnoDB 实现了标准里的四级隔离：

隔离级别	典型问题	InnoDB 要点（官方行为）
READ UNCOMMITTED	脏读	普通 `SELECT` 可能读到「更早版本」的行，读本身不一致
READ COMMITTED	不可重复读、幻读	每次一致性读使用新快照；锁定读通常只锁记录、不锁间隙
REPEATABLE READ（默认）	幻读在加锁读路径上被抑制	事务内普通一致性读复用首次读建立的快照；范围锁定读使用 gap/next-key
SERIALIZABLE	最强串行语义	在 `autocommit` 关闭时，普通 `SELECT` 隐式变为 `SELECT ... FOR SHARE`

默认是 REPEATABLE READ。很多团队在迁移自 Oracle 等库时会改成 READ COMMITTED，这会显著改变锁与幻读行为——必须按业务场景评估，而不是「听说更像 Oracle 就改」。

核心原理：MVCC 如何让读不挡写

行上的隐藏字段与 undo

InnoDB 是多版本存储引擎：被修改行的旧版本信息保存在 undo 表空间 / 回滚段 中，用于：

事务回滚时做 undo
一致性读时构造「更早版本的行」

官方文档指出，InnoDB 会在每行内部维护（概念上）这些字段：

DB_TRX_ID（6 字节）：最近一次插入或更新该行的事务 ID；删除在内部也视作更新，并打上删除标记
DB_ROLL_PTR（7 字节）：回滚指针，指向 undo log，从而能重建更新前的行内容
DB_ROW_ID（6 字节）：单调递增的行 ID；仅在没有合适主键、需要自动生成聚簇索引时进入索引结构

undo 又分为 insert undo 与 update undo：insert undo 在事务提交后即可丢弃；update undo 还要服务一致性读，只有当不再存在「可能需要该历史版本」的读视图事务时，才能清理。这也是「长事务拖垮 undo / 历史版本膨胀」的根因。

一致性非锁定读（Consistent Nonlocking Read）

在 READ COMMITTED 与 REPEATABLE READ 下，普通 SELECT 默认走 一致性读：

查询看到某个时间点之前已提交事务所做的修改
看不到之后提交或未提交事务的修改
例外：同一事务内更早语句自己写过的变更，当前事务能看见

一致性读 不在表上加读锁，因此其他会话可以同时改这些表——这就是 MVCC 带来的读写并发。

快照时机是理解 RR / RC 差异的关键：

REPEATABLE READ：事务内第一次一致性读建立快照，后续普通 SELECT 复用同一快照，彼此一致
READ COMMITTED：事务内每一次一致性读都建立并读取新的快照

因此在 RR 下，「同一事务里两次 SELECT 结果一样」是默认语义；在 RC 下，「读到别人已提交的新数据」是默认语义。

官方还特别提醒：快照主要作用于事务内的 SELECT，不一定约束 UPDATE/DELETE 的目标行集合。在 RR 中可能出现：

-- 会话 A：REPEATABLE READ
SELECT COUNT(*) FROM t1 WHERE c1 = 'xyz'; -- 0
DELETE FROM t1 WHERE c1 = 'xyz'; -- 却可能删掉其他事务刚提交的多行
SELECT COUNT(*) FROM t1 WHERE c1 = 'xyz'; -- 仍可能是 0（普通 SELECT 仍看旧快照）

也就是说：写路径看到的是“当前最新可提交状态 + 锁”，读路径在 RR 下仍可能停在旧快照。混用「普通 SELECT 决策 + DML」时，要意识到二者语义不同；需要当前读时用 SELECT ... FOR UPDATE / FOR SHARE。

加锁读与间隙：幻读如何被挡住

普通 SELECT 是快照读；下列语句是 locking read / 当前读：

SELECT ... FOR UPDATE / SELECT ... FOR SHARE
UPDATE / DELETE（以及会读取并锁定目标行的 DML）

在 REPEATABLE READ 下（官方）：

唯一索引 + 唯一等值条件：通常只锁住找到的索引记录，不锁前面的 gap
其他搜索条件（范围、非唯一等）：扫描范围内使用 gap lock 或 next-key lock，阻止其他会话向间隙中插入

Next-key lock = 索引记录锁 + 该记录之前间隙上的 gap lock。官方用幻读例子说明：若只锁已有记录、不锁间隙，其他事务可在范围中间插入新行，导致同一事务再次查询出现「幻影行」。InnoDB 通过 next-key 算法抑制这类插入。

在 READ COMMITTED 下（官方）：

锁定读一般只锁 index record，不锁 gap，因此允许在已锁记录旁插入新行
gap 锁主要用于外键检查与重复键检查
因为 gap 锁关闭，可能出现幻读
另有工程意义：UPDATE/DELETE 对 不匹配 WHERE 的行 会在评估后释放锁，死锁概率通常更低；但死锁仍可能发生

SERIALIZABLE 不是「神秘黑盒」

官方定义很明确：SERIALIZABLE 类似 REPEATABLE READ，但当 autocommit 关闭 时，InnoDB 会把普通 SELECT 隐式转换成 SELECT ... FOR SHARE。若 autocommit 开启，单条 SELECT 本身就是只读事务，可走一致性非锁定读而不必阻塞。

因此：

想用 SERIALIZABLE 做「读也要挡住别人改」：确保在显式事务中（关闭 autocommit）
它会显著增加锁竞争，只适合 XA、强一致性专项场景，不适合默认全库开启

实践：如何查看、设置与正确选用

查看与设置隔离级别

-- 查看（MySQL 8 推荐系统变量）
SELECT @@GLOBAL.transaction_isolation, @@SESSION.transaction_isolation;

-- 仅影响下一笔未开始的事务
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 影响当前会话后续事务
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 影响新连接的默认（需权限）
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

也可在配置文件中设置服务端默认：

[mysqld]
transaction-isolation = READ-COMMITTED

（选项值使用连字符形式，如 REPEATABLE-READ。）

访问模式还可设为 READ ONLY / READ WRITE，只读事务有助于引擎做优化，适合报表会话。

业务选型建议（工程向）

默认保持 REPEATABLE READ
- 账户余额校验 + 扣减、库存预占、需要「事务内多次普通读一致」的流程更自然
- 范围更新/删除配合索引时，要注意 gap/next-key 带来的插入阻塞
高并发、写多读多、能接受「读到最新已提交」时考虑 READ COMMITTED
- 常见于互联网业务减少间隙锁、降低死锁
- 必须接受：同一事务内两次普通读可能不同；幻读可能发生
- 官方要求 RC 下二进制日志实质走 row-based（MIXED 时会自动切 row）
需要「读到的行在事务期间不被别人改」
- 不要只靠普通 SELECT 的 RR 快照（别人仍可改，你只是看不见）
- 使用 SELECT ... FOR UPDATE（要改）或 FOR SHARE（共享读）明确当前读
避免长事务
- 官方建议即使是只做一致性读的事务也要及时提交，否则 update undo 无法回收，回滚段膨胀
- 长事务还会拉长锁持有时间，放大死锁与锁等待

可复现的小实验（建议在测试库）

准备：

CREATE TABLE account (
 id INT PRIMARY KEY,
 balance INT NOT NULL
) ENGINE=InnoDB;
INSERT INTO account VALUES (1, 100), (2, 200);

实验 A：RR 下快照读

-- 会话 1
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT balance FROM account WHERE id = 1; -- 100

-- 会话 2
UPDATE account SET balance = 90 WHERE id = 1;
COMMIT;

-- 会话 1
SELECT balance FROM account WHERE id = 1; -- 仍为 100（复用首次快照）
COMMIT;
SELECT balance FROM account WHERE id = 1; -- 提交后新事务可见 90

实验 B：需要当前读时加锁

START TRANSACTION;
SELECT balance FROM account WHERE id = 1 FOR UPDATE; -- 当前读 + X 锁
-- 业务校验 balance >= 10 后再扣减
UPDATE account SET balance = balance - 10 WHERE id = 1;
COMMIT;

实验 C：范围条件与插入阻塞（RR）

-- 会话 1
START TRANSACTION;
SELECT * FROM account WHERE id >= 1 FOR UPDATE; -- 范围 + next-key/gap

-- 会话 2
INSERT INTO account VALUES (3, 50); -- 往往会等待会话 1 提交

把 FOR UPDATE 换成普通 SELECT 时，会话 2 通常可以插入（快照读不加锁），这能直观区分「看不见」和「锁住」。

常见坑与排查

1. 用普通 SELECT 做决策，却期望互斥

快照读不互斥。库存/余额扣减必须：

事务内 SELECT ... FOR UPDATE 再更新，或
直接条件更新并检查影响行数：UPDATE ... WHERE id=? AND balance>=?

仅靠 RR 的「两次 SELECT 一样」不能防止超卖。

2. 唯一等值 vs 范围：锁范围差很多

官方写明：RR 下唯一索引等值命中通常只锁记录；范围或非唯一条件会锁间隙。排查「插入被堵住」时，先看 SQL 是否走了范围扫描、索引是否合适。

3. RR 下「SELECT 看不到，DELETE 却删到了」

这是官方明确描述过的快照读与 DML 当前读差异，不是玄学 bug。审计日志或对账逻辑要按「语句类型」理解可见性。

4. 死锁：隔离级别救不了写写冲突

官方指出：死锁可能性与隔离级别无直接关系——隔离级别主要改读行为，而死锁来自写锁互相等待。处理要点：

保持默认死锁检测开启（innodb_deadlock_detect）
死锁发生时 InnoDB 会回滚其中一个事务（victim），应用必须可重试
关闭检测时依赖 innodb_lock_wait_timeout，代价是更长的等待
用 SHOW ENGINE INNODB STATUS 查看最近一次死锁
工程上：固定多表/多行加锁顺序、缩短事务、给 WHERE 列建合适索引

5. 历史版本与「undo 涨爆」

长查询、忘记提交的会话、超大事务都会让 update undo 滞留。监控 undo 表空间、历史列表长度，并在应用层强制事务超时/连接回收。

6. 混用锁定读与非锁定读

官方不建议在同一 RR 事务里混用大量「普通 SELECT」与 UPDATE/SELECT ... FOR UPDATE，因为二者看到的状态基准不同，逻辑难推理；若目标接近串行，应显式使用加锁读或评估 SERIALIZABLE。

总结

InnoDB 默认 REPEATABLE READ，普通读靠 MVCC 快照，写与加锁读靠 行锁 +（RR 下）gap/next-key。
RC 每次一致性读换新快照、锁定读基本不锁 gap，并发更好但幻读与不可重复读更易出现。
SERIALIZABLE 在关闭 autocommit 时把普通 SELECT 变成 FOR SHARE，代价是锁竞争。
工程上优先：短事务、正确索引、该当前读就 FOR UPDATE、死锁可重试；不要把「提高隔离级别」当成唯一药方。
理解「快照读 vs 当前读」比背诵四个级别名称更能减少线上数据竞争事故。

参考资料

MySQL 8.4 Reference Manual — Transaction Isolation Levels
MySQL 8.0 Reference Manual（Oracle Docs）— InnoDB Multi-Versioning
MySQL 8.0 Reference Manual — Consistent Nonlocking Reads
MySQL 8.0 Reference Manual — InnoDB Locking
MySQL 8.0 Reference Manual — Phantom Rows
MySQL 8.0 Reference Manual — Deadlocks in InnoDB
MySQL 8.0 Reference Manual — SET TRANSACTION Statement
MariaDB Knowledge Base — SET TRANSACTION（辅助对照 InnoDB 兼容实现）

MySQL深度调优实战：从SQL到架构的全面优化

Fri, 26 Jun 2026 17:00:00 +0000

前言

MySQL 是最流行的关系型数据库之一，但在生产环境中，性能问题往往是开发和运维面临的最大挑战。本文将从 SQL 优化、索引设计、配置调优、架构优化四个维度，全面介绍 MySQL 性能调优的实战技巧。

一、SQL 优化

1.1 EXPLAIN 执行计划分析

EXPLAIN SELECT * FROM users WHERE age > 25 AND city = 'Beijing';

关键字段说明：

字段	说明	优化目标
type	访问类型	至少达到 range 级别
key	使用的索引	避免 NULL
rows	扫描行数	越小越好
Extra	额外信息	避免 Using filesort/temporary

type 访问类型（从好到差）：

system > const > eq_ref > ref > range > index > ALL

1.2 索引优化技巧

最左前缀原则

-- 联合索引 (a, b, c)
-- ✅ 命中索引
SELECT * FROM table WHERE a = 1;
SELECT * FROM table WHERE a = 1 AND b = 2;
SELECT * FROM table WHERE a = 1 AND b = 2 AND c = 3;

-- ❌ 无法使用索引
SELECT * FROM table WHERE b = 2;
SELECT * FROM table WHERE c = 3;
SELECT * FROM table WHERE b = 2 AND c = 3;

覆盖索引

-- 创建覆盖索引
ALTER TABLE users ADD INDEX idx_name_age (name, age);

-- 查询只需要索引字段，无需回表
SELECT name, age FROM users WHERE name = 'John';

索引失效场景

-- ❌ 函数操作
SELECT * FROM users WHERE YEAR(create_time) = 2024;
-- ✅ 改为范围查询
SELECT * FROM users WHERE create_time >= '2024-01-01' 
 AND create_time < '2025-01-01';

-- ❌ 隐式类型转换
SELECT * FROM users WHERE phone = 13800138000;
-- ✅ 类型匹配
SELECT * FROM users WHERE phone = '13800138000';

-- ❌ LIKE 左模糊
SELECT * FROM users WHERE name LIKE '%John';
-- ✅ 前缀匹配
SELECT * FROM users WHERE name LIKE 'John%';

-- ❌ OR 条件
SELECT * FROM users WHERE age = 25 OR name = 'John';
-- ✅ 使用 UNION
SELECT * FROM users WHERE age = 25
UNION
SELECT * FROM users WHERE name = 'John';

1.3 查询优化

分页查询优化

-- ❌ 慢查询（深分页）
SELECT * FROM orders ORDER BY id LIMIT 1000000, 10;

-- ✅ 延迟关联
SELECT o.* FROM orders o
INNER JOIN (
 SELECT id FROM orders ORDER BY id LIMIT 1000000, 10
) t ON o.id = t.id;

-- ✅ 游标分页
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 10;

JOIN 优化

-- 确保关联字段有索引
ALTER TABLE orders ADD INDEX idx_user_id (user_id);

-- 小表驱动大表
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

子查询优化

-- ❌ 子查询
SELECT * FROM orders WHERE user_id IN (
 SELECT id FROM users WHERE status = 1
);

-- ✅ JOIN 优化
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

二、索引设计原则

2.1 索引设计规范

-- 1. 选择区分度高的列
SELECT 
 COUNT(DISTINCT city) / COUNT(*) AS selectivity
FROM users;
-- 区分度 > 0.1 才考虑建索引

-- 2. 联合索引字段顺序
-- 区分度高的字段在前
-- 查询频率高的字段在前
-- 排序字段在最后

-- 3. 避免过多索引
-- 每张表索引不超过 5 个
-- 单个索引字段不超过 5 个

2.2 索引监控

-- 查看索引使用情况
SELECT 
 object_schema,
 object_name,
 index_name,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
ORDER BY count_read DESC;

-- 查看未使用的索引
SELECT 
 object_schema,
 object_name,
 index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
 AND index_name IS NOT NULL
 AND count_star = 0;

三、配置调优

3.1 InnoDB Buffer Pool

# my.cnf
[mysqld]
# Buffer Pool 大小，建议物理内存的 70-80%
innodb_buffer_pool_size = 8G

# Buffer Pool 实例数，减少锁竞争
innodb_buffer_pool_instances = 8

# Buffer Pool 预热
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

3.2 日志配置

[mysqld]
# Redo Log 大小
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# 刷盘策略
# 1：每次提交都刷盘（最安全）
# 2：每次提交写入OS缓存
# 0：每秒刷盘
innodb_flush_log_at_trx_commit = 1

# 双1配置（生产推荐）
sync_binlog = 1

3.3 连接配置

[mysqld]
# 最大连接数
max_connections = 500

# 连接超时
wait_timeout = 600
interactive_timeout = 600

# 线程缓存
thread_cache_size = 64

# 表缓存
table_open_cache = 4096
table_definition_cache = 2048

3.4 查询缓存（MySQL 8.0 已移除）

# MySQL 5.7 及以下
[mysqld]
query_cache_type = 0 # 建议关闭
query_cache_size = 0

3.5 排序和临时表

[mysqld]
# 排序缓冲区
sort_buffer_size = 4M

# JOIN 缓冲区
join_buffer_size = 4M

# 临时表大小
tmp_table_size = 64M
max_heap_table_size = 64M

# 读缓冲区
read_buffer_size = 2M
read_rnd_buffer_size = 8M

四、架构优化

4.1 读写分离

 ┌─────────────┐
 │ 应用程序 │
 └──────┬──────┘
 │
 ┌──────▼──────┐
 │ 代理层 │
 │ (ProxySQL) │
 └──────┬──────┘
 │
 ┌──────────────┼──────────────┐
 │ │ │
 ┌──────▼──────┐ ┌────▼────┐ ┌───────▼──────┐
 │ Master │ │ Slave 1 │ │ Slave 2 │
 │ (写) │ │ (读) │ │ (读) │
 └─────────────┘ └─────────┘ └──────────────┘

ProxySQL 配置示例：

-- 添加后端MySQL服务器
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, '10.0.0.1', 3306), -- 写组
(20, '10.0.0.2', 3306), -- 读组
(20, '10.0.0.3', 3306); -- 读组

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup) VALUES
(1, '^SELECT.*FOR UPDATE', 10), -- 写操作
(2, '^SELECT', 20); -- 读操作

4.2 分库分表

垂直分库

用户库 (user_db)
├── users
├── user_profiles
└── user_settings

订单库 (order_db)
├── orders
├── order_items
└── payments

商品库 (product_db)
├── products
├── categories
└── inventory

水平分表

-- 按用户ID分表
orders_0 -- user_id % 4 = 0
orders_1 -- user_id % 4 = 1
orders_2 -- user_id % 4 = 2
orders_3 -- user_id % 4 = 3

-- ShardingSphere 配置
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.sharding.tables.orders.actual-data-nodes=ds$->{0..1}.orders_$->{0..3}
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.algorithm-expression=orders_$->{user_id % 4}

4.3 缓存策略

┌──────────┐ ┌──────────┐ ┌──────────┐
│ 应用程序 │───▶│ Redis │───▶│ MySQL │
└──────────┘ └──────────┘ └──────────┘
 │ │ │
 │ 1.查询缓存 │ │
 │──────────────▶│ │
 │ 2.返回缓存 │ │
 │◀──────────────│ │
 │ │ │
 │ 3.缓存未命中│ │
 │──────────────────────────────▶│
 │ 4.查询数据库│ │
 │◀──────────────────────────────│
 │ │ │
 │ 5.写入缓存 │ │
 │──────────────▶│ │

缓存更新策略：

// Cache Aside Pattern
public User getUser(Long userId) {
 // 1. 先查缓存
 String key = "user:" + userId;
 User user = redis.get(key);
 if (user != null) {
 return user;
 }
 
 // 2. 缓存未命中，查数据库
 user = userMapper.selectById(userId);
 if (user != null) {
 // 3. 写入缓存
 redis.setex(key, 3600, user);
 }
 return user;
}

4.4 表设计优化

-- 1. 选择合适的数据类型
-- ❌ 不推荐
CREATE TABLE users (
 id BIGINT,
 name VARCHAR(1000),
 age INT,
 status VARCHAR(20)
);

-- ✅ 推荐
CREATE TABLE users (
 id BIGINT UNSIGNED AUTO_INCREMENT,
 name VARCHAR(50) NOT NULL,
 age TINYINT UNSIGNED,
 status TINYINT NOT NULL DEFAULT 1,
 PRIMARY KEY (id),
 INDEX idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 避免NULL
-- 使用 NOT NULL + DEFAULT

-- 3. 主键设计
-- 使用自增ID作为主键
-- 避免使用UUID作为主键（无序，影响插入性能）

五、监控与诊断

5.1 慢查询日志

[mysqld]
# 开启慢查询日志
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 超过1秒记录
log_queries_not_using_indexes = ON

# 分析慢查询日志
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 使用 pt-query-digest
pt-query-digest /var/log/mysql/slow.log > slow_report.txt

5.2 性能监控SQL

-- 查看当前连接
SHOW PROCESSLIST;

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS;

-- 查看表大小
SELECT 
 table_schema,
 table_name,
 ROUND(data_length / 1024 / 1024, 2) AS data_mb,
 ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'your_database'
ORDER BY data_length DESC;

-- 查看索引使用统计
SELECT 
 object_schema,
 object_name,
 index_name,
 count_star,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database';

5.3 诊断工具

# Percona Toolkit
# 安装
apt install percona-toolkit

# 分析慢查询
pt-query-digest /var/log/mysql/slow.log

# 检查重复/冗余索引
pt-duplicate-key-checker --host=localhost --user=root --password=xxx

# 查看索引使用情况
pt-index-usage --host=localhost --user=root --password=xxx /var/log/mysql/slow.log

六、调优清单

6.1 SQL 层面

所有查询都使用了合适的索引
避免了 SELECT *，只查询需要的字段
分页查询使用了延迟关联
避免了深分页（LIMIT offset 过大）
JOIN 查询关联字段有索引
避免了索引失效的写法

6.2 索引层面

高频查询字段都有索引
联合索引遵循最左前缀原则
区分度低的字段不建索引
定期清理未使用的索引
使用覆盖索引减少回表

6.3 配置层面

Buffer Pool 设置为物理内存的 70-80%
开启慢查询日志
设置合理的连接数
配置合适的日志刷盘策略

6.4 架构层面

读写分离（读多写少场景）
分库分表（数据量大场景）
引入缓存层（热点数据）
表设计规范化

总结

MySQL 调优是一个系统工程，需要从多个维度综合考虑：

SQL 优化是基础：写好 SQL 是最直接的优化手段
索引设计是核心：合理的索引能提升查询性能数倍
配置调优是保障：正确的配置能最大化硬件利用率
架构优化是根本：当单机瓶颈时，架构扩展是必由之路

建议按照本文的调优清单逐步检查，结合监控数据持续优化。

2025 Java MySQL 面试高频题汇总

Thu, 25 Jun 2026 10:05:00 +0000

前言

本文整理了 2025 年 Java 后端开发面试中 MySQL 相关的高频考点，涵盖索引优化、事务隔离、锁机制、SQL 调优等核心内容，帮助候选人系统复习、高效备战。

一、MySQL 索引相关

1.1 为什么 MySQL 使用 B+ 树而不是 B 树？

B+ 树叶子节点形成有序链表，范围查询效率更高
非叶子节点只存储索引，单个页能容纳更多索引，树高更矮，IO 次数更少
所有查询都落到叶子节点，查询性能稳定

1.2 聚簇索引和非聚簇索引的区别？

特性	聚簇索引	非聚簇索引（二级索引）
数据存储	叶子节点存储完整数据行	叶子节点存储主键值
查询方式	直接获取数据	需要回表查询
数量限制	一张表只有一个	可以有多个

1.3 什么是覆盖索引？

覆盖索引是指查询的列全部在索引中，不需要回表查询主键索引就能获取数据，显著提升查询性能。

-- 假设有联合索引 idx_name_age(name, age)
SELECT name, age FROM user WHERE name = '张三';
-- 此查询走覆盖索引，无需回表

1.4 索引失效的常见场景

使用 LIKE '%xxx' 左模糊查询
对索引列使用函数或表达式
隐式类型转换
使用 OR 连接非索引列
联合索引未遵循最左前缀原则
NOT IN、NOT EXISTS、!=、<> 可能导致失效

二、事务与隔离级别

2.1 事务的 ACID 特性

A（原子性）：undo log 实现，事务要么全部成功，要么全部回滚
C（一致性）：由其他三个特性共同保证
I（隔离性）：锁机制 + MVCC 实现
D（持久性）：redo log 实现

2.2 四种隔离级别

隔离级别	脏读	不可重复读	幻读
READ UNCOMMITTED	✓	✓	✓
READ COMMITTED	✗	✓	✓
REPEATABLE READ（默认）	✗	✗	✗*
SERIALIZABLE	✗	✗	✗

InnoDB 在 RR 级别下通过 MVCC + Next-Key Lock 解决了大部分幻读问题。

2.3 MVCC 实现原理

MVCC（多版本并发控制）通过以下机制实现：

隐藏列：每行数据包含 DB_TRX_ID（事务ID）、DB_ROLL_PTR（回滚指针）
undo log：形成版本链
Read View：根据事务启动时机判断可见性

RC 与 RR 的区别：RC 每次查询生成新的 Read View，RR 只在事务第一次查询时生成。

三、锁机制

3.1 InnoDB 锁类型

共享锁（S Lock）：读锁，多个事务可共享
排他锁（X Lock）：写锁，互斥
意向锁（IS/IX）：表级锁，标识事务意图
间隙锁（Gap Lock）：锁定索引间隙，防止幻读
临键锁（Next-Key Lock）：记录锁 + 间隙锁，左开右闭区间

3.2 死锁如何产生和解决？

产生条件：两个或多个事务互相等待对方持有的锁。

排查方法：

SHOW ENGINE INNODB STATUS; -- 查看最近死锁信息
SELECT * FROM information_schema.INNODB_TRX; -- 查看当前事务

解决方案：

按固定顺序访问表和行
大事务拆小事务
设置合理的锁等待超时 innodb_lock_wait_timeout
使用低隔离级别（业务允许时）

四、SQL 优化

4.1 EXPLAIN 执行计划关键字段

EXPLAIN SELECT * FROM user WHERE name = '张三';

重点关注字段：

type：访问类型，性能从好到差 system > const > eq_ref > ref > range > index > ALL
key：实际使用的索引
rows：预估扫描行数
Extra：Using index（覆盖索引）、Using filesort（文件排序）、Using temporary（临时表）

4.2 慢查询优化思路

开启慢查询日志定位问题 SQL
使用 EXPLAIN 分析执行计划
合理添加索引（遵循最左前缀原则）
避免 SELECT *，只查询需要的列
分页优化：深分页使用延迟关联

-- 深分页优化：先查主键再关联
SELECT * FROM user u
INNER JOIN (
 SELECT id FROM user ORDER BY id LIMIT 1000000, 10
) t ON u.id = t.id;

4.3 JOIN 优化

小表驱动大表
被驱动表关联字段加索引
避免 LEFT JOIN 时 ON 条件使用 OR

五、MySQL 架构

5.1 InnoDB 架构核心组件

Buffer Pool：缓存数据页和索引页
Change Buffer：缓存非唯一二级索引的写操作
Log Buffer：缓存 redo log
redo log：保证事务持久性（WAL 机制）
undo log：保证事务原子性，支持 MVCC

5.2 binlog、redo log、undo log 区别

特性	binlog	redo log	undo log
层级	Server 层	InnoDB 引擎	InnoDB 引擎
内容	逻辑日志	物理日志	逻辑日志
作用	主从复制、数据恢复	崩溃恢复	事务回滚、MVCC
写入方式	追加写入	循环写入	追加写入

5.3 两阶段提交（2PC）

为了保证 binlog 和 redo log 的一致性：

prepare 阶段：redo log 写入磁盘，标记为 prepare
commit 阶段：binlog 写入磁盘后，redo log 标记为 commit

六、高频场景题

6.1 分库分表方案

垂直分库：按业务拆分（订单库、用户库）
水平分表：按行拆分（取模、范围、时间）
常用中间件：ShardingSphere、MyCat

6.2 如何设计一个高并发的秒杀数据库方案？

热点数据缓存到 Redis
库存扣减使用 Redis 原子操作预扣
订单写入异步队列
数据库层面乐观锁更新
分库分表减少单表压力

-- 乐观锁扣减库存
UPDATE goods SET stock = stock - 1 
WHERE id = 1001 AND stock > 0;

总结

2025 年 Java MySQL 面试依然围绕 索引原理、事务隔离、锁机制、SQL 优化 四大核心主题展开。理解底层原理比死记硬背更重要，建议结合源码和实际项目经验深入学习。

推荐书籍：《高性能 MySQL》《MySQL 技术内幕：InnoDB 存储引擎》

达梦数据库 DM8 与 MySQL 差异全解析：迁移避坑指南

Wed, 24 Jun 2026 11:00:00 +0000

前言

随着国内信创（信息技术应用创新）政策的推进，越来越多的项目需要从 MySQL 迁移到国产数据库。达梦数据库（DM8） 是最主流的国产关系型数据库之一，兼容大部分 SQL 标准，但与 MySQL 在语法、函数、数据类型等方面仍存在不少差异。

本文从实际迁移角度出发，系统梳理 DM8 与 MySQL 的核心差异，帮助开发者少踩坑。

1. 架构差异

对比项	MySQL	达梦 DM8
数据库模型	单实例多数据库（`database`）	单数据库多 Schema（一个用户对应一个 Schema）
默认端口	3306	5236
存储引擎	InnoDB / MyISAM 等可选	单一存储引擎
大小写	默认不区分（可配置）	默认区分大小写
空字符串	`''` 和 `NULL` 是不同的	`''` 等同于 `NULL`

⚠️ 重点注意：DM8 中空字符串 '' 就是 NULL，这是迁移中最容易踩的坑。MySQL 中 WHERE col = '' 和 WHERE col IS NULL 结果完全不同，在 DM8 中两者等价。

2. 数据类型映射

2.1 数值类型

MySQL	DM8	说明
`TINYINT`	`TINYINT`	兼容
`SMALLINT`	`SMALLINT`	兼容
`MEDIUMINT`	`INT`	DM 无 MEDIUMINT
`INT`	`INTEGER`	兼容
`BIGINT`	`BIGINT`	兼容
`FLOAT`	`FLOAT`	兼容
`DOUBLE`	`DOUBLE` / `NUMBER`	建议用 DOUBLE
`DECIMAL(p,s)`	`NUMBER(p,s)`	精度一致

2.2 字符串类型

MySQL	DM8	说明
`CHAR(n)`	`CHAR(n)`	兼容
`VARCHAR(n)`	`VARCHAR2(n)`	DM 推荐用 VARCHAR2
`TEXT`	`CLOB`	大文本用 CLOB
`MEDIUMTEXT`	`CLOB`
`LONGTEXT`	`CLOB`
`ENUM`	`VARCHAR2`	DM 无 ENUM，存为字符串
`SET`	`VARCHAR2`	DM 无 SET

2.3 日期时间类型

MySQL	DM8	说明
`DATE`	`DATE`	MySQL 只存日期，DM 的 DATE 包含时间
`DATETIME`	`DATE` / `TIMESTAMP`	DM 的 DATE 就带时间
`TIMESTAMP`	`TIMESTAMP`
`TIME`	`TIME`	DM 支持 TIME 类型，可直接映射
`YEAR`	`CHAR(4)`	DM 无 YEAR 类型

2.4 其他类型

MySQL	DM8	说明
`BLOB`	`BLOB`	兼容
`JSON`	`CLOB` / `JSONB`（新版本）	旧版用 CLOB 存储
`BOOLEAN`	`BIT`
`AUTO_INCREMENT`	`IDENTITY(1,1)`	自增语法不同

3. 函数差异对照

这是迁移中改动量最大的部分。

3.1 字符串函数

MySQL	DM8	示例
`CONCAT(a, b)`	`a \|\| b` 或 `CONCAT(a, b)`	DM 推荐用 `\|\|`
`SUBSTRING(str, pos, len)`	`SUBSTR(str, pos, len)`	少了个 `ING`
`LOCATE(sub, str)`	`INSTR(str, sub)`	参数顺序相反
`GROUP_CONCAT(col)`	`LISTAGG(col, ',') WITHIN GROUP (ORDER BY col)`	语法差异大
`REPLACE(str, old, new)`	`REPLACE(str, old, new)`	兼容

3.2 日期函数

MySQL	DM8	示例
`NOW()`	`SYSDATE` 或 `CURRENT_TIMESTAMP`
`CURDATE()`	`CURRENT_DATE` 或 `SYSDATE`
`DATE_FORMAT(d, '%Y-%m-%d')`	`TO_CHAR(d, 'YYYY-MM-DD')`	格式化语法不同
`STR_TO_DATE(s, '%Y-%m-%d')`	`TO_DATE(s, 'YYYY-MM-DD')`
`DATE_ADD(d, INTERVAL 1 DAY)`	`d + 1` 或 `ADD_DAYS(d, 1)`
`DATE_SUB(d, INTERVAL 1 MONTH)`	`ADD_MONTHS(d, -1)`
`DATEDIFF(d1, d2)`	`d1 - d2`	DM 直接相减
`YEAR(d)`	`EXTRACT(YEAR FROM d)`
`MONTH(d)`	`EXTRACT(MONTH FROM d)`

3.3 条件与空值函数

MySQL	DM8	说明
`IF(cond, v1, v2)`	`CASE WHEN cond THEN v1 ELSE v2 END`	DM 无 IF 函数
`IFNULL(expr, default)`	`NVL(expr, default)`	也可用 COALESCE
`IFNULL` 多层嵌套	`COALESCE(a, b, c)`	推荐用 COALESCE

3.4 类型转换

MySQL	DM8	说明
`CONVERT(expr, type)`	`CONVERT(type, expr)`	参数顺序相反 ⚠️
`CAST(expr AS type)`	`CAST(expr AS type)`	兼容

4. SQL 语法差异

4.1 自增主键

-- MySQL
CREATE TABLE users (
 id BIGINT AUTO_INCREMENT PRIMARY KEY,
 name VARCHAR(100)
);

-- DM8
CREATE TABLE users (
 id BIGINT IDENTITY(1,1) PRIMARY KEY,
 name VARCHAR2(100)
);

4.2 分页查询

-- MySQL
SELECT * FROM users LIMIT 10 OFFSET 20;

-- DM8（兼容 LIMIT 或使用 ROWNUM）
SELECT * FROM users LIMIT 10 OFFSET 20;

-- DM8 传统写法
SELECT * FROM (
 SELECT t.*, ROWNUM rn FROM (
 SELECT * FROM users ORDER BY id
 ) t WHERE ROWNUM <= 30
) WHERE rn > 20;

DM8 较新版本已支持 LIMIT offset, count 语法，但 ROWNUM 仍是 DM 的保留关键字，不要用作列名。

4.3 多行插入

-- MySQL
INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

-- DM8
INSERT ALL
 INTO users (name) VALUES ('Alice')
 INTO users (name) VALUES ('Bob')
 INTO users (name) VALUES ('Charlie')
SELECT 1 FROM dual;

4.4 多表更新

-- MySQL
UPDATE t1, t2 SET t1.col = t2.col WHERE t1.id = t2.id;

-- DM8（使用 MERGE INTO）
MERGE INTO t1 USING t2 ON (t1.id = t2.id)
WHEN MATCHED THEN UPDATE SET t1.col = t2.col;

4.5 多表删除

-- MySQL
DELETE t1 FROM t1, t2 WHERE t1.id = t2.id AND t2.status = 0;

-- DM8
DELETE FROM t1 WHERE id IN (SELECT id FROM t2 WHERE status = 0);

4.6 修改列名

-- MySQL
ALTER TABLE users CHANGE name full_name VARCHAR(100);

-- DM8
ALTER TABLE users RENAME COLUMN name TO full_name;

4.7 删除列

-- MySQL
ALTER TABLE users DROP COLUMN age;

-- DM8
ALTER TABLE users DROP age;

5. GROUP BY 语义差异（重要！）

这是迁移中最容易出 bug 的地方。

5.1 MySQL 的宽松模式

MySQL 默认允许 SELECT 中出现未在 GROUP BY 中声明的非聚合列（ONLY_FULL_GROUP_BY 关闭时）：

-- MySQL 可以执行（但结果不确定）
SELECT id, name, COUNT(*) FROM users GROUP BY department;

5.2 DM8 的严格模式

DM8 严格执行 SQL 标准，SELECT 中的非聚合列必须出现在 GROUP BY 中：

-- DM8 必须这样写
SELECT department, COUNT(*) FROM users GROUP BY department;

5.3 GROUP BY 主键 ≠ DISTINCT

迁移时不要轻易把 GROUP BY id 改成 SELECT DISTINCT，当 JOIN 导致行数膨胀时，两者结果不同。

6. 其他语义陷阱

6.1 别名引用

-- MySQL：HAVING 可以引用 SELECT 别名
SELECT name AS alias_name, COUNT(*) AS cnt
FROM users GROUP BY alias_name HAVING cnt > 5;

-- DM8：HAVING 不能引用别名，必须用原始表达式
SELECT name AS alias_name, COUNT(*) AS cnt
FROM users GROUP BY name HAVING COUNT(*) > 5;

6.2 别名引号

-- MySQL：单引号
SELECT name AS '姓名' FROM users;

-- DM8：双引号
SELECT name AS "姓名" FROM users;

6.3 隐式类型转换

DM8 类型检查更严格，字符串列与数字比较会报错：

-- MySQL 可以执行（隐式转换）
SELECT * FROM users WHERE phone = 13800138000;

-- DM8 必须类型一致
SELECT * FROM users WHERE phone = '13800138000';

7. JDBC 连接配置

7.1 驱动配置

配置项	MySQL	DM8
驱动类	`com.mysql.cj.jdbc.Driver`	`dm.jdbc.driver.DmDriver`
JDBC URL	`jdbc:mysql://host:3306/db`	`jdbc:dm://host:5236`
默认端口	3306	5236

7.2 Hibernate / MyBatis 方言

# MySQL
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.jpa.database-platform=org.hibernate.dialect.MySQLDialect

# DM8
spring.datasource.driver-class-name=dm.jdbc.driver.DmDriver
spring.datasource.url=jdbc:dm://localhost:5236
spring.jpa.database-platform=dm.hibernate.dialect.DmDialect

7.3 指定 Schema

DM8 默认一个用户对应一个 Schema，连接时可以通过 JDBC 参数指定：

jdbc:dm://localhost:5236?schema=MY_SCHEMA

8. 建库注意事项

DM8 一个实例即对应一个数据库，字符集在实例初始化（dminit）阶段确定，之后不可更改，没有 MySQL 那样的 CREATE DATABASE ... CHARSET= 语句。务必在初始化时就选择 UTF-8：

# 初始化实例时指定字符集（CHARSET：0=GB18030，1=UTF-8，2=EUC-KR）
dminit PATH=/dm/data DB_NAME=mydb INSTANCE_NAME=mydb CHARSET=1 PAGE_SIZE=16

如果字符集选错，中文数据会出现乱码，且修改成本很高。

9. 迁移工具推荐

工具	方向	语言	特点
sql-dialect-adapter	MySQL ↔ DM	Java	SQL 方言自动转换，支持 6 个方向
MySQL2DM	MySQL → DM	Python	多线程数据迁移，自动类型映射
DM2MySQL	DM → MySQL	Go	企业级反向迁移工具
mysqltodmsqltransfer	MySQL → DM	Java	MyBatis 插件，运行时自动转换 SQL
DM 数据迁移工具 (DTS)	多种 → DM	GUI	达梦官方工具，图形化操作

10. 迁移检查清单

建库时选择 UTF-8 字符集
AUTO_INCREMENT 改为 IDENTITY(1,1)
VARCHAR 改为 VARCHAR2，TEXT 改为 CLOB
NOW() 改为 SYSDATE，DATE_FORMAT 改为 TO_CHAR
GROUP_CONCAT 改为 LISTAGG
IF() 改为 CASE WHEN
IFNULL() 改为 NVL()
检查所有 GROUP BY 语句是否符合严格模式
检查空字符串 '' 的业务逻辑（DM 中等同于 NULL）
检查隐式类型转换（字符串 vs 数字比较）
更新 JDBC 驱动和连接 URL
更新 ORM 方言配置（Hibernate / MyBatis）
测试分页查询是否兼容
测试多行 INSERT、多表 UPDATE/DELETE 语法