MySQL 5.7还是8.0？新项目主流大版本选择指南

不晚

发布时间：2026-09-20 | 4人浏览过

原创

如果只在 MySQL 5.7 和 8.0 之间二选一，新项目应优先选择 8.0，而不是继续从 5.7 起步。不过这里有一个很重要的时间条件：截至 2026 年，MySQL 5.7 早已进入 Sustaining Support，而 MySQL 8.0 也已在 2026 年 4 月随 8.0.46 到达生命周期终点。Oracle 官方已经建议 8.0 用户升级到 MySQL 8.4 LTS 或更新发行系列。因此，对今天真正从零开始的长期项目来说，更合理的选择通常是 MySQL 8.4 LTS；如果现有环境只允许在 5.7 和 8.0 中选择，则把 8.0 作为兼容或过渡版本更合适。 :contentReference[oaicite:0]{index=0}

先看结论：5.7 和 8.0 应该怎么选

版本选择可以直接按项目情况判断，不需要先比较几十项参数。

项目情况	选择建议	主要原因
维护历史 MySQL 5.7 系统	可以暂时保留 5.7	重点应放在稳定维护和制定升级计划，而不是为了版本统一立即重构。
旧应用只能兼容 5.7	短期保留 5.7	需要先解决驱动、SQL、字符集和业务程序兼容问题。
环境限定只能选 5.7 或 8.0	优先 8.0	功能、数据字典、认证机制和 SQL 能力更接近后续版本。
2026 年新建长期运行项目	优先考虑 8.4 LTS	8.0 已结束生命周期，8.4 属于新的 LTS 系列。
准备从 5.7 升级现有系统	先完成兼容检查	不能简单替换二进制文件后就认为迁移结束。

MySQL 5.7、8.0与8.4 LTS的新项目版本选择关系图 — 图1：截至 2026 年，5.7 与 8.0 更适合作为历史兼容问题讨论，新项目应同时考虑 8.4 LTS。

为什么新项目不应该再从 MySQL 5.7 开始

MySQL 5.7 本身并不是一个“不能用”的数据库版本。大量已经稳定运行多年的业务仍可能建立在 5.7 上，继续维护这类系统完全是正常情况。问题在于，维护旧系统和创建新系统是两个不同的决策。

Oracle 在 2023 年 10 月已经宣布 MySQL 5.7 进入 Sustaining Support，并建议用户升级到 MySQL 8.0。对于新项目来说，再主动选择 5.7，意味着一开始就建立在已经退出常规产品生命周期的旧版本上。 :contentReference[oaicite:1]{index=1}

这会带来一个很现实的问题：即使第一天开发没有障碍，后续框架、数据库驱动、管理工具、云服务和运维流程都会越来越倾向更新版本。你可能暂时减少了一点兼容改造，却把版本迁移工作推到了项目运行以后。

因此，下面这些理由通常不足以成为新项目选择 5.7 的依据：

以前一直使用 5.7，所以比较熟悉；
网上关于 5.7 的教程很多；
旧项目的 SQL 可以直接复制过来；
担心 8.x 功能更多，所以一定更占资源；
团队暂时没有使用 8.x 新语法。

真正能够让 5.7 继续存在的理由，通常是明确的历史兼容限制，例如某套封闭商业软件只认证 5.7、旧驱动无法更换，或者当前业务必须与已有 5.7 集群保持一致。

如果只比较 5.7 和 8.0，8.0 的实际变化在哪里

选择数据库版本不能只看“版本号更新了”。对应用开发真正有影响的，是 SQL 能力、字符集、认证方式、元数据结构以及升级行为。

1. SQL 表达能力明显增强

MySQL 8.0 支持公共表表达式 CTE，包括递归 CTE，也支持窗口函数。对于排行榜、分组排名、逐行累计、树形结构查询等场景，可以少写很多嵌套查询或应用层代码。 :contentReference[oaicite:2]{index=2}

例如，需要计算每个部门内部员工的工资排名，在 MySQL 8.0 中可以直接写：

SELECT
    id,
    department_id,
    name,
    salary,
    DENSE_RANK() OVER (
        PARTITION BY department_id
        ORDER BY salary DESC
    ) AS salary_rank
