◈ DB 选型参考
← 返回首页

MariaDB

关系型 OLTP #MySQL兼容 #开源GPL #主从复制 #Galera多主 #MariaDB公司私有化

MySQL 的嫡系 fork（创始人 Monty Widenius 主导），2010 年代初曾是"MySQL 的 drop-in 替代"，如今已与 Oracle MySQL 实质分化为两个独立演进的产品；社区版慷慨、公司刚经历私有化动荡。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商MariaDB Corporation（K1 Investment Management 旗下私有公司；开源项目由独立的 MariaDB Foundation 治理）
国家芬兰（起源）/ 美国（公司运营）
首次发布2009（5.1 起）；MariaDB Foundation 成立于 2012
许可证社区版 GPLv2；企业版向订阅客户分发；MaxScale 等周边为 BSL
托管服务MariaDB Cloud（SkySQL 2025-08 被重新收购后并入云战略）；AWS RDS / Azure / GCP 均有托管
主类型关系型（行存，InnoDB）
兼具类型列存分析（ColumnStore）、向量检索（11.8+ 自研 VECTOR + HNSW）
一致性模型主从异步=最终一致；半同步=低丢失；Galera=零丢失多主
复制协议binlog 主从复制；Galera wsrep 认证复制

硬维度（47 项）

1 静态加密 / TDE 有

有官方文档——10.1 起实例级静态加密：InnoDB 表空间（innodb_encrypt_tables）、redo log（innodb_encrypt_log）、临时文件、binlog（encrypt_binlog，10.5+）；插件式密钥管理：file_key_management（社区版自带，密钥存本地文件，合规性弱）/ AWS KMS 插件（企业版限定，GPL 与 AWS SDK 许可证冲突故社区二进制不分发）。备份文件本身的加密未找到证据，视为需外部手段解决。

2 TLS / 传输加密 有

有官方文档 社区实测——社区版原生 TLS，可按用户 REQUIRE SSL/X509 强制或全局 require_secure_transport=ON。

3 审计 有

有官方文档——server_audit 插件社区版自带（与 MySQL 企业版限定审计形成对比）；更细粒度的 MariaDB Enterprise Audit 为企业版，两者不可混装。

4 认证与权限 有

有官方文档——插件式认证（mysql_native_password / ed25519 / unix_socket / pam / gssapi）；10.4 起权限存储迁至 mysql.global_priv（JSON）；完整角色模型，10.11 新增 PUBLIC 伪角色。

5 备份恢复 有

有官方文档——mariabackup（XtraBackup fork）在线热物理备份，支持全量+链式增量，物理恢复为文件拷贝故速度快；mariadb-dump 做逻辑备份（库表级粒度、可跨版本、恢复慢）；binlog 做 PITR。

6 可观测性 有

有（官方文档；PFS 滞后为社区共识）——慢查询日志、general log 完整；PFS 10.6 起默认开启、sys schema 10.6 起内置；但 PFS 相对 MySQL 8 实现滞后、部分 instruments 缺失，重度依赖 PFS 的监控工具需实测。无官方 APM，靠 Prometheus mysqld_exporter 等第三方。

7 连接模型 有

有官方文档——默认 one-thread-per-connection；线程池内核自带、社区版可用（官方原话：MySQL 的线程池仅企业版，MariaDB 全版本可用）。官方无自带池化代理（MaxScale 为 BSL 商业产品）。

8 事务与隔离级别 有

有官方文档 社区实测——InnoDB MVCC，四档隔离级别，RR 为默认，支持 XA。注意 11.6.2 起 innodb_snapshot_isolation 默认 ON：RR 下对并发修改过的行做写写冲突检测，命中报 ER_CHECKREAD (1020) 并整个事务回滚——应用重试逻辑必须把 1020 与死锁 1213 同等处理（12.3 实测案例）。

9 复制与一致性 有

有官方文档——异步主从 + 半同步（社区版自带）+ Galera Cluster。GTID 为域式 domain-server_id-sequence，与 MySQL 的 UUID 式 GTID 完全不互通。

10 扩展方式 部分支持

部分支持官方文档 社区共识——纵向无缝；读扩展在线成熟（主从+读写分离、Galera 加节点）；写横向扩展为短板，查证为无官方自动分片方案（Spider 引擎运维复杂、生态小）。

11 兼容性 部分支持

部分支持官方文档 社区共识——MySQL 线协议兼容，驱动/ORM/GUI 通用；但 SQL 层"drop-in replacement"已是过时说法。查证缺失的 MySQL 8.x 关键特性：原生二进制 JSON、JSON_TABLE、JSON 多值索引、事务性数据字典、Group Replication、caching_sha2_password 默认认证。MariaDB 独有：sequences、系统版本表、INSERT...RETURNING、invisible columns、Oracle 兼容模式、VECTOR+HNSW（11.8+，反超 MySQL 一步）。

12 许可证与商业模式 有

有（官方文档/媒体报道）——社区版 GPLv2；企业版仅向订阅客户分发；MaxScale 等 BSL；订阅制计费（官网未公开价目，待验证）。

