MySQL 8.4 中已移除 OLD_PASSWORD() 和 ENCODE()/DECODE() 函数，调用或配置引用会导致报错或初始化失败；JSON_EXTRACT/UNQUOTE、GROUP_CONCAT、NTILE() 等函数行为变更，且 WINDOW 子句命名、CTE 递归深度等兼容性细节亦有调整。
JSON_TABLE 在 8.0.22 引入，但 8.4 中行为更稳定；REGEXP_LIKE、REGEXP_SUBSTR 等正则函数在 8.0.4 和 8.4 中都可用，但 8.4 默认启用 PCRE2 引擎，匹配行为略有差异；JSON_SCHEMA_VALID 从 8.0.17 开始支持，8.4 中修复了部分 schema 校验的边界 case。这些不是“新增函数”，而是同一函数在不同版本中语义、默认行为或稳定性上的实际差别。
哪些函数在 8.4 中被移除或废弃？
MySQL 8.4 没有大规模移除内置函数，但有两个关键变化必须注意：
-
OLD_PASSWORD()：早在 8.0.11 就已标记为废弃，8.4 中彻底不可用，调用会报错ERROR 1305 (42000): FUNCTION OLD_PASSWORD does not exist -
ENCODE()/DECODE()：这两个基于弱加密的函数在 8.0.30 被弃用，8.4 启动时若配置中仍引用它们（比如在视图定义或存储过程里），会导致初始化失败或查询报错
特别注意：ENCODE() 的替代方案不是 AES_ENCRYPT()，而是应改用 TO_BASE64() + 应用层加盐哈希，因为 ENCODE() 无密钥、可逆且不安全。
哪些函数在 8.4 中行为变更？
最常踩坑的是 JSON_EXTRACT 和 JSON_UNQUOTE 的组合处理空值与 null 字符串：
- 在 8.0.46 中：
JSON_EXTRACT('{"a": null}', '$.a')返回NULL，而JSON_UNQUOTE(JSON_EXTRACT('{"a": "null"}', '$.a'))返回字符串"null"（带引号） - 在 8.4.9 中：
JSON_UNQUOTE对NULL输入返回NULL，但对字符串"null"仍返回"null"—— 表面一致，但底层 JSON 解析器升级后，某些嵌套路径表达式（如$[0].x）在数组越界时不再静默返回NULL，而是抛出 warning 并影响STRICT_TRANS_TABLES模式下的插入行为
另一个易忽略点：GROUP_CONCAT 的默认分隔符在 8.4 中仍是逗号，但当 group_concat_max_len 被设为 0（表示不限制）时，8.4 实际按 max_allowed_packet 截断，而 8.0 可能截断更早 —— 这会导致导出 JSON 数组时意外截断。
窗口函数和 CTE 在 8.4 中有哪些兼容性细节？
8.0 引入窗口函数（ROW_NUMBER()、RANK()、LAG() 等）和 CTE（WITH），8.4 并未新增语法，但优化了执行计划选择：
-
WINDOW子句命名在 8.4 中支持重复引用，而 8.0.34 前要求每个命名 window 必须唯一；若旧 SQL 里写了两个同名WINDOW w AS (ORDER BY x)，8.0 会报错，8.4 允许（但不推荐） -
RECURSIVE CTE的最大递归深度默认值从 8.0 的 1000 改为 8.4 的 500，超限直接报错ERROR 3636 (HY000): Recursive query aborted after 500 iterations，不能靠SET SESSION cte_max_recursion_depth = 1000动态提升（该变量在 8.4 中已移除） -
NTILE()在 8.0 中对空结果集返回空，8.4 中明确返回NULL—— 如果业务代码用IFNULL(NTILE(4) OVER(...), 0)，在 8.4 下可能逻辑偏移
函数调用时容易被忽略的权限与上下文限制
8.4 加强了函数执行的上下文校验，尤其涉及系统信息或敏感操作：
-
USER()和CURRENT_USER()在 DEFINER 为root@localhost的存储过程中，8.4 默认返回定义者身份，但若过程内调用SYS_SCHEMA相关函数（如ps_helper工具包里的format_bytes()），需显式授予SELECT权限到performance_schema，否则报错ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_VARIABLES_ADMIN privilege(s) for this operation -
VALIDATE_PASSWORD_STRENGTH()在 8.4 中要求用户必须有SELECT权限才能访问mysql.password_history表，否则返回NULL而非报错 —— 这会让密码强度检查逻辑静默失效 - 所有返回 JSON 的函数（
JSON_OBJECT()、JSON_ARRAY()）在 8.4 中对 key 名称强制去重：如果写JSON_OBJECT('id', 1, 'id', 2)，8.4 返回{"id": 2}，而 8.0 返回{"id": 1, "id": 2}（非法 JSON，但 parser 未严格拦截）
真正麻烦的不是函数有没有，而是你写的 SQL 在 8.0 跑得好好的，在 8.4 里要么结果不对，要么权限不够就静默失败 —— 特别是那些依赖隐式类型转换、空值处理或权限宽松的老脚本。