FROM employee;

窗口函数不会像普通 GROUP BY 那样把多行合并成一行，因此特别适合“保留原始记录，同时进行排名或统计”的查询。

CTE 则可以让复杂 SQL 更容易拆解。例如：

WITH high_salary AS (
    SELECT id, name, department_id, salary
    FROM employee
    WHERE salary >= 20000
)
SELECT department_id, COUNT(*) AS employee_count
FROM high_salary
GROUP BY department_id;

这并不意味着项目必须使用这些新语法，而是说明选择 8.x 后，数据库层具有更大的表达空间。

2. 索引管理方式更灵活

MySQL 8.0 增加了不可见索引和真正的降序索引等能力。不可见索引仍然会被数据库维护，但默认不会被优化器选择，因此在准备删除某个索引时，可以先把索引设置为不可见，观察业务查询是否受到影响。 :contentReference[oaicite:3]{index=3}

ALTER TABLE orders
ALTER INDEX idx_user_created INVISIBLE;

如果观察后发现查询性能下降，可以重新恢复：

ALTER TABLE orders
ALTER INDEX idx_user_created VISIBLE;

相比直接删除再重新创建索引，这种方式更适合生产环境中的索引验证。

3. 数据字典和 DDL 机制发生变化

MySQL 8.0 引入事务型数据字典，字典数据存储在 InnoDB 表中，可以使用与普通 InnoDB 数据类似的提交、回滚和崩溃恢复机制。它也是 MySQL 8.0 实现原子 DDL 的基础。 :contentReference[oaicite:4]{index=4}

对于应用开发人员来说，这种变化平时并不会直接出现在业务代码里，但对数据库升级、元数据管理以及 DDL 可靠性有实际影响。

MySQL 5.7和8.0关键能力差异示意图 — 图2：MySQL 8.0 相比 5.7 的主要变化集中在 SQL、索引、数据字典及 DDL 等实际能力上。

字符集是新项目很容易忽略的一项差异

MySQL 8.0 默认服务器字符集为 utf8mb4，默认排序规则为 utf8mb4_0900_ai_ci。 :contentReference[oaicite:5]{index=5}

这对新项目通常是好事，因为现代 Web 系统往往直接需要完整 Unicode 支持。不过，从 5.7 迁移到 8.0 时不能简单认为“都是 utf8mb4，所以结果一定一样”。排序规则变化可能影响字符串比较、排序结果和唯一索引判断。

新项目建议在建库时明确指定，而不是完全依赖服务器默认值。例如：

CREATE DATABASE app_db
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

如果项目必须与旧系统保持一致，则应先查看旧数据库实际使用的字符集和排序规则：

SELECT
    DEFAULT_CHARACTER_SET_NAME,
    DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = 'app_db';

迁移项目中尤其要检查包含用户名、编码、业务编号等唯一字符串字段的表，避免因为排序规则变化而出现此前未暴露的重复值。

认证方式是 5.7 升 8.0 最常见的连接兼容问题之一

MySQL 8.0 默认认证插件改为 caching_sha2_password，而不是旧版本常见的 mysql_native_password。官方也明确建议使用支持新认证方式的客户端和连接器。 :contentReference[oaicite:6]{index=6}

因此，一个旧项目升级数据库以后，如果程序出现类似“数据库账号密码明明正确，但无法连接”的情况，不应该立即怀疑数据库损坏。更合理的排查顺序是：

确认应用使用的语言和框架版本；
确认 MySQL 驱动版本；
确认驱动是否支持 caching_sha2_password；
再检查账号本身使用的认证插件和连接加密配置。

可以在数据库中查看账户使用的插件：

SELECT
    user,
    host,
    plugin
FROM mysql.user
ORDER BY user, host;

不要因为旧驱动不支持就把“永久改回旧认证方式”当成新项目默认方案。更好的处理方式通常是升级应用端连接器，使整个技术栈与新版本 MySQL 保持一致。

MySQL 8.0 并不意味着所有查询都会自动更快