13 中文资料丰富度 部分支持

部分支持社区共识——官方 KB 以英文为主、无官方中文文档；中文内容散见云厂商文档、dbaplus、墨天轮、CSDN，多停留在 10.x 时代；11/12 新特性中文资料稀缺。

14 性能与延迟特征 有

有（单机性能与 MySQL 相近；Galera 多写有代价）。

  • 单机 OLTP 与 MySQL 同量级；线程池开源、优化器有差异化特性 社区共识。
  • Galera 多主写：认证复制有开销，写冲突导致回滚，高冲突负载下不如单主 社区共识。
  • ColumnStore 做分析，行列混合不如原生 HTAP 一体 社区共识。

15 合规与认证 部分支持

部分支持（开源无官方认证；企业版走厂商体系）。

  • 社区版：无官方合规认证，合规责任在部署方 社区共识。
  • MariaDB 企业版/SkySQL 的合规资质以厂商公开页为准 厂商口径。
  • 无信创名录公开信息 待验证。

16 成熟度与社区生态 有

有（2009 年从 MySQL fork；上市公司）。

  • 2009 年由 MySQL 创始人 Monty fork；MariaDB plc 上市 社区共识。
  • 曾财务动荡、2024 年被 K1 私有化，治理稳定性有问号 社区共识。
  • 社区版持续迭代，但生态声量弱于 MySQL/PG 社区共识。

17 标杆用户 有

有（Wikipedia 是最著名的公开案例）。

  • Wikipedia 从 MySQL 迁移到 MariaDB（公开）社区共识。
  • Google 内部曾用 MariaDB（公开报道）社区共识。
  • Linux 发行版默认 MySQL 替代，装机量大但多为中小场景 社区共识。

18 生态工具链 有

有（基本继承 MySQL 工具链）。

  • mysqldump/MariaDB 备份工具；gh-ost/pt-osc 多数可用 社区共识。
  • CDC：Debezium/Canal（协议兼容 MySQL）社区共识。
  • 专属工具少于 MySQL，SkySQL 托管版补齐 社区共识。

19 云托管与 Serverless 有

有（SkySQL；各云 MySQL 托管多兼容）。

  • SkySQL（MariaDB 官方云，Serverless 形态）厂商口径。
  • 各云 MySQL 托管与 MariaDB 协议兼容，迁移成本低 社区共识。
  • 第三方托管选择少于 MySQL 社区共识。

20 数据接入与摄入 有

有（LOAD DATA/mariadb-import；mydumper）。

  • LOAD DATA INFILE、mariadb-import（mysqlimport 对应）官方文档。
  • mydumper/myloader 并行逻辑导入导出，社区主流 社区共识。
  • ColumnStore 有 cpimport 专用批量导入 官方文档。

21 外部数据访问 有

有（CONNECT 引擎查 CSV/ODBC；Spider 做分片联邦）。

  • CONNECT 存储引擎可把 CSV/XML/ODBC/JSON 等当表查询，是特色能力 官方文档。
  • Spider 引擎可做分片与跨节点联邦查询 官方文档。
  • FEDERATED 引擎也可用但功能较弱 社区共识。

22 CDC 与下游同步 有

有（binlog；Debezium/Maxwell/Canal）。

  • binlog（row 格式）+ GTID，与 MySQL 生态工具兼容 官方文档。
  • Debezium、Maxwell 均可消费 社区共识。
  • Galera 集群下 CDC 建议从单节点取 binlog 社区共识。

23 TTL 与数据生命周期管理 部分支持

部分支持（分区+event；无原生行级 TTL）。

  • 分区表 + event scheduler 定时清理是标准做法 社区共识。
  • 与 MySQL 同源限制，无原生行级 TTL 社区共识。

24 在线 DDL 与 Schema 演进 部分支持

部分支持（INSTANT/NOCOPY/ALTER ONLINE TABLE；重建类操作仍慢，大表靠工具）。

  • 只改定义：INSTANT 只动元数据、O(1)：加列（10.3.2+ 仅末尾，10.4+ 任意位置）、重命名列、改列 DEFAULT 官方文档。
    • 重写但位置不变：INPLACE 后台构建、允许并发 DML；NOCOPY 是 MariaDB 特有断言——会重建聚簇索引就直接报错，而不是悄悄变慢；ALTER ONLINE TABLE 是 LOCK=NONE 简写，不满足就失败 官方文档。
    • 搬数据：改列类型等重建类操作走 COPY 全表重建（官方文档示例：Cannot change column type INPLACE），大表数小时、阻塞写 官方文档；大表生产仍用 pt-osc/gh-ost 做无锁变更 社区共识。
    • 验证约束：无 NOT VALID 两阶段语法（查证为无）；加索引走 INPLACE 在线构建 官方文档。
    • 规模：第二、四类代价 O(n)；且无论哪种锁策略，操作起止都要短暂独占锁表——活跃事务不提交，DDL 就卡住 官方文档。
    • 语义：DDL 隐式提交、非事务性 社区共识；同 MySQL 的 MDL 模型：长事务卡 DDL，排队中的 DDL 卡住后续请求；迁移写法显式指定 ALGORITHM + LOCK=NONE，让失败显性化而不是悄悄降级 社区共识。

