MySQL 8.0 与 MySQL 5.7 之间，确实存在几处 SQL 语法层面的“硬断点”，数据库升级或迁移时基本无法绕开：GRANT 语句已经不再支持 IDENTIFIED BY，必须拆分为 CREATE USER + GRANT 两步执行；CREATE USER 也需要把认证插件明确写出来，例如 mysql_native_password；GROUP BY 不再像旧版本那样默认返回排序结果，如果需要有序数据，就必须显式补充 ORDER BY；此外，NO_AUTO_CREATE_USER 这类 sql_mode 选项，在 MySQL 8.0 中也已经被彻底移除。
MySQL 8.0 和 5.7 的 SQL 语法差异并不是简单的小改动，而是存在几处**必须改写后才能正常运行**的关键断裂点。很多人在升级 MySQL 版本后，第一条 GRANT 就报错，或者发现 GROUP BY 查询结果顺序混乱、CREATE USER 执行完成却依然无法连接——这些通常不是配置问题，而是 MySQL 8.0 的语法规则和解析行为已经发生了变化。
GRANT 语句中不能再使用 IDENTIFIED BY
这是 MySQL 5.7 升级到 MySQL 8.0 时最常见的兼容性问题之一。MySQL 8.0 已经彻底移除了 GRANT 中的 IDENTIFIED BY 语法，即使目标用户不存在，也不允许再通过“创建用户并同时授权”的方式一步完成。
- 5.7 可正常执行：
GRANT SELECT ON app.* TO 'api'@'%' IDENTIFIED BY 'p123'; - 8.0 会直接报错：
ERROR 1064 (42000): You ha ve an error in your SQL syntax [...] near 'IDENTIFIED BY' - 正确处理方式是拆成两步：
CREATE USER 'api'@'%' IDENTIFIED WITH mysql_native_password BY 'p123';→GRANT SELECT ON app.* TO 'api'@'%'; - 为了兼容不同版本，常见写法是使用
CREATE USER IF NOT EXISTS开头，5.7 会忽略IF NOT EXISTS且不会报错，8.0 中则会真正生效
CREATE USER 需要显式指定认证插件
从 MySQL 8.0 开始，默认认证插件变成了 caching_sha2_password。但像 PyMySQL ≤0.9、旧版 Na vicat、PHP mysqli、JDBC 5.x 等较老的客户端，往往并不支持这个插件。一旦尝试连接，就很容易出现 Authentication plugin 'caching_sha2_password' cannot be loaded 之类的报错。
- 错误示例：只写
CREATE USER 'u'@'%' IDENTIFIED BY 'p';—— 用户虽然创建成功，但旧客户端可能无法连接 - 正确示例：显式指定插件：
CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p'; IDENTIFIED WITH和IDENTIFIED BY需要同时出现，而且顺序不能写反；WITH后面是认证插件名称，BY后面才是密码- 如果是修改已有用户的认证方式，可使用：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p';（注意：如果只写ALTER USER ... IDENTIFIED BY，可能会在无提示的情况下把插件重置为caching_sha2_password）
GROUP BY 不再隐式排序，必须手动加 ORDER BY
在 MySQL 5.7 中，像 SELECT a, COUNT(*) FROM t GROUP BY a 这类语句，结果通常会默认按照 a 排序；而在 MySQL 8.0 中，这种隐式排序行为已经被移除，查询结果顺序不再可靠，除非显式写出 ORDER BY。
- 如果业务逻辑依赖分组后的顺序，必须补充：
SELECT a, COUNT(*) FROM t GROUP BY a ORDER BY a; - 不要仅凭测试环境数据判断查询顺序是否稳定——MySQL 8.0 优化器可能因为统计信息变化而调整执行计划，同一条 SQL 在不同时间都可能返回不同顺序
- 升级前还应检查：
SELECT @@sql_mode;是否包含ONLY_FULL_GROUP_BY，因为它会让不合法的GROUP BY写法（例如SELECT a, b FROM t GROUP BY a）直接报错
sql_mode 里的 NO_AUTO_CREATE_USER 已经被删除
这个选项在 MySQL 8.0 中已经完全移除，不是简单废弃，而是彻底删除。如果你的备份恢复脚本、初始化 SQL 或配置文件里仍然保留了它，那么 MySQL 8.0 在启动或执行时就可能直接失败。
- 常见报错：
Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' - MySQL 8.0 默认的
sql_mode包含STRICT_ALL_TABLES（相比 5.7 常见的STRICT_TRANS_TABLES更严格），同时已经不再支持NO_AUTO_CREATE_USER - 因此在数据库迁移、版本升级时，必须清理所有包含该选项的配置文件、dump 文件以及初始化脚本
- 其他已被移除的项目还包括：
DB2、MSSQL、ORACLE等兼容模拟模式，以及NO_FIELD_OPTIONS等会影响SHOW CREATE TABLE输出结果的选项
最容易被忽视的，其实是 ALTER USER ... IDENTIFIED BY 这种表面上看起来很安全的操作——它在 MySQL 8.0 中可能会静默覆盖认证插件，导致原本可以正常连接的账户突然无法登录。也就是说，MySQL 8.0 与 MySQL 5.7 的语法差异，并不都是直接报错，有些变化更危险，因为它们会悄悄改变关键行为。