版本选择时还有一个常见误区：认为 8.0 是新版本，所以同一套业务迁过去一定更快。

8.0 的优化器、索引能力和内部机制确实有许多改进，但数据库性能受 SQL 写法、数据分布、索引设计、内存、存储设备以及配置参数共同影响。更换大版本后，部分 SQL 的执行计划也可能发生变化。

因此，生产项目不应该用“新版本肯定更快”代替压测。真正需要验证的是自己的工作负载，例如：

接口最常执行的 20～50 条核心 SQL；
订单、日志、内容等大表的范围查询；
分页和排序查询；
复杂 JOIN；
批量 INSERT、UPDATE；
高并发连接情况下的响应时间；
备份、恢复和复制链路。

对关键 SQL，可以分别执行 EXPLAIN 或 EXPLAIN ANALYZE 等分析方式，并观察实际索引和执行计划，而不是只比较数据库启动后的空闲内存。

新项目选择版本时，按这四步检查最稳妥

如果正在搭建 PHP、Java、Python、Node.js 或其他 Web 项目，可以按照下面的顺序完成版本决策。

第一步：先看官方生命周期，而不是只看网上教程数量

新项目预期可能运行三年、五年甚至更长时间。数据库版本剩余的支持周期比“现在能不能安装成功”重要得多。

截至 2026 年，MySQL 官方的发行模式已经明确区分 LTS 与 Innovation。LTS 面向需要稳定功能集合和较长支持周期的生产环境；Innovation 更偏向希望较快获得新功能、并具有完善自动化测试与升级能力的环境。 :contentReference[oaicite:7]{index=7}

普通企业网站、CMS、商城、内容平台和后台管理系统，如果没有追逐最新数据库功能的需要，通常更容易从 LTS 路线获得稳定的维护节奏。

第二步：检查应用框架和数据库驱动

例如一个项目采用：

PHP / Java / Python / Node.js
        ↓
数据库连接驱动
        ↓
MySQL Server

真正与数据库协议打交道的是连接驱动。即使业务代码完全没有变化，驱动过旧也可能因为认证协议、TLS 或服务器行为差异出现问题。

因此应该先确认：

当前语言运行时是否仍处于维护状态；
ORM 或数据库组件是否明确支持目标 MySQL 版本；
连接驱动是否支持目标版本使用的认证方式；
部署环境中的管理和备份工具是否兼容。

第三步：验证 SQL 和表结构

如果项目是从旧代码库复制出来的新项目，尤其不能因为“新建数据库”就忽略兼容性。

重点检查：

是否使用被废弃或删除的语法；
字段名称是否与新版本保留关键字冲突；
sql_mode 差异是否暴露不规范 SQL；
字符集和排序规则是否符合预期；
日期字段中是否存在不规范数据；
ORM 自动生成 SQL 是否可以正常运行。

第四步：用真实数据进行验证

不要只创建一张测试表，然后认为数据库版本已经验证完毕。至少应该导入接近真实结构的数据，跑一次主要接口、后台查询、定时任务和数据导入流程。

新项目选择MySQL版本的四步检查流程 — 图3：选择 MySQL 版本时，可以按生命周期、驱动、SQL 兼容和真实负载四个步骤逐层确认。

已有 MySQL 5.7 项目升级 8.0，不能直接当成新安装

如果当前已经运行 MySQL 5.7，问题就从“选择哪个版本”变成了“如何安全升级”。官方支持从 MySQL 5.7 GA 版本升级到 MySQL 8.0，并建议先升级到最新的 5.7 版本，再进入下一版本系列。 :contentReference[oaicite:8]{index=8}

生产环境升级前，至少应完成下面几个动作：

完整备份数据库，并实际验证备份可以恢复；
在测试环境复制生产数据；
运行升级兼容性检查；
检查废弃语法、字符集、排序规则和认证方式；
升级应用端 MySQL 驱动；
执行核心业务回归测试；
重新检查关键 SQL 执行计划；
确认备份、监控和复制系统仍正常工作；
再安排生产环境切换。

MySQL 官方提供 MySQL Shell Upgrade Checker，可以帮助检查实例升级目标版本时存在的潜在兼容问题。 :contentReference[oaicite:9]{index=9}