25 多租户与资源隔离 部分支持

部分支持（无原生资源组；线程池有限缓解）。

  • 无 CPU/内存/IO 租户限流 社区共识。
  • 线程池可缓解连接风暴，但不是 QoS 官方文档。

26 跨地域多活 部分支持

部分支持（Galera/主从跨区可配；延迟敏感）。

  • Galera 多写跨区对延迟极敏感，生产少用 社区共识。
  • 主从跨区是常规容灾，无多活写 社区共识。

27 高可用架构与 RTO/RPO 部分支持

部分支持（主从/MHA/Galera，方案散）。

  • MHA/MMM/主从手动切，RTO 分钟级，脑裂风险看方案 社区共识。
  • Galera 多主同步，节点故障自动，但写放大 官方文档。
  • 无一键托管 HA，自建拼装 社区共识。

28 行级安全与数据脱敏 部分支持

部分支持（无原生RLS；靠视图与角色）。

  • MariaDB 无原生行级安全，行级隔离靠视图 + DEFINER 或应用层实现 社区共识
  • 支持列级 GRANT 与角色（roles），但无动态脱敏引擎 官方文档
  • MaxScale 等中间件可在查询改写层面做脱敏，但属外部组件 社区共识
  • 与 MySQL 企业版脱敏组件不对等，从 MySQL 企业版迁移时需重新评估 待验证

29 JSON 与半结构化能力 有

有（JSON 为 LONGTEXT 别名，函数兼容）。

  • JSON 为 LONGTEXT 别名（非二进制），JSON 函数与 MySQL 兼容 官方文档。
  • 无原生二进制存储与 JSON 路径索引，虚拟列可部分弥补 社区共识。

30 全文检索能力 有

有（FULLTEXT+Mroonga 中文分词）。

  • FULLTEXT 索引，Mroonga 引擎提供中文分词 官方文档。
  • Mroonga 为外部引擎，运维与主从复制需额外注意 社区实测。

31 存储效率与压缩 有

有（InnoDB 页压缩+Aria 引擎+列存引擎）。

  • 继承 InnoDB 页压缩与透明压缩能力（与 MySQL 同源）。官方文档
  • Aria 存储引擎支持数据页压缩；ColumnStore 引擎提供列式存储与高压缩比。官方文档
  • 多引擎并存带来选型复杂度，压缩收益因引擎而异。社区实测

32 开源协议与厂商锁定风险 部分支持

部分支持（核心 GPL 开源；MaxScale 曾转 BSL）。

  • MariaDB Server 核心采用 GPLv2 开源，由 MariaDB 基金会治理，协议变更黑历史较少。官方文档
  • 配套代理 MaxScale 曾从 GPL 转为 BSL（Business Source License），存在商业使用限制，后续生态出现替代方案。社区共识
  • 与 MySQL 高度兼容，跨两者迁移成本低，协议风险有实质缓解。社区共识

33 查询优化器与计划稳定性 有

有（MySQL 衍生 CBO；hint 兼容）。

  • 优化器源自 MySQL 并独立演进，EXPLAIN/hint 兼容 官方文档。
  • 统计信息引擎是差异点 官方文档。
  • 无计划冻结机制 社区共识。

34 参数调优与自治能力 部分支持

部分支持（参数多；调优复杂度同 MySQL）。

  • 参数体系庞大，调优经验与 MySQL 通用 社区共识。
  • 自治能力弱 社区共识。

35 静默数据损坏防护 有

有（InnoDB 页校验成熟，Aria 亦有页检查）。

  • InnoDB 数据页内置 checksum，读入校验，损坏页拒绝载入；doublewrite 防写撕裂。官方文档
  • Aria 存储引擎同样带页检查机制。官方文档
  • 复制链路无内容校验，静默损坏可扩散，需外部校验工具定期检查。社区实测

36 存储过程/触发器/过程语言 有

有（SP/触发器/事件；Oracle 模式）。

  • 存储过程、触发器、事件完整，Oracle 模式兼容 PL/SQL 子集 官方文档。
  • Oracle 模式兼容有限，复杂包改写仍重 社区共识。

37 约束与数据完整性 有

有（FK/CHECK 完整（10.2+））。

  • InnoDB 外键，10.2+ CHECK 约束 官方文档。
  • 外键级联大批量操作同样注意锁与写放大 社区实测。

38 分析 SQL 完备性 有

有（窗口/CTE（10.2+））。

  • 10.2+ 窗口函数、CTE 官方文档。
  • 分析函数完备度弱于 PG/Oracle 社区共识。

39 被遗忘权与数据擦除 部分支持

