MariaDB Community Server 13.0 已进入 GA，意味着这一版本从试验阶段转为官方稳定版本。它的重点不只是增加若干 SQL 语法，而是同时推进 Oracle 兼容性、过程化 SQL、DML 能力、开发体验、可观测性和性能，并伴随需要升级团队注意的弃用项。
对于准备升级的团队，真正的问题不是“新版本能否启动”，而是现有存储过程、事务语义、查询计划和监控体系能否保持稳定。
Oracle 兼容性为何值得关注
增强 Oracle 兼容性，可以降低数据库迁移中最昂贵的一部分工作：过程化 SQL 和数据库端业务逻辑的重写。普通表结构和简单查询通常容易转换，存储过程、异常处理、游标、变量类型以及隐式类型转换才是迁移难点。
不过，“兼容性增强”并不等于 Oracle 应用可以不经验证直接切换。迁移时至少要检查：
- 存储过程、函数和触发器的语法与执行语义；
- 空字符串与
NULL的处理差异； - 日期、时间、字符集和排序规则；
- 数值精度及隐式类型转换；
- 序列、自增列和主键生成策略；
- 异常传播、事务提交和回滚边界；
- Oracle 专有包、提示语法及系统视图依赖。
建议把兼容模式看成迁移工具，而不是永久掩盖差异的开关。先让应用跑起来，再逐步把关键 SQL 改造成 MariaDB 原生且容易维护的形式。
过程化 SQL 与 DML：重点验证语义，而不只是语法
MariaDB 13 扩展了过程化 SQL 支持，并增加了 DML 能力。对开发者来说，这会影响批处理、数据修复脚本、存储过程以及复杂写入流程。
升级测试不能只运行一次 CREATE PROCEDURE。至少需要覆盖正常执行、重复数据、空结果、异常回滚和并发写入。下面是一个可以直接用于冒烟测试的过程化 SQL 示例。它使用通用 MariaDB 语法，目的是验证升级后的过程、事务与异常处理基线，而不是演示某个 MariaDB 13 独有语法。
CREATE DATABASE IF NOT EXISTS upgrade_lab;
USE upgrade_lab;
CREATE TABLE IF NOT EXISTS account_balance (
account_id BIGINT PRIMARY KEY,
balance DECIMAL(18, 2) NOT NULL,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
);
INSERT INTO account_balance (account_id, balance)
VALUES (1, 1000.00), (2, 500.00);
DELIMITER //
DROP PROCEDURE IF EXISTS transfer_money//
CREATE PROCEDURE transfer_money(
IN p_from BIGINT,
IN p_to BIGINT,
IN p_amount DECIMAL(18, 2)
)
BEGIN
DECLARE v_balance DECIMAL(18, 2);
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
RESIGNAL;
END;
START TRANSACTION;
SELECT balance INTO v_balance
FROM account_balance
WHERE account_id = p_from
FOR UPDATE;
IF v_balance < p_amount THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'insufficient balance';
END IF;
UPDATE account_balance
SET balance = balance - p_amount
WHERE account_id = p_from;
UPDATE account_balance
SET balance = balance + p_amount
WHERE account_id = p_to;
COMMIT;
END//
DELIMITER ;
CALL transfer_money(1, 2, 125.00);
SELECT * FROM account_balance ORDER BY account_id;
在预生产环境中，还应并发调用这个过程，确认行锁、死锁重试和事务隔离级别符合预期。数据库升级最危险的回归往往不是语法错误，而是语句仍能执行，却产生了不同的锁定范围或执行计划。
用容器搭建可重复的升级实验室
可以用独立容器运行 MariaDB 13，并将生产结构和脱敏数据导入其中。下面的 Compose 文件可作为起点；运行前应确认所用镜像仓库提供对应的 13.0 GA 标签，并替换示例密码。
services:
mariadb13:
image: mariadb:13.0
container_name: mariadb13-lab
environment:
MARIADB_ROOT_PASSWORD: change-this-password
MARIADB_DATABASE: upgrade_lab
ports:
- "3307:3306"
command:
- --performance-schema=ON
- --slow-query-log=ON
- --long-query-time=0.5
volumes:
- mariadb13_data:/var/lib/mysql
volumes:
mariadb13_data:
启动并连接：
docker compose up -d
docker exec -it mariadb13-lab \
mariadb -uroot -pchange-this-password upgrade_lab
如果需要比较旧版与 13.0，不要让两个实例共享数据目录。更稳妥的办法是分别启动实例，通过逻辑备份恢复相同的数据集，再执行同一组集成测试和性能测试。
把可观测性纳入验收标准
新版本强调开发体验和可观测性，但监控能力只有接入日常工作流才有价值。升级验收时可以同时查看活动连接、慢查询和聚合语句统计。
SHOW FULL PROCESSLIST;
SELECT
DIGEST_TEXT,
COUNT_STAR,
ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds,
SUM_ROWS_EXAMINED,
SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
performance_schema 的具体数据可用性取决于实例配置和消费者是否启用。生产环境中还要关注其内存及采集开销，并将数据库指标与应用端延迟、错误率和连接池等待时间放在一起分析。
针对关键查询，可以在升级前后分别记录执行计划和真实运行指标。例如 MariaDB 环境可用以下形式分析查询；请先在测试库执行，避免分析型语句给生产带来额外负载：
ANALYZE FORMAT=JSON
SELECT account_id, balance
FROM account_balance
WHERE balance >= 500
ORDER BY balance DESC;
重点比较扫描行数、索引选择、排序方式和总耗时，而不是只比较查询是否返回相同结果。
升级前的决策清单
MariaDB 13.0 已经 GA，但 GA 代表版本具备正式稳定状态，不代表每个应用都应立即原地升级。较稳妥的采用路径是：
- 阅读与当前小版本跨度对应的发行说明和弃用清单；
- 对存储过程、函数、触发器和复杂 DML 建立回归测试；
- 使用脱敏生产数据比较查询计划与延迟分位数；
- 验证驱动、连接池、备份、复制和监控工具兼容性；
- 设计可执行的回滚方案，而不是只保留数据库备份；
- 先升级低风险实例，再通过灰度流量观察错误率和资源变化。
如果团队正在进行 Oracle 迁移，MariaDB 13 的兼容性增强值得专门做一次概念验证；如果团队已经运行 MariaDB，则过程化 SQL、DML、性能和可观测性改进可能带来直接收益。无论哪种情况，都应以可重复测试和运行指标决定升级节奏，而不是只根据功能列表做判断。