2026/9/19 3:02:11
FEATURED · 精选文章 
这几年的数据库圈隔三差五就会冒出“MySQL 是不是凉了”的讨论尤其当有人甩出那句“Is MySQL dead? Long live MariaDB”的时候评论区总能吵成一片。作为从 MySQL 5.5 一路用到 8.4、又亲手维护过 MariaDB 10.11 集群的从业者我先给个明确结论MySQL 没死MariaDB 也不是什么“取代者”两者是同根生的两兄弟只是走的路线越来越不一样了。这篇文章我不打算站队只把分家历史、技术差异、迁移实操、选型逻辑和未来走向一次讲清楚适合正在做数据库选型的后端开发者、运维和架构师参考。内容全部来自这些年的实际项目和踩坑记录不抄文档尽量说人话。1. “MySQL已死”的论调是从哪冒出来的1.1 十多年前那场收购埋下了一切的种子要理解“MySQL 已死”这个说法绕不开 2008 到 2009 年那两笔震动开源圈的收购。先是 Sun 买下 MySQL AB紧接着 Oracle 又把 Sun 整个吞了。消息一出大量 MySQL 老用户心里就咯噔一下一个靠开源社区起家的数据库落到了当时全球最大的商业数据库公司手里后面会发生什么谁都不敢打包票。最典型的反应来自 MySQL 创始人 Monty Widenius。他不仅公开表达了对 Oracle 的不信任还直接离开项目基于 MySQL 5.1 的代码分支创建了 MariaDB。这个名字来自他女儿 Maria等于从父辈到子辈都跟 MySQL 有血缘关系。MariaDB 最早几个版本基本就是 MySQL 5.1 加补丁改动并不大但随着版本迭代它和“正统 MySQL”之间的代码差异越来越大最终彻底成了独立的数据库产品。这段历史在技术圈留下的最大遗产是“信任”的分裂。很多企业不是因为 MariaDB 功能更强才换而是单纯不想把自己的核心数据库押注在一个不信任的厂商手里。这种情绪后来被不断放大成了“MySQL 已死”论调的原始土壤。1.2 “已死”信号到底指哪些事那为什么现在还有人说 MySQL “死了”我复盘了一下主要来自三个信号。第一个信号是操作系统的默认切换。从 CentOS/RHEL 7 开始系统自带的 mysql 命令实际指向的就是 MariaDBCentOS/RHEL 8 默认装上的更是 MariaDB 10.3Debian 9 之后也把默认数据库换成了 MariaDBFedora 更是早就切换过去了。这就造成一个很有名的名场面新手照着“MySQL 安装教程”去装数据库装完一执行mysql -V跳出来一串 “MariaDB”当场懵掉。对普通用户来说系统默认用谁谁看起来就更像“活的”。第二个信号是 Oracle 的商业化动作。MySQL 社区版一直还在但 Oracle 把大量高级功能做成了 Enterprise 闭源插件比如企业级审计、线程池、加密特性这些社区里想用只能另想办法。再叠加 Oracle 对 MySQL 的版本节奏、许可政策调整社区里那种“MySQL 被商业绑架了”的声音就没断过。第三个信号是几个明星项目高调迁移。最有名的就是 Wikipedia 从 MySQL 迁到了 MariaDB这给外界传递了一个信号连这么大的站点都跑了MySQL 是不是不行了再加上各种技术号为了流量反复渲染“MySQL 衰败论”久而久之“MySQL 已死”就成了数据库圈的月经话题。1.3 说句公道话MySQL 的非官方讣告写早了但现实和情绪是两回事。到今天为止MySQL 社区版依然在按固定节奏迭代8.4 LTS 在 2024 年发布9.x 创新版也持续推出全球数据库排名里 MySQL 常年稳居第二仅次于 Oracle 数据库本身。更关键的是云厂商在这件事上的押注极其明确阿里云 RDS MySQL、腾讯云 TDSQL-C for MySQL、AWS Aurora MySQL清一色基于 MySQL 生态开发。国内很多号称“国产自研”的分布式数据库协议层也都是兼容 MySQL 的。再看就业市场Java 后端面试题里 MySQL 永远是重头戏从索引到事务、从执行计划到主从复制“mysql 面试题”这类搜索常年居高不下。一个真正“死了”的数据库不可能每天还有这么多人围绕它找工作、做培训、写适配层。所以我的判断很直接MySQL 的讣告被写早了而且写它的人大多数根本不在生产环境里维护过 MySQL。2. MariaDB 和 MySQL到底差在哪2.1 版本号背后的“分道扬镳”想搞明白两者的差异先从版本号说起。MySQL 的演进路径是 5.5 → 5.6 → 5.7 → 8.08.0 之后又改成 8.4 LTS 9.x 创新版的发布节奏。MariaDB 早期版本号完全对齐 MySQL比如 5.5 就是对齐 MySQL 5.5后来改用 10.0 对齐 MySQL 5.610.1 对齐 MySQL 5.7从 10.2 开始加入了很多 MySQL 8.0 才有的特性比如窗口函数、CTE、CHECK 约束。但从 10.2 之后MariaDB 就不打算再跟 MySQL 一一对表了直接走出自己的节奏10.3、10.4、10.5、10.6 LTS、10.11 LTS再到 11.x 系列。这就带来一个非常实际的问题网上大量“MySQL 8.0 教程”里说的功能放到 MariaDB 10.11 上可能能用也可能不能用反过来用 MariaDB 的经验去套 MySQL 8.4也会踩坑。版本号不再对应之后兼容性全靠实测不能靠“凭感觉”。2.2 存储引擎与核心功能的取舍我把两者在生产环境中最容易感知到的差异整理成了一张表方便你对照项目需求快速判断功能点MySQL 8.0 / 8.4MariaDB 10.11 / 11.x默认存储引擎InnoDBInnoDB原生 JSON 类型支持二进制 JSON JSON_TABLE不支持JSON 是 LONGTEXT 的别名窗口函数8.0 起支持10.2 起支持CTE 公用表表达式8.0 起支持10.2 起支持CHECK 约束8.0.16 起支持10.2.1 起支持独立序列 SEQUENCE无只能用 AUTO_INCREMENT10.3 起原生支持 CREATE SEQUENCE系统版本表无10.3 起支持 WITH SYSTEM VERSIONING数据库角色 ROLE8.0 起支持10.0.5 起支持默认认证插件caching_sha2_passwordmysql_native_password内置 Galera 多主集群无需额外配置组复制 中间件10.4 起内置内存占用相对较高相对更低这张表看着简单但每个差异背后都是实际业务坑。比如你的应用要是用了 MySQL 8.0 的 JSON 函数做复杂查询迁到 MariaDB 就得小心它的 JSON 字段本质是字符串JSON_EXTRACT 这类函数虽然也有但存储格式、索引方式、排序行为都跟 MySQL 8 的原生 JSON 不一样线上数据量大以后性能差异会非常明显。反过来如果你需要“历史数据可回溯”这种需求MariaDB 的系统版本表开箱即用MySQL 8 反而没有这个功能得靠业务层自己实现或者依赖企业版的 flashback 能力。2.3 从热搜问题看兼容性最大的几个坑我翻了翻大家日常搜得最多的问题发现很多坑其实都源于“两个库用一个经验”。挑几个典型的说说。第一个是 MySQL 8.0 的认证插件问题。从 8.0 开始 MySQL 默认启用 caching_sha2_password而 MariaDB 默认还用着 mysql_native_password。这就导致老版本的 Navicat、老旧 JDBC 驱动去连 MySQL 8.0 时直接报 “Client does not support authentication protocol requested by server”。很多人以为是密码错了其实是协议不兼容。临时办法是给账号改回老插件但从 MySQL 8.4 开始这个老插件默认被禁用所以我更建议直接升级客户端和驱动别再留恋老古董。第二个是drop database报错 1010。这个问题在搜“drop database leshanshop”相关报错时特别典型报错信息类似ERROR 1010 (HY000): Error dropping database (cant rmdir ./xxx/, errno: 39)。核心原因通常是数据库目录里有 MySQL 不认识或没删干净的文件比如之前手动往 datadir 里丢过东西或者文件权限不对。处理思路是先ls看目录里残留了什么确认无价值后手动清理再让数据库重试 DROP如果目录删不掉也可以先把目录移走库里执行 DROP 清掉元数据再手动处理物理目录。第三个是框架主动抬高新版要求。这两年 Django、一些 ORM 框架已经把最低支持的 MySQL 版本抬到了 8.x 甚至更高老库不升级新框架版本就装不上、跑不动。这类问题本质上是生态在倒逼 MySQL 版本升级而不是数据库本身出了毛病。第四个我觉得很值得点名的是“初始密码”问题。很多人用包管理器装完 MySQL 后习惯性地用 root 空密码登录结果怎么都登不上。原因要分场景用 MySQL 官方仓库装初始随机密码写在日志里用系统自带的 MariaDBDebian 系默认走 unix_socket 认证需要sudo mysql才能进。搞清楚自己到底装的是谁、用的什么认证方式是解决这类问题的最快路径。3. 实操指南迁移、安装、调优一次讲清3.1 选型前先做一次体检我的迁移检查清单不管你是要从 MySQL 迁移到 MariaDB还是从 MariaDB 兜回 MySQL我都强烈建议先做一轮“数据库体检”不要脑子一热就直接mysqldump。体检的核心是搞清楚你的存量业务到底踩了哪些“专属特性”。我的体检清单一般是这几项版本和驱动体检登录每个库执行SELECT VERSION()把应用侧 JDBC/ODBC/PHP 扩展版本列出来逐项确认是否支持目标库的认证方式。字符集与排序规则检查SHOW VARIABLES LIKE character_set%重点看 utf8mb4 是否统一排序规则在 MySQL 8 里常见的是 utf8mb4_0900_ai_ciMariaDB 里更常见的是 utf8mb4_general_ci迁移后排序结果可能不一样。SQL 模式体检执行SELECT sql_mode如果业务依赖 ONLY_FULL_GROUP_BY 之外的宽松模式迁移后很可能报 SQL 错误。存储引擎体检执行SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine InnoDB找出所有 MyISAM、MEMORY 表评估是否需要转换。高风险 SQL 扫描去代码库里搜所有用到了 JSON 函数、窗口函数、CTE、INSERT IGNORE、REPLACE INTO、UPDATE ... JOIN的地方逐个确认目标库语法支持度。备份恢复演练别等机房断电才第一次做恢复先在测试环境完整跑一遍备份和恢复记录耗时。体检花半天后面能少熬一个月。我见过太多人跳过这步结果迁移完第二天接口全挂最后逐条捞慢 SQL 捞到头秃。3.2 安装配置CentOS 系与 Debian 系的差异安装这块网上教程多如牛毛但很多都没讲清楚“装的是哪个”。分两个系统来说。Debian/Ubuntu 系里apt install mysql-server和apt install mariadb-server是两个独立包想装谁就装谁装完后mysql -V能直接看出是哪个。需要注意Debian 系的 MariaDB 默认 root 走 unix_socket 认证直接mysql -uroot -p是登不进去的得sudo mysql这是新手最容易卡住的地方。CentOS/RHEL 系更特殊7 之后默认源里根本没有 MySQL只有 MariaDB。要装 MySQL 8.4通常得去官网下载对应发行版的 repo 包装完后服务名、配置文件路径都和 MariaDB 略有出入。配置方面两者核心参数基本一致重点都在这几个innodb_buffer_pool_size我一般建议设为物理内存的 60% 到 75%纯读多可以再高点但别超过 80%否则留给系统和其他进程的内存太紧。max_connections别一上来就设 5000。每个连接都要占线程内存先按业务并发估算一般 500-2000 之间比较常见然后再看监控调整。binlog_format生产环境建议 ROW配合主从复制和数据恢复更安全。MySQL 8 开 GTID 也更常见。skip_name_resolve在高并发场景能减少 DNS 反查的开销但要注意所有授权账号得用 IP不能再用主机名。Docker 部署也很流行。MySQL 官方镜像用mysql:8.4MariaDB 用mariadb:lts两个镜像的初始化和挂载目录大体一致但环境变量名字不同MySQL 用MYSQL_ROOT_PASSWORDMariaDB 用MARIADB_ROOT_PASSWORD。另外在 ARM 平台、树莓派这类边缘设备上MariaDB 的发行版支持明显更顺滑装上就能跑MySQL 虽然也有官方镜像但很多 Linux 发行版的默认源里搜到的是mariadb-server而不是 MySQL这也解释了为什么“mariadb arm 客户端”这类搜索热度一直挺高。3.3 迁移实操逻辑备份 参数核对的关键步骤真到了迁移这一步我的标准流程是下面这样两个方向通用。第一步全量逻辑备份。用 mysqldump 或者 MariaDB 的 mariadb-dump核心参数是--single-transaction保证 InnoDB 一致性快照加上--routines --triggers --events把存储过程、触发器、定时事件都带出来再补--hex-blob避免二进制字段乱码。MySQL 8 导出时还要特别注意 GTID 相关语句备份时加--set-gtid-purgedOFF否则导入 MariaDB 时很容易报错。命令长这样mysqldump -u root -p \ --single-transaction --routines --triggers --events --hex-blob \ --set-gtid-purgedOFF \ --databases mydb mydb_$(date %F).sql第二步目标库导入。导入前先建好库和账号然后执行mysql -u root -p --default-character-setutf8mb4 mydb_2025-01-01.sql注意字符集一定要指定不然历史数据很可能在导入过程中被错误转码恢复完中文全变问号。第三步导入后做“五核对”核对表数量是否一致、抽样核对每张表的行数、检查外键约束是否完整、检查自增主键的 next value 是否正常、检查存储过程和触发器的编目状态。Before 和 After 各跑一遍select count(*) ...是笨办法但最可靠。第四步是应用切换。别直接一刀切切主库我习惯先让应用连到新库的只读副本跑一段时间观察慢查询日志和连接报错确认没问题再切写流量。切完之后保留旧库只读状态至少一两个星期方便随时回滚。3.4 常见问题排查速查表我把这些年实际遇到的高频问题整理成一张速查表你在群里帮人排查时可以直接抄现象可能原因处理办法Access denied for user rootlocalhost初始密码未取/认证方式不同查日志里的临时密码Debian 系 MariaDB 用sudo mysql先登录再改密码Client does not support authentication protocolMySQL 8 默认 caching_sha2_password 而客户端太老升级客户端驱动临时兼容才用ALTER USER ... IDENTIFIED WITH mysql_native_password BY ...ERROR 1010 (HY000): Error dropping database数据库物理目录有残留文件或权限异常检查 datadir 下对应目录手动清理残留文件再 DROP 或直接移走目录Navicat 连 MySQL 8 报认证错误同认证插件问题升级 Navicat 到 12或改账号插件Django 报MySQL 8.4 or later is required (found 8.0)ORM 新版本抬高数据库最低版本升级数据库到 8.4 LTS或锁定 ORM/框架版本迁移后中文乱码dump 或导入时字符集未指定统一使用--default-character-setutf8mb4再检查库表字符集系统 CPU 高但并发不高慢 SQL、索引失效、锁竞争开慢查询日志EXPLAIN分析执行计划检查锁等待general_log文件暴涨打开了 general log 且没轮转关闭general_logON或设置log_outputTABLE定期清理Microsoft Jet database engine 错误 80004005Access 通过 ODBC 连 MySQL 时位数不匹配保证 Access 和 MySQL ODBC 驱动同为 32 位或同为 64 位这里面最值得展开的是general_log的用法。很多线上问题应用层日志根本看不出来真正发到数据库的 SQL 才是元凶。把general_logON打开后所有 SQL 都会记录下来能帮你定位到底哪个接口发了什么异常查询。但注意生产环境别长时间开着这个日志增长速度极快我一般只在排查期间开一两个小时配合slow_query_log一起分析定位完立刻关掉。4. 生产环境选型到底该站哪一边4.1 云上数据库与自建 MySQL 的现实博弈现在做选型最先要回答的其实不是“用 MySQL 还是 MariaDB”而是“上不上云”。这个前提一变答案就完全不一样。如果你用的是阿里云、腾讯云、AWS 这些主流云厂商默认选项几乎必然是 MySQL 兼容引擎。云厂商的 MySQL 生态非常成熟自动备份、高可用切换、读写分离、审计日志、性能监控全都有很多运维能力是自建数据库根本追不上的。你要在这些云上找托管式 MariaDB选择面就窄很多要么是少数厂商提供但版本滞后要么你得自己在 ECS 上搭一套备份和高可用全部自己扛。反过来如果你是在内网 IDC 自建或者团队对云厂商没有强绑定那 MariaDB 的优势立刻就能体现出来。它没有 MySQL Enterprise 那些闭源功能带来的“心理落差”LTS 版本支持周期够长社区版功能完整还默认集成了 Galera 多主集群。对预算敏感、又不想被商业授权规则绑住手脚的团队MariaDB 是个非常现实的选择。这里我个人的态度是别跟平台逆着走。云厂商默认主推什么你就优先用什么除非有极其硬核的理由。数据库选型的终极目标是降低整体运维成本而不是在技术信仰上分高下。4.2 MariaDB 的长板恰恰是 MySQL 的短板抛开云环境单看产品本身MariaDB 有几个地方确实比 MySQL 社区版更舒服。第一是“纯开源”这个标签。MySQL 社区版虽然开源但 Oracle 把大量企业级功能线程池、审计、加密做进了闭源的 Enterprise 版里。MariaDB 的做法是把这类功能尽量放进 GPL 社区版里比如审计日志、线程池这些在 MariaDB 里都能直接用。对“不想碰商业扩展包”的团队来说这个差别很实际。第二是 Galera 多主集群。MariaDB 从 10.4 开始内置 Galera部署多主强同步集群的路径很平滑。MySQL 要实现类似能力得靠 InnoDB Cluster Group Replication 加 MySQL Shell 一套组合拳配置门槛高不少真正跑顺还需要不少调优经验。第三是轻量。同一台 2C4G 的云主机上MariaDB 的空闲内存占用通常比 MySQL 8 更小这在边缘节点、ARM 设备、树莓派这些资源紧张的场景里感受非常明显。所以“mariadb arm 客户端”这类需求热度一直不低很多 arm 生态项目默认就把 MariaDB 当成了首选数据库。第四是几个实用特性。系统版本表做数据回溯、SEQUENCE 做序列号管理都是 MariaDB 原生能力MySQL 得靠业务层自己变通实现。但这些长板也对应着短板MariaDB 的工具链生态、第三方兼容测试、云托管服务、岗位技能储备都明显弱于 MySQL。团队里如果都是熟悉 MySQL 的人MariaDB 上手容易去招聘市场找人MariaDB 专精的候选人明显比 MySQL 少一个量级。4.3 我的选型决策清单把上面的讨论收敛成一张决策清单你可以对着自己的项目逐条打勾项目要上主流云厂商托管数据库直接选 MySQL 8.x别折腾。自建且追求纯开源、不想看到“企业版专属”字样MariaDB 优先Percona Server 也可以考虑。存量代码大量依赖 MySQL 8 的 JSON、窗口函数、CTE留在 MySQL不要迁移。需要多主强同步集群且不想用商业方案MariaDB Galera 更省事。团队只会 MySQL 运维套路、希望零学习成本承接MariaDB 配置和命令几乎贴合 MySQL 习惯迁移难度可控。只是被“MySQL 已死”文章吓到深呼吸回到业务需求本身再选。5. 数据库巨头未来会走向哪里5.1 MySQL 8.4 LTS/9.x 还在认真迭代从产品动作看Oracle 对 MySQL 的投资并没有停。8.0 之后Oracle 把版本策略改成了“LTS 创新版”节奏8.1、8.2、8.3 是创新版8.4 做成长周期支持版本9.0、9.1 等继续以创新版形式推进。这种策略本质上是面向开发者社区示好想证明 MySQL 依然在快速演进。功能上也一直在往热点方向靠。JSON 能力持续增强、加入向量类型和相似度搜索、优化并发性能这些动作明显是在往 AI 应用、半结构化数据场景上押注。加上 MySQL HeatWave 这种把分析能力和 OLTP 揉在一起的方案Oracle 想在云时代继续保留 MySQL 的技术话语权。所以从代码活跃度和产品投入来看MySQL 离“死”字差着十万八千里。5.2 MariaDB 的商业化与社区双轨制MariaDB 这边商业路径确实比 MySQL 曲折。MariaDB plc 在 2022 年上市之后又经历了私有化私有调整商业故事讲得不算顺。但值得注意的一点是无论商业层面怎么变社区版 MariaDB 的发布节奏一直没断10.6 LTS、10.11 LTS、11.4 LTS 都按计划推进LTS 版本的支持周期也足够长生产环境有明确的可依赖版本。从社区情感角度看MariaDB 占了“正统继承人”的叙事优势。当年那批不信任 Oracle 的 MySQL 老用户很多是带着感情在做 MariaDB 的生态这是 MySQL 八竿子打不着的软实力。只要 Oracle 继续把 MySQL 的商业化边界往外推MariaDB 就能一直找到自己的存在意义。5.3 真正的威胁不是彼此而是云原生和 PostgreSQL最后聊点大势。MySQL 和 MariaDB 斗来斗去但两者真正的挑战已经变成了另外两个玩家云原生数据库和 PostgreSQL。云原生数据库在改变“数据库”这个概念本身。Serverless、按量付费、自动扩缩容、多活容灾已经不用你在底层数据库上花太多心思。像 Aurora 这样兼容 MySQL 协议的云原生数据库已经在抢“要不要自建 MySQL”这门生意。数据库的选型越来越变成“选哪个云服务”而不是“装哪个数据库软件”。PostgreSQL 则是另一个维度上的对手。它功能密度高、扩展能力强pgvector 等扩展又卡位了 AI 场景这两年声望一路走高很多新项目干脆直接在 MySQL 和 PostgreSQL 之间纠结根本不会想到 MariaDB。这种外部竞争比 MySQL 和 MariaDB 之间的内部消耗要致命得多。我对未来的判断是MySQL 会继续稳坐“开源关系型数据库一哥”的位置MariaDB 更像“数据库界的 Linux Mint”在特定用户圈里活得很好但很难逆转生态位。两者在短期十年内都死不了真正需要担心的是云原生和 PostgreSQL 把整个传统关系型数据库的市场蛋糕重新洗牌。我自己在实际项目里的体会是数据库选型最容易犯的错就是被技术情怀带偏。MySQL 也好MariaDB 也罢本质上都是工具关键看你的业务跑在什么环境、团队能维护哪个。如果硬要分享一个最值得记住的经验不管最后选了谁迁移后的第一个月一定把 slow_query_log 开着有条件的话再排查几轮 general_log把所有异常 SQL 捞出来过一遍。很多“换库之后变慢了”的案例根本不是数据库的锅而是连接池参数、索引统计、字符集处理没跟上。工具没有绝对的生死只有适不适合你的业务。
MySQL与MariaDB分家史：技术差异、迁移实战与生产选型指南
这几年的数据库圈隔三差五就会冒出“MySQL 是不是凉了”的讨论尤其当有人甩出那句“Is MySQL dead? Long live MariaDB”的时候评论区总能吵成一片。作为从 MySQL 5.5 一路用到 8.4、又亲手维护过 MariaDB 10.11 集群的从业者我先给个明确结论MySQL 没死MariaDB 也不是什么“取代者”两者是同根生的两兄弟只是走的路线越来越不一样了。这篇文章我不打算站队只把分家历史、技术差异、迁移实操、选型逻辑和未来走向一次讲清楚适合正在做数据库选型的后端开发者、运维和架构师参考。内容全部来自这些年的实际项目和踩坑记录不抄文档尽量说人话。1. “MySQL已死”的论调是从哪冒出来的1.1 十多年前那场收购埋下了一切的种子要理解“MySQL 已死”这个说法绕不开 2008 到 2009 年那两笔震动开源圈的收购。先是 Sun 买下 MySQL AB紧接着 Oracle 又把 Sun 整个吞了。消息一出大量 MySQL 老用户心里就咯噔一下一个靠开源社区起家的数据库落到了当时全球最大的商业数据库公司手里后面会发生什么谁都不敢打包票。最典型的反应来自 MySQL 创始人 Monty Widenius。他不仅公开表达了对 Oracle 的不信任还直接离开项目基于 MySQL 5.1 的代码分支创建了 MariaDB。这个名字来自他女儿 Maria等于从父辈到子辈都跟 MySQL 有血缘关系。MariaDB 最早几个版本基本就是 MySQL 5.1 加补丁改动并不大但随着版本迭代它和“正统 MySQL”之间的代码差异越来越大最终彻底成了独立的数据库产品。这段历史在技术圈留下的最大遗产是“信任”的分裂。很多企业不是因为 MariaDB 功能更强才换而是单纯不想把自己的核心数据库押注在一个不信任的厂商手里。这种情绪后来被不断放大成了“MySQL 已死”论调的原始土壤。1.2 “已死”信号到底指哪些事那为什么现在还有人说 MySQL “死了”我复盘了一下主要来自三个信号。第一个信号是操作系统的默认切换。从 CentOS/RHEL 7 开始系统自带的 mysql 命令实际指向的就是 MariaDBCentOS/RHEL 8 默认装上的更是 MariaDB 10.3Debian 9 之后也把默认数据库换成了 MariaDBFedora 更是早就切换过去了。这就造成一个很有名的名场面新手照着“MySQL 安装教程”去装数据库装完一执行mysql -V跳出来一串 “MariaDB”当场懵掉。对普通用户来说系统默认用谁谁看起来就更像“活的”。第二个信号是 Oracle 的商业化动作。MySQL 社区版一直还在但 Oracle 把大量高级功能做成了 Enterprise 闭源插件比如企业级审计、线程池、加密特性这些社区里想用只能另想办法。再叠加 Oracle 对 MySQL 的版本节奏、许可政策调整社区里那种“MySQL 被商业绑架了”的声音就没断过。第三个信号是几个明星项目高调迁移。最有名的就是 Wikipedia 从 MySQL 迁到了 MariaDB这给外界传递了一个信号连这么大的站点都跑了MySQL 是不是不行了再加上各种技术号为了流量反复渲染“MySQL 衰败论”久而久之“MySQL 已死”就成了数据库圈的月经话题。1.3 说句公道话MySQL 的非官方讣告写早了但现实和情绪是两回事。到今天为止MySQL 社区版依然在按固定节奏迭代8.4 LTS 在 2024 年发布9.x 创新版也持续推出全球数据库排名里 MySQL 常年稳居第二仅次于 Oracle 数据库本身。更关键的是云厂商在这件事上的押注极其明确阿里云 RDS MySQL、腾讯云 TDSQL-C for MySQL、AWS Aurora MySQL清一色基于 MySQL 生态开发。国内很多号称“国产自研”的分布式数据库协议层也都是兼容 MySQL 的。再看就业市场Java 后端面试题里 MySQL 永远是重头戏从索引到事务、从执行计划到主从复制“mysql 面试题”这类搜索常年居高不下。一个真正“死了”的数据库不可能每天还有这么多人围绕它找工作、做培训、写适配层。所以我的判断很直接MySQL 的讣告被写早了而且写它的人大多数根本不在生产环境里维护过 MySQL。2. MariaDB 和 MySQL到底差在哪2.1 版本号背后的“分道扬镳”想搞明白两者的差异先从版本号说起。MySQL 的演进路径是 5.5 → 5.6 → 5.7 → 8.08.0 之后又改成 8.4 LTS 9.x 创新版的发布节奏。MariaDB 早期版本号完全对齐 MySQL比如 5.5 就是对齐 MySQL 5.5后来改用 10.0 对齐 MySQL 5.610.1 对齐 MySQL 5.7从 10.2 开始加入了很多 MySQL 8.0 才有的特性比如窗口函数、CTE、CHECK 约束。但从 10.2 之后MariaDB 就不打算再跟 MySQL 一一对表了直接走出自己的节奏10.3、10.4、10.5、10.6 LTS、10.11 LTS再到 11.x 系列。这就带来一个非常实际的问题网上大量“MySQL 8.0 教程”里说的功能放到 MariaDB 10.11 上可能能用也可能不能用反过来用 MariaDB 的经验去套 MySQL 8.4也会踩坑。版本号不再对应之后兼容性全靠实测不能靠“凭感觉”。2.2 存储引擎与核心功能的取舍我把两者在生产环境中最容易感知到的差异整理成了一张表方便你对照项目需求快速判断功能点MySQL 8.0 / 8.4MariaDB 10.11 / 11.x默认存储引擎InnoDBInnoDB原生 JSON 类型支持二进制 JSON JSON_TABLE不支持JSON 是 LONGTEXT 的别名窗口函数8.0 起支持10.2 起支持CTE 公用表表达式8.0 起支持10.2 起支持CHECK 约束8.0.16 起支持10.2.1 起支持独立序列 SEQUENCE无只能用 AUTO_INCREMENT10.3 起原生支持 CREATE SEQUENCE系统版本表无10.3 起支持 WITH SYSTEM VERSIONING数据库角色 ROLE8.0 起支持10.0.5 起支持默认认证插件caching_sha2_passwordmysql_native_password内置 Galera 多主集群无需额外配置组复制 中间件10.4 起内置内存占用相对较高相对更低这张表看着简单但每个差异背后都是实际业务坑。比如你的应用要是用了 MySQL 8.0 的 JSON 函数做复杂查询迁到 MariaDB 就得小心它的 JSON 字段本质是字符串JSON_EXTRACT 这类函数虽然也有但存储格式、索引方式、排序行为都跟 MySQL 8 的原生 JSON 不一样线上数据量大以后性能差异会非常明显。反过来如果你需要“历史数据可回溯”这种需求MariaDB 的系统版本表开箱即用MySQL 8 反而没有这个功能得靠业务层自己实现或者依赖企业版的 flashback 能力。2.3 从热搜问题看兼容性最大的几个坑我翻了翻大家日常搜得最多的问题发现很多坑其实都源于“两个库用一个经验”。挑几个典型的说说。第一个是 MySQL 8.0 的认证插件问题。从 8.0 开始 MySQL 默认启用 caching_sha2_password而 MariaDB 默认还用着 mysql_native_password。这就导致老版本的 Navicat、老旧 JDBC 驱动去连 MySQL 8.0 时直接报 “Client does not support authentication protocol requested by server”。很多人以为是密码错了其实是协议不兼容。临时办法是给账号改回老插件但从 MySQL 8.4 开始这个老插件默认被禁用所以我更建议直接升级客户端和驱动别再留恋老古董。第二个是drop database报错 1010。这个问题在搜“drop database leshanshop”相关报错时特别典型报错信息类似ERROR 1010 (HY000): Error dropping database (cant rmdir ./xxx/, errno: 39)。核心原因通常是数据库目录里有 MySQL 不认识或没删干净的文件比如之前手动往 datadir 里丢过东西或者文件权限不对。处理思路是先ls看目录里残留了什么确认无价值后手动清理再让数据库重试 DROP如果目录删不掉也可以先把目录移走库里执行 DROP 清掉元数据再手动处理物理目录。第三个是框架主动抬高新版要求。这两年 Django、一些 ORM 框架已经把最低支持的 MySQL 版本抬到了 8.x 甚至更高老库不升级新框架版本就装不上、跑不动。这类问题本质上是生态在倒逼 MySQL 版本升级而不是数据库本身出了毛病。第四个我觉得很值得点名的是“初始密码”问题。很多人用包管理器装完 MySQL 后习惯性地用 root 空密码登录结果怎么都登不上。原因要分场景用 MySQL 官方仓库装初始随机密码写在日志里用系统自带的 MariaDBDebian 系默认走 unix_socket 认证需要sudo mysql才能进。搞清楚自己到底装的是谁、用的什么认证方式是解决这类问题的最快路径。3. 实操指南迁移、安装、调优一次讲清3.1 选型前先做一次体检我的迁移检查清单不管你是要从 MySQL 迁移到 MariaDB还是从 MariaDB 兜回 MySQL我都强烈建议先做一轮“数据库体检”不要脑子一热就直接mysqldump。体检的核心是搞清楚你的存量业务到底踩了哪些“专属特性”。我的体检清单一般是这几项版本和驱动体检登录每个库执行SELECT VERSION()把应用侧 JDBC/ODBC/PHP 扩展版本列出来逐项确认是否支持目标库的认证方式。字符集与排序规则检查SHOW VARIABLES LIKE character_set%重点看 utf8mb4 是否统一排序规则在 MySQL 8 里常见的是 utf8mb4_0900_ai_ciMariaDB 里更常见的是 utf8mb4_general_ci迁移后排序结果可能不一样。SQL 模式体检执行SELECT sql_mode如果业务依赖 ONLY_FULL_GROUP_BY 之外的宽松模式迁移后很可能报 SQL 错误。存储引擎体检执行SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine InnoDB找出所有 MyISAM、MEMORY 表评估是否需要转换。高风险 SQL 扫描去代码库里搜所有用到了 JSON 函数、窗口函数、CTE、INSERT IGNORE、REPLACE INTO、UPDATE ... JOIN的地方逐个确认目标库语法支持度。备份恢复演练别等机房断电才第一次做恢复先在测试环境完整跑一遍备份和恢复记录耗时。体检花半天后面能少熬一个月。我见过太多人跳过这步结果迁移完第二天接口全挂最后逐条捞慢 SQL 捞到头秃。3.2 安装配置CentOS 系与 Debian 系的差异安装这块网上教程多如牛毛但很多都没讲清楚“装的是哪个”。分两个系统来说。Debian/Ubuntu 系里apt install mysql-server和apt install mariadb-server是两个独立包想装谁就装谁装完后mysql -V能直接看出是哪个。需要注意Debian 系的 MariaDB 默认 root 走 unix_socket 认证直接mysql -uroot -p是登不进去的得sudo mysql这是新手最容易卡住的地方。CentOS/RHEL 系更特殊7 之后默认源里根本没有 MySQL只有 MariaDB。要装 MySQL 8.4通常得去官网下载对应发行版的 repo 包装完后服务名、配置文件路径都和 MariaDB 略有出入。配置方面两者核心参数基本一致重点都在这几个innodb_buffer_pool_size我一般建议设为物理内存的 60% 到 75%纯读多可以再高点但别超过 80%否则留给系统和其他进程的内存太紧。max_connections别一上来就设 5000。每个连接都要占线程内存先按业务并发估算一般 500-2000 之间比较常见然后再看监控调整。binlog_format生产环境建议 ROW配合主从复制和数据恢复更安全。MySQL 8 开 GTID 也更常见。skip_name_resolve在高并发场景能减少 DNS 反查的开销但要注意所有授权账号得用 IP不能再用主机名。Docker 部署也很流行。MySQL 官方镜像用mysql:8.4MariaDB 用mariadb:lts两个镜像的初始化和挂载目录大体一致但环境变量名字不同MySQL 用MYSQL_ROOT_PASSWORDMariaDB 用MARIADB_ROOT_PASSWORD。另外在 ARM 平台、树莓派这类边缘设备上MariaDB 的发行版支持明显更顺滑装上就能跑MySQL 虽然也有官方镜像但很多 Linux 发行版的默认源里搜到的是mariadb-server而不是 MySQL这也解释了为什么“mariadb arm 客户端”这类搜索热度一直挺高。3.3 迁移实操逻辑备份 参数核对的关键步骤真到了迁移这一步我的标准流程是下面这样两个方向通用。第一步全量逻辑备份。用 mysqldump 或者 MariaDB 的 mariadb-dump核心参数是--single-transaction保证 InnoDB 一致性快照加上--routines --triggers --events把存储过程、触发器、定时事件都带出来再补--hex-blob避免二进制字段乱码。MySQL 8 导出时还要特别注意 GTID 相关语句备份时加--set-gtid-purgedOFF否则导入 MariaDB 时很容易报错。命令长这样mysqldump -u root -p \ --single-transaction --routines --triggers --events --hex-blob \ --set-gtid-purgedOFF \ --databases mydb mydb_$(date %F).sql第二步目标库导入。导入前先建好库和账号然后执行mysql -u root -p --default-character-setutf8mb4 mydb_2025-01-01.sql注意字符集一定要指定不然历史数据很可能在导入过程中被错误转码恢复完中文全变问号。第三步导入后做“五核对”核对表数量是否一致、抽样核对每张表的行数、检查外键约束是否完整、检查自增主键的 next value 是否正常、检查存储过程和触发器的编目状态。Before 和 After 各跑一遍select count(*) ...是笨办法但最可靠。第四步是应用切换。别直接一刀切切主库我习惯先让应用连到新库的只读副本跑一段时间观察慢查询日志和连接报错确认没问题再切写流量。切完之后保留旧库只读状态至少一两个星期方便随时回滚。3.4 常见问题排查速查表我把这些年实际遇到的高频问题整理成一张速查表你在群里帮人排查时可以直接抄现象可能原因处理办法Access denied for user rootlocalhost初始密码未取/认证方式不同查日志里的临时密码Debian 系 MariaDB 用sudo mysql先登录再改密码Client does not support authentication protocolMySQL 8 默认 caching_sha2_password 而客户端太老升级客户端驱动临时兼容才用ALTER USER ... IDENTIFIED WITH mysql_native_password BY ...ERROR 1010 (HY000): Error dropping database数据库物理目录有残留文件或权限异常检查 datadir 下对应目录手动清理残留文件再 DROP 或直接移走目录Navicat 连 MySQL 8 报认证错误同认证插件问题升级 Navicat 到 12或改账号插件Django 报MySQL 8.4 or later is required (found 8.0)ORM 新版本抬高数据库最低版本升级数据库到 8.4 LTS或锁定 ORM/框架版本迁移后中文乱码dump 或导入时字符集未指定统一使用--default-character-setutf8mb4再检查库表字符集系统 CPU 高但并发不高慢 SQL、索引失效、锁竞争开慢查询日志EXPLAIN分析执行计划检查锁等待general_log文件暴涨打开了 general log 且没轮转关闭general_logON或设置log_outputTABLE定期清理Microsoft Jet database engine 错误 80004005Access 通过 ODBC 连 MySQL 时位数不匹配保证 Access 和 MySQL ODBC 驱动同为 32 位或同为 64 位这里面最值得展开的是general_log的用法。很多线上问题应用层日志根本看不出来真正发到数据库的 SQL 才是元凶。把general_logON打开后所有 SQL 都会记录下来能帮你定位到底哪个接口发了什么异常查询。但注意生产环境别长时间开着这个日志增长速度极快我一般只在排查期间开一两个小时配合slow_query_log一起分析定位完立刻关掉。4. 生产环境选型到底该站哪一边4.1 云上数据库与自建 MySQL 的现实博弈现在做选型最先要回答的其实不是“用 MySQL 还是 MariaDB”而是“上不上云”。这个前提一变答案就完全不一样。如果你用的是阿里云、腾讯云、AWS 这些主流云厂商默认选项几乎必然是 MySQL 兼容引擎。云厂商的 MySQL 生态非常成熟自动备份、高可用切换、读写分离、审计日志、性能监控全都有很多运维能力是自建数据库根本追不上的。你要在这些云上找托管式 MariaDB选择面就窄很多要么是少数厂商提供但版本滞后要么你得自己在 ECS 上搭一套备份和高可用全部自己扛。反过来如果你是在内网 IDC 自建或者团队对云厂商没有强绑定那 MariaDB 的优势立刻就能体现出来。它没有 MySQL Enterprise 那些闭源功能带来的“心理落差”LTS 版本支持周期够长社区版功能完整还默认集成了 Galera 多主集群。对预算敏感、又不想被商业授权规则绑住手脚的团队MariaDB 是个非常现实的选择。这里我个人的态度是别跟平台逆着走。云厂商默认主推什么你就优先用什么除非有极其硬核的理由。数据库选型的终极目标是降低整体运维成本而不是在技术信仰上分高下。4.2 MariaDB 的长板恰恰是 MySQL 的短板抛开云环境单看产品本身MariaDB 有几个地方确实比 MySQL 社区版更舒服。第一是“纯开源”这个标签。MySQL 社区版虽然开源但 Oracle 把大量企业级功能线程池、审计、加密做进了闭源的 Enterprise 版里。MariaDB 的做法是把这类功能尽量放进 GPL 社区版里比如审计日志、线程池这些在 MariaDB 里都能直接用。对“不想碰商业扩展包”的团队来说这个差别很实际。第二是 Galera 多主集群。MariaDB 从 10.4 开始内置 Galera部署多主强同步集群的路径很平滑。MySQL 要实现类似能力得靠 InnoDB Cluster Group Replication 加 MySQL Shell 一套组合拳配置门槛高不少真正跑顺还需要不少调优经验。第三是轻量。同一台 2C4G 的云主机上MariaDB 的空闲内存占用通常比 MySQL 8 更小这在边缘节点、ARM 设备、树莓派这些资源紧张的场景里感受非常明显。所以“mariadb arm 客户端”这类需求热度一直不低很多 arm 生态项目默认就把 MariaDB 当成了首选数据库。第四是几个实用特性。系统版本表做数据回溯、SEQUENCE 做序列号管理都是 MariaDB 原生能力MySQL 得靠业务层自己变通实现。但这些长板也对应着短板MariaDB 的工具链生态、第三方兼容测试、云托管服务、岗位技能储备都明显弱于 MySQL。团队里如果都是熟悉 MySQL 的人MariaDB 上手容易去招聘市场找人MariaDB 专精的候选人明显比 MySQL 少一个量级。4.3 我的选型决策清单把上面的讨论收敛成一张决策清单你可以对着自己的项目逐条打勾项目要上主流云厂商托管数据库直接选 MySQL 8.x别折腾。自建且追求纯开源、不想看到“企业版专属”字样MariaDB 优先Percona Server 也可以考虑。存量代码大量依赖 MySQL 8 的 JSON、窗口函数、CTE留在 MySQL不要迁移。需要多主强同步集群且不想用商业方案MariaDB Galera 更省事。团队只会 MySQL 运维套路、希望零学习成本承接MariaDB 配置和命令几乎贴合 MySQL 习惯迁移难度可控。只是被“MySQL 已死”文章吓到深呼吸回到业务需求本身再选。5. 数据库巨头未来会走向哪里5.1 MySQL 8.4 LTS/9.x 还在认真迭代从产品动作看Oracle 对 MySQL 的投资并没有停。8.0 之后Oracle 把版本策略改成了“LTS 创新版”节奏8.1、8.2、8.3 是创新版8.4 做成长周期支持版本9.0、9.1 等继续以创新版形式推进。这种策略本质上是面向开发者社区示好想证明 MySQL 依然在快速演进。功能上也一直在往热点方向靠。JSON 能力持续增强、加入向量类型和相似度搜索、优化并发性能这些动作明显是在往 AI 应用、半结构化数据场景上押注。加上 MySQL HeatWave 这种把分析能力和 OLTP 揉在一起的方案Oracle 想在云时代继续保留 MySQL 的技术话语权。所以从代码活跃度和产品投入来看MySQL 离“死”字差着十万八千里。5.2 MariaDB 的商业化与社区双轨制MariaDB 这边商业路径确实比 MySQL 曲折。MariaDB plc 在 2022 年上市之后又经历了私有化私有调整商业故事讲得不算顺。但值得注意的一点是无论商业层面怎么变社区版 MariaDB 的发布节奏一直没断10.6 LTS、10.11 LTS、11.4 LTS 都按计划推进LTS 版本的支持周期也足够长生产环境有明确的可依赖版本。从社区情感角度看MariaDB 占了“正统继承人”的叙事优势。当年那批不信任 Oracle 的 MySQL 老用户很多是带着感情在做 MariaDB 的生态这是 MySQL 八竿子打不着的软实力。只要 Oracle 继续把 MySQL 的商业化边界往外推MariaDB 就能一直找到自己的存在意义。5.3 真正的威胁不是彼此而是云原生和 PostgreSQL最后聊点大势。MySQL 和 MariaDB 斗来斗去但两者真正的挑战已经变成了另外两个玩家云原生数据库和 PostgreSQL。云原生数据库在改变“数据库”这个概念本身。Serverless、按量付费、自动扩缩容、多活容灾已经不用你在底层数据库上花太多心思。像 Aurora 这样兼容 MySQL 协议的云原生数据库已经在抢“要不要自建 MySQL”这门生意。数据库的选型越来越变成“选哪个云服务”而不是“装哪个数据库软件”。PostgreSQL 则是另一个维度上的对手。它功能密度高、扩展能力强pgvector 等扩展又卡位了 AI 场景这两年声望一路走高很多新项目干脆直接在 MySQL 和 PostgreSQL 之间纠结根本不会想到 MariaDB。这种外部竞争比 MySQL 和 MariaDB 之间的内部消耗要致命得多。我对未来的判断是MySQL 会继续稳坐“开源关系型数据库一哥”的位置MariaDB 更像“数据库界的 Linux Mint”在特定用户圈里活得很好但很难逆转生态位。两者在短期十年内都死不了真正需要担心的是云原生和 PostgreSQL 把整个传统关系型数据库的市场蛋糕重新洗牌。我自己在实际项目里的体会是数据库选型最容易犯的错就是被技术情怀带偏。MySQL 也好MariaDB 也罢本质上都是工具关键看你的业务跑在什么环境、团队能维护哪个。如果硬要分享一个最值得记住的经验不管最后选了谁迁移后的第一个月一定把 slow_query_log 开着有条件的话再排查几轮 general_log把所有异常 SQL 捞出来过一遍。很多“换库之后变慢了”的案例根本不是数据库的锅而是连接池参数、索引统计、字符集处理没跟上。工具没有绝对的生死只有适不适合你的业务。 