部分支持（手动DELETE；binlog/备份残留）。

  • 与 MySQL 同源：DELETE 为逻辑标记 + 空间回收，无擦除证明 社区共识
  • binlog、mariabackup 备份、Galera 节点间 SST 都会复制被删数据的历史状态 社区共识
  • 分区交换 / 删除是批量擦除的常用手段 社区实测

40 数据血缘与目录集成 无

无（查证为无原生血缘）。

  • 无原生血缘 官方文档。

41 存算分离 vs 存算一体 有

有（存算一体：本地盘架构）。

  • 经典存算一体本地盘架构 官方文档。

42 多模能力 部分支持

部分支持（JSON 别名+全文；无向量）。

  • JSON 为 LONGTEXT 别名，全文索引可用 官方文档。
  • 无原生向量/图 社区共识。

43 FinOps 成本可观测性 不适用

不适用（自建无计费，成本=硬件+人力自理）。

  • 开源自建无内置计费概念，成本是服务器、存储与运维人力。社区共识
  • SkySQL 等托管版可在云账单侧做标签归因与预算告警。厂商口径

44 驱动与多语言生态 有

有（MySQL 协议兼容，驱动通用）。

  • MySQL 线协议兼容，Connector/J 等驱动通用 官方文档。

45 物化视图 无

无（查证为无原生；Flexviews 非内置）。

  • 无原生（查证为无），Flexviews 等外部方案非内置 社区共识。
  • 汇总表+事件调度模拟 社区共识。

46 支持跨云 有

有（开源任意云；SkySQL 多云）。

  • 开源版任意云可部署 官方文档。
  • SkySQL 支持多云 厂商口径。

47 热点数据更新能力 部分支持

部分支持（InnoDB 行锁串行，无专用热点优化）。

  • 并发原语：InnoDB 行级记录锁（锁实际落在索引记录上），后来者排队等待，等待时长受 innodb_lock_wait_timeout（默认 50 秒）限制；死锁由内核检测并回滚代价较小的一方（报 1213），重试由应用负责；热点行即串行单点 官方文档。
  • 衰减：高并发热点下锁等待队列线性增长，吞吐趋平、p99 延迟上升；若热点更新的 WHERE 没有可用索引，锁范围会放大到所有被扫描行，进一步加剧竞争 社区共识。
  • 未找到 MariaDB 官方提供专用热点行优化机制（如自动打散/排队化）的证据，缓解靠应用层；Galera 多主模式下热点行还会触发认证冲突回滚，情况更差 待验证。
  • 应用层模式与代价：社区推荐计数器分桶（写时随机 32 桶、读时 SUM）、异步聚合、短事务、用 READ COMMITTED 减少间隙锁；代价是读聚合复杂度与短暂不一致 社区共识。

招牌能力

  1. 社区版慷慨：审计、线程池、静态加密全免费 真本事：server_audit、线程池、实例级静态加密在 MariaDB 社区版全部自带——这三样在 Oracle MySQL 那边是企业版（付费）的墙内能力。对预算敏感又需要合规基线的团队，这是实打实的差异。 边缘真相：慷慨不等于企业级——server_audit 的过滤能力弱于 Enterprise Audit；file_key_management 的密钥存本地文件，过等保/PCI 这类强合规还是要上 KMS（企业版墙内）。以及"免费"的前提是公司还活着（见深水区二）。
  2. 协议层 MySQL 兼容 + 独立演进的 SQL 方言 真本事：MySQL 线协议兼容，现有驱动、ORM、GUI 工具基本不用换；同时 10.2 起窗口函数/CTE 首发早于 MySQL 8.0，11.8 自研向量检索反超，Oracle PL/SQL 兼容模式是独家。 边缘真相：协议兼容掩盖了语义分化——GTID 不互通、JSON 是 LONGTEXT 别名、优化器代价模型独立（11.0 起基于时间），从 MySQL 8.0 迁过来复杂 SQL 必须重测。别把"连得上"当成"跑得一样"。
  3. Galera Cluster：官方背书的多主同步复制 真本事：2025 年 6 月 MariaDB 直接收购了 Galera Cluster（原 Codership 独立产品），官方 2026 年确认长期保留在社区版——同机房多活 + 自动故障转移，RPO=0。 边缘真相：见深水区四——它是"乐观多写"不是"同步魔法"：热点行跨节点写会认证冲突回滚、大事务拖住全集群、流控让最慢节点决定集群写入速度。生产正解是单写+多读。
  4. Temporal 表（系统版本表）与 Oracle 兼容模式 真本事：系统版本表（AS OF 查询历史数据）是 SQL:2011 标准能力，MySQL 至今没有；Oracle 兼容模式（PL/SQL 语法）给"去 O"场景留了一条低成本路。 边缘真相：两者都是"有但浅"——temporal 表的历史数据膨胀需要分区/清理策略，否则存储翻倍；Oracle 模式覆盖的是语法子集，重度 PL/SQL 仍要逐项 POC。适合轻量场景，重度依赖别当救命稻草。

深水区

深水区一：GTID 不兼容——迁移的第一道墙（domain：复制与迁移）

  • 机制：MariaDB GTID 是 domain-id – server-id – sequence 三元组官方文档，MySQL 是 server_uuid:transaction_id，两套 ID 体系互不识别。
  • 推到边缘：MariaDB 可做 MySQL 主库的从库（走传统位点），但 MySQL 不能做 MariaDB 主库的从库官方文档；GTID 模式下跨库复制直接失效。若现有架构依赖 GTID 做主从切换/多源复制/故障转移编排（如 Orchestrator），迁移等于复制拓扑全部重做，不存在连续 GTID 跟踪的平滑迁移社区共识。
  • 选型含义：从 MySQL 迁 MariaDB 必须按"异构数据库"做迁移评估，而非"升级"；双写或渐进迁移需要应用层或逻辑复制工具做转换层。
  • 来源：官方文档（mariadb.com GTID 页面）；社区迁移技能文档多份交叉

深水区二：公司商业模式与 SkySQL 的起落——最大风险不在技术（domain：商业模式）

  • 机制：MariaDB Corporation 走订阅制（Enterprise Server + 支持 + 云）；社区版由独立的 MariaDB Foundation 治理。
  • 推到边缘：时间线（多家媒体交叉：TechCrunch/The Register/SiliconANGLE）——2022-12 SPAC 上市首日破发；2023-10 裁员 28%、砍掉 SkySQL 与 Xpand（SkySQL 2023-12 剥离为独立公司）；2024-02 K1 出价收购（媒体口径）、完成私有化后 NYSE 退市，CEO 换为 Rohit de Souza。私有化后反而扩张：2025-01 Enterprise Platform 2025、2025-06 收购 Galera、2025-08 回购 SkySQL、2026-03 收购 GridGain。
  • 选型含义：生存风险已解除，但两点需警惕：① 私有化后无公开财报，财务健康度不可见待验证；② 战略重心转向 AI/向量/RAG 叙事，传统 OLTP 投入占比可能被稀释。社区版路线图由 Foundation 保障，但企业版功能越来越向 AI workload 倾斜。
  • 来源：TechCrunch 2024-09-10；The Register；SiliconANGLE 2026-03-09；官方新闻稿

深水区三：存储引擎现状——"引擎动物园"的代价（domain：存储引擎）

  • 机制：MariaDB 曾以多引擎为卖点；10.4 起系统表默认引擎为 Aria（MyISAM 的崩溃安全替代，WAL 重放恢复，无事务、表级锁）；ColumnStore（InfiniDB fork）是 MPP 列存 OLAP 引擎。
  • 推到边缘：① Aria 没有行级锁，高并发写入表锁串行化，绝不能当 OLTP 事务引擎；系统表放 Aria 上意味着 mysql 库本身无事务保护社区共识。② ColumnStore 未停滞但转向企业版/云优先：2026-08 企业版 release notes 仍在集成 25.10.6，主仓库仍有提交；但官方 Docker 镜像自 2023 年停更，社区被迫自建镜像；分布式部署需 CMAPI + 多节点编排，运维成本接近一套独立 MPP 数仓社区实测。③ 勘误：10.6 移除的是 TokuDB（10.5 禁用、10.6 移除，MDEV-19780）和 Cassandra SE，不是 MyRocks；MyRocks 至今在代码树中但长期停留 Alpha/Beta、从未生产级社区共识——"引擎动物园"的代价是每个引擎都要跟随主版本适配，分叉越远维护成本越高，最终只能放弃。
  • 选型含义：生产只认 InnoDB；Aria 限归档/只读表；ColumnStore 按"独立 MPP 系统"做运维预算，分析 workload 更务实的选择仍是 ClickHouse/DuckDB 等外部系统；Spider/CONNECT/MyRocks/S3 视为无人维护。
  • 来源：官方文档（MDEV-19780）；mariadb.com 企业版博客；社区实测（docker-mariadb-columnstore）；2026-09 Medium 综述

深水区四：Galera Cluster——乐观多写，不是同步魔法（domain：复制与一致性）

  • 机制：wsrep 认证复制——事务在发起节点本地执行，COMMIT 时把写集广播全节点，各节点用确定性算法认证行级冲突，全节点独立得出相同结论。先本地执行、提交时全局认证，是乐观并发控制。
  • 推到边缘：① 跨节点写同一热点行→认证冲突，后提交事务被回滚，驱动层看到死锁错误，需应用层重试（社区实测：passbolt 多主下双管理员操作可稳定复现 500 错误；标准解法是单写节点）。② 大事务：写集原子认证，超大写集（社区经验值 ~12.8 万行以上）拖住全集群认证，官方建议拆几千行一批；整个写集在内存组装/传输。③ Flow control：某节点 apply 跟不上（wsrep_local_recv_queue_avg 持续增长）会触发流控让全集群暂停写——最慢节点决定集群写入速度，wsrep_flow_control_paused 应接近 0。④ 节点故障：短期离线用 IST（依赖 gcache 大小），覆盖不了则 SST 全量同步，donor 节点被 desync/阻塞。⑤ 脑裂：Primary Component 算法，只有加权多数（>50%）分区可写；2 节点集群任何分区下两边都变只读，偶数节点 2/2 分区同样全停；解法是 3 节点 / garbd 仲裁 / 非对称权重官方文档。⑥ 限制清单（官方文档+社区实测）：不支持 XA；复制表必须有主键（认证靠主键定位）；DDL 是 TOI 全局锁，阻塞整个集群；只有 InnoDB 表被复制。
  • 选型含义：Galera 解决的是同机房/同城多活+自动故障转移，代价是写延迟、热点行冲突、运维面（SST/IST/流控/quorum）。单写路径、能容忍秒级 RPO 的场景，异步复制 + 自动故障转移综合成本远低于 Galera社区共识。选前先回答：有没有跨节点写同一行？有没有大事务？
  • 来源：Codership 官方文档（weighted-quorum）；MariaDB 官方博客；coroot inspections；社区运维指南