需要特别注意：从 MySQL 8.0 回到 MySQL 5.7 不属于受支持的降级路径。升级前应该保留可恢复的完整备份和明确的回退方案，而不是假设升级失败后直接换回旧版本二进制文件即可。 :contentReference[oaicite:10]{index=10}

什么时候仍然可能选择 MySQL 5.7

虽然不建议新项目主动采用 5.7，但现实中仍然存在合理的例外。

例如，一家公司运行一套十年前开发的业务系统，软件供应商明确规定只能使用 MySQL 5.7，同时程序依赖无法升级的数据库组件。这时立即把数据库换成更新版本，可能会引入比继续运行 5.7 更大的业务风险。

这种情况下正确的策略不是声称“5.7 更稳定”，而是承认这是一个兼容性约束：

旧系统继续使用经过验证的 5.7 环境；
限制其暴露范围并加强备份与监控；
不要再让新的独立系统继续依赖 5.7；
制定应用改造和数据库迁移路线。

也就是说，5.7 可以因为历史原因继续存在，但这和“适合今天的新项目”不是一回事。

什么时候会暂时选择 MySQL 8.0

虽然 8.0 已经结束其生命周期，但某些环境仍可能暂时以 8.0 作为现实中的兼容版本。例如：

某个云数据库产品当前项目环境只提供特定的 8.0 规格；
商业软件明确认证到 8.0，但尚未认证 8.4；
企业内部数据库平台统一停留在 8.0；
正在进行 5.7 → 8.0 → 8.4 的阶段性迁移。

在这些场景中使用 8.0 并不等于版本选择错误，但应该把后续升级纳入项目设计，而不是把 8.0 当作未来多年无需变化的最终版本。

如果现在新建数据库，更实用的版本决策方法

因此，“MySQL 5.7 还是 8.0”这个问题，在不同时间点会得到不同答案。

几年前，这个问题的重点可能是“旧版 5.7 还是新版 8.0”；到了 2026 年，官方版本生命周期已经发生变化，更合理的理解方式变成：

历史 MySQL 5.7 项目：继续稳定维护，同时准备迁移。
历史 MySQL 8.0 项目：检查升级到当前 LTS 的计划。
只能在 5.7 与 8.0 二选一的兼容环境：通常优先 8.0。
完全从零开始的新项目：直接评估当前 MySQL LTS 系列，2026 年应重点考虑 MySQL 8.4 LTS。

总结

如果问题严格限定为“MySQL 5.7 还是 8.0”，答案比较明确：新项目不应再从 5.7 开始，在二者之间应优先 8.0。8.0 提供 CTE、窗口函数、不可见索引、事务型数据字典、更现代的认证机制等能力，也更接近后续 MySQL 的架构和使用方式。

但版本选择必须带上时间条件。截至 2026 年 9 月，MySQL 5.7 已处于 Sustaining Support，MySQL 8.0 也已经在 2026 年 4 月达到 EOL。Oracle 官方建议 8.0 用户迁移到 MySQL 8.4 LTS 或后续发行系列。 :contentReference[oaicite:11]{index=11}

因此，如果正在维护旧系统，可以根据兼容性决定何时升级；如果受到平台限制只能在 5.7 和 8.0 之间选择，通常选择 8.0；如果是没有历史包袱、准备长期运行的全新项目，则不应再把 5.7 与 8.0 当成唯一候选，而应直接从当前受支持的 LTS 版本开始评估。

无论最终使用哪个版本，上线前都应该完成驱动兼容、字符集与排序规则、SQL 行为、核心查询性能、备份恢复以及升级路径验证。这些检查比单纯比较“哪个版本快”更能决定数据库在实际项目中能否稳定使用。

资料核对： 本文涉及 MySQL 5.7 支持状态、MySQL 8.0 EOL、8.4 LTS、认证插件、字符集、升级路径、窗口函数、CTE、不可见索引和数据字典等时效性信息，依据 MySQL 官方 Reference Manual、Release Notes 与 Support EOL 公告核对。 :contentReference[oaicite:12]{index=12}