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

如果只在 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 开始

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 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}

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

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

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

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 5.7 项目升级 8.0，不能直接当成新安装

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

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

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

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

什么时候仍然可能选择 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 行为、核心查询性能、备份恢复以及升级路径验证。这些检查比单纯比较“哪个版本快”更能决定数据库在实际项目中能否稳定使用。