深水区五：版本支持策略——清晰但有断裂带（domain：运维与升级）

  • 机制：MariaDB 自 11.x 起"每季度滚动版 + 每年 LTS"节奏；短期版约 1 年维护，是下一 LTS 的试验田，不要上生产社区共识。LTS 线（社区实测 endoflife.date，采集 2026-09-29）：10.6 LTS 已于 2026-07-06 EOL（不到 3 个月前）；10.11（EOL 2028-02-16）、11.4（EOL 2029-05-29，最长 runway）、11.8（EOL 2028-06-04）、12.3（EOL 2029-06-12）支持中。
  • 推到边缘：10.x→11.0 是架构断裂带——优化器代价模型改写（查询计划可能变化，升级前必须抓 EXPLAIN 基线）、GRANT SUPER 不再隐含细分权限（自动化脚本升级后报 access-denied）、innodb_change_buffering 等已移除参数残留会阻止启动社区实测。升级真正成本不在 mariadb-upgrade 本身，而在三件事：my.cnf 参数审计、优化器回归测试、权限/认证模型变更（10.4 global_priv、11.0 SUPER 解耦）。另注意 12.x 破坏性默认变更：innodb_snapshot_isolation=ON（1020 错误需应用层重试）、新增保留字。
  • 选型含义：新部署选 11.4/11.8/12.3 LTS；10.x→11.x 按架构升级做预算，不是按补丁做；MariaDB 版本号不再传递任何与 MySQL 的对应关系，迁移过来的人要重建版本心智模型。
  • 来源：endoflife.date；AWS 迁移技能文档；社区实测（dev.to 12.3 升级案例）

客户经验

生态 治理红利 —— "真正开放的 MySQL"

一句话
当社区不信任 Oracle 治下的 MySQL 时，MariaDB 是"MySQL 本该有的样子"——这不是性能招牌，是信任招牌。
窄场景
对开源许可证/社区治理敏感的机构（基金会、高校、公共部门、Linux 发行版）；担心 MySQL 未来闭源化或功能阉割的长期选型。
机制
MariaDB 由 MySQL 创始人 Monty Widenius 主导分叉，基金会治理、GPLv2 协议。它的招牌不是某一个 feature，而是"MySQL 生态的开放备份"：一旦 MySQL 出现社区不可接受的转向，整个生态有可切换的逃生舱。Wikipedia 的迁移理由说得最直白。
生产验证
Wikipedia 2013 年从 MySQL 迁移到 MariaDB：Wikimedia 的 Asher Feldman 原话——"主要目标不是性能，而是确保真正开放的未来"（https://diff.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/）。实测平均查询快 8%、qps 提升 2–10%（https://torquemag.io/2013/01/wikipedia-mariadb/），但当事人强调性能是副产品，开放未来才是目标。RHEL、Debian、Fedora 等主流发行版默认搭载 MariaDB 作为 MySQL 实现。
竞品差距
MySQL——技术同源，差距纯粹在治理：Oracle 拥有、社区对闭源化/企业版功能倾斜的担忧是 MariaDB 存在的根本原因；Percona Server 同为开源分支但无 MariaDB 的发行版地位。这是 31 款里唯一的"治理即招牌"案例，选型理由不在基准测试里。
证据等级
具名当事人原话 + 机构官方博客 + 发行版默认地位
最后核验
2026-10-01

内核 存储引擎矩阵 —— MySQL 没有的第二、第三、第四个引擎

一句话
ColumnStore 列存、Spider 水平分片、MyRocks 写优化、S3 冷存储引擎——一个发行版里装着 MySQL 生态没有的引擎选项。
窄场景
想在 MySQL 协议/生态内解决"分析查询""写放大""冷数据成本"而不引入新系统：轻量 HTAP（ColumnStore）、透明分片（Spider）、写入密集（MyRocks）、S3 冷存降本。
机制
MariaDB 保留并发展了 MySQL 5.x 时代的可插拔引擎传统：ColumnStore 是列式存储引擎（10.5+ 整合），Spider 是分片代理引擎（应用无感知的水平拆分），MyRocks 是基于 RocksDB 的写优化引擎（写放大显著低于 InnoDB），另有 S3 存储引擎把冷表直接存对象存储——"一个协议、多种存储取向"，对照 MySQL（InnoDB 一统天下）。
生产验证
Redgate Simple-Talk 的独立技术对比梳理了 MariaDB 相对 MySQL 的引擎差异（https://www.red-gate.com/simple-talk/databases/the-one-big-difference-between-mysql-and-mariadb-you-may-have-overlooked/）。诚实标注：各引擎的生产口碑证据为中等——ColumnStore/Spider 的大规模生产案例本次未挖到一线工程师具名分享。这是"有牌但少人晒战绩"的招牌。
竞品差距
MySQL——官方只有 InnoDB（MyRocks 是 Meta 内部/Facebook 分支，非官方发行版）；TiDB——HTAP 靠 TiFlash 独立节点（架构更重）；AlloyDB——列存是云托管专属。"MySQL 协议 + 可选列存/分片引擎"的组合 31 款里只有 MariaDB。但社区真实声音是"InnoDB 照样是 95% 场景的答案"——引擎矩阵是长尾场景的逃生舱，不是日常主力。
证据等级
独立技术对比（引擎存在性与差异）+ 生产口碑证据中等（诚实标注）
最后核验
2026-10-01

用户最买账的 5 点

  1. "比 MySQL 更开源"的信任感
    • 为什么是真的：创始人嫡系、GPLv2、Foundation 独立治理；Oracle 收购 MySQL 后的"逃离 Oracle"情绪是 MariaDB 早年增长的核心燃料，AWS 成为 Foundation 首个 diamond 赞助商。
    • 边缘与限度：信任的是"开源"，不是"公司"——Corporation 刚经历私有化动荡，财务不可见；且"逃离 Oracle"叙事在 2026 年已是十年前的故事，新用户应基于 12.x 的产品力而非 2013 年的情绪做决策。
    • 来源：社区共识；TechCrunch 2024-09-10。评审版本：12.3 LTS
  2. 社区版功能慷慨
    • 为什么是真的：审计插件、线程池、静态加密、半同步复制全在社区版——MySQL 那边同等能力要企业版付费。对预算敏感的团队，合规基线（审计+加密）零成本达成。
    • 边缘与限度：慷慨的是"有"，不是"强"——社区审计过滤能力弱于企业版；file_key_management 密钥存本地文件，强合规仍需 KMS（企业版墙内）；线程池调优（thread_pool_size 等）仍需 DBA 手艺。
    • 来源：官方文档；社区共识。评审版本：12.3 LTS
  3. MySQL 生态平滑接入
    • 为什么是真的：线协议兼容，DBeaver/phpMyAdmin/WordPress/PMM 等工具基本不用换；MySQL 5.7 时代用户迁过来曾是近乎 drop-in。
    • 边缘与限度："连得上"≠"跑得一样"——GTID 不互通、JSON 语义差异、优化器分化，MySQL 8.0 用户迁过来已是"换发动机"级别改造（逻辑 dump 重建 + 用户授权手工迁移 + 全量回归）。生态兼容的是工具链，不是语义。
    • 来源：社区迁移实测文档多份交叉。评审版本：12.3 LTS
  4. Galera 多活口碑
    • 为什么是真的：同机房多节点可写、自动故障转移、RPO=0，在对"双活"有执念的传统行业（尤其国内部分金融/政企）口碑深厚；2025 年官方收购 Galera 后背书更强。
    • 边缘与限度：口碑成立的前提是 workload 友好——无跨节点热点写、无大事务、无频繁 DDL；否则认证冲突、流控、TOI 锁会把"多活"变成"多坑"。很多团队真正需要的是"故障自动切换"而非"多点写入"，异步+编排更便宜。
    • 来源：社区运维共识；Codership 官方文档。评审版本：12.3 LTS
  5. LTS 节奏可预测
    • 为什么是真的：每年一个 LTS、5 年社区维护，节奏固定；11.4（EOL 2029-05-29）给了最长的 runway。
    • 边缘与限度：可预测的是"时间"，不是"平滑"——10.x→11.x 是架构断裂带，升级预算要按"换代"做；12.x 每个次版本都可能含破坏性变更（snapshot isolation 默认 ON 就是 12.x 的坑），LTS 不等于"无感升级"。
    • 来源：endoflife.date（采集 2026-09-29）；社区升级实测。评审版本：12.3 LTS

吐槽清单

分类吐槽影响版本状态
兼容坑GTID 与 MySQL 完全不互通，跨库复制/迁移无平滑路径，复制拓扑推倒重来全版本open
兼容坑JSON 是 LONGTEXT 别名+CHECK 约束，非二进制存储；->>/JSON_TABLE/多值索引缺失，迁移后需给 JSON 列补 CHECK 约束否则静默写坏全版本open
兼容坑11.4 之前无 caching_sha2_password 兼容插件，MySQL 8 用户密码需轮换重建<11.4partially-fixed（11.4.9+/11.8.4+ 有迁移插件，12.1 有完整插件，成熟度待验证）
兼容坑10.4 起 mysql.user 变视图、权限迁至 mysql.global_priv，监控/审计/备份脚本需重写10.4+open（按新模型适配）
性能坑11.0 起优化器代价模型改写，升级后查询计划可能变差，多表 join/大范围扫描最受影响，需抓 EXPLAIN 基线11.x/12.xopen（升级前回归测试）
性能坑Galera 跨节点热点写认证冲突回滚、流控让最慢节点决定写入速度、大事务拖住全集群全版本open（单写+多读规避）
运维坑Galera DDL 是 TOI 全局锁，阻塞整个集群；RSU 滚动升级让集群短暂分叉全版本open
运维坑Galera 2 节点集群任何网络分区下两边都变只读，无安全双节点配置全版本open（需 3 节点/garbd/加权 quorum）
运维坑大版本升级无官方回退支持，redo log/系统表格式升级不可逆全版本open
运维坑PFS 相对 MySQL 8 实现滞后、部分 instruments 缺失，重度依赖 PFS 的监控工具需实测全版本open
版本坑10.6 LTS 已于 2026-07-06 EOL，仍在跑 10.6 的生产库需尽快规划升级10.6open
版本坑12.x 引入 innodb_snapshot_isolation 默认 ON，应用层需把 1020 错误与死锁同等重试，否则并发更新报错11.6.2+/12.xopen（应用层适配）
生态坑中文资料少一个量级且多停留 10.x 时代，11/12 新特性中文资料稀缺，深水区问题需读英文文档/Jira全版本open
生态坑ColumnStore 官方 Docker 镜像自 2023 年停更，社区版 OLAP 用户需自建镜像、无人值守跑 MPP全版本open
授权坑AWS KMS 插件、Enterprise Audit/Backup、128 索引上限等为企业版墙内；MaxScale BSL 生产使用受限全版本open
成本坑公司私有化后无公开财报，长期路线图可信度标注"厂商口径"；战略转向 AI/向量，传统 OLTP 投入占比待观察2024-09 后open待验证

判决

  • 一句话定位：MySQL 协议兼容、社区版慷慨的独立关系型数据库，但与 MySQL 8.x 已是两个产品；公司刚走出动荡，技术债可控、商业连续性待观察。
  • 适合谁：预算敏感但需要审计/加密合规基线的团队；MySQL 5.7 存量大、想摆脱 Oracle 授权的团队；需要同机房多活且 workload 友好（无热点跨节点写）并接受 Galera 运维面的团队；WordPress/PHP 生态（MariaDB 仍是默认推荐）。
  • 不适合谁：深度绑定 MySQL 8.x 特性（原生 JSON、Group Replication、caching_sha2_password 生态）且不愿做异构迁移的团队；需要官方自动分片写扩展的团队；把"云原生 DBaaS 稳定性"放在首位的团队（MariaDB Cloud 是 2025-08 才买回重建的，连续性风险待验证）；重度依赖中文资料的新手团队。
  • 迁移成本：MySQL 5.7 → 低（曾近乎 drop-in，但注意目标版本已 EOL 的 10.6 不要选）；MySQL 8.0 → 中高（GTID/认证/JSON/字符集四处硬分化，逻辑 dump 重建 + 全量回归，按异构数据库对待）；Oracle → 中（Oracle 兼容模式覆盖语法子集，重度 PL/SQL 逐项 POC）；PostgreSQL → 高（无 PG 兼容，走应用层改造）。

来源与待验证清单

  • 版本基线：endoflife.date MariaDB 页面（12.3.3，2026-08-24 发布；12.3 LTS EOL 2029-06-12）；WordPress hosting-handbook 兼容性表
  • 公司与组织：TechCrunch 2024-09-10（K1 收购/私有化/CEO 变更）；The Register 2023-05-16（商业与开源走钢丝）；SiliconANGLE 2026-03-09（收购 GridGain）；官方新闻稿（回购 SkySQL 2025-08、企业版 12.3 beta）
  • 固定题库：MariaDB 官方文档（静态加密/TLS/server_audit/线程池/mariabackup/升级指南）；社区实测（TLS 配置范式、PFS 滞后、1020 错误案例 dev.to）
  • 深水区：官方文档（GTID、MDEV-19780 TokuDB 移除、Galera 长期保留声明）；Codership weighted-quorum 文档；coroot inspections；passbolt 多主实测；mariadb-corporation 官方迁移工具文档（2026-09 仍在更新）；AWS 迁移技能文档；2026-09 Medium 引擎综述
  • 待验证项：wsrep_max_ws_size 默认值；K1 私有化后真实财务状况；12.1 caching_sha2_password 完整插件的生产成熟度；ColumnStore 社区版长期投入强度；企业版订阅价目
  • 下次评审：建议跟踪 13.0 LTS（预计 2027 年中）发布后更新版本策略条目；跟踪 MariaDB Cloud（SkySQL 回购后）的连续性表现