Oracle中无GROUP_CONCAT等价函数，最接近的是LISTAGG，但需显式ORDER BY、默认4000字节限制且超长报错；STATS_MODE在MySQL需窗口函数模拟；JSON_OBJECTAGG在Oracle应改用JSON_ARRAYAGG(JSON_OBJECT(KEY...))。
MySQL的GROUP_CONCAT在Oracle里没有直接等价函数
Oracle不支持GROUP_CONCAT，最接近的是LISTAGG，但行为差异明显：它要求显式指定排序（否则报错ORA-01489: result of string concatenation is too long），且默认长度限制为4000字节（超出会直接报错，而非截断）。MySQL的GROUP_CONCAT默认按插入顺序拼接，长度上限由group_concat_max_len系统变量控制，超长时静默截断。
迁移时需注意：
-
LISTAGG(col, ',') WITHIN GROUP (ORDER BY col)是基本写法，ORDER BY不可省略 - 若原MySQL语句未指定排序，需确认业务是否真不依赖顺序；否则Oracle必须补上合理排序字段（如
id或时间戳） - 超过4000字节要加
ON OVERFLOW TRUNCATE（12cR2+）或改用XMLAGG+XMLELEMENT兜底 - MySQL中
GROUP_CONCAT(DISTINCT col)对应Oracle需用子查询去重：LISTAGG(col, ',') WITHIN GROUP (ORDER BY col)套在SELECT DISTINCT结果上
Oracle的STATS_MODE在MySQL里得手写模拟
MySQL 8.0+ 仍未原生支持众数（mode）聚合，而Oracle的STATS_MODE(col)可直接返回出现频次最高的值（有多个时返回任意一个）。迁移时不能简单删掉——除非确认该字段无重复值或业务已弃用该统计。
可行替代方案：
- 用窗口函数模拟（MySQL 8.0+）：
SELECT col FROM (<br> SELECT col, COUNT(*) c, RANK() OVER (ORDER BY COUNT(*) DESC) r<br> FROM t GROUP BY col<br>) t2 WHERE r = 1 LIMIT 1
- 低版本MySQL只能靠子查询+
ORDER BY COUNT(*) DESC LIMIT 1，但要注意NULL值参与计数、多众数时结果不确定 - 若表很大，这种写法性能较差，建议提前建好
(col)索引
COUNT(DISTINCT ...)在Oracle和MySQL的NULL处理一致，但执行计划差异大
两者都正确忽略NULL值，语法完全兼容，看似可直译。但实际迁移后可能突然变慢——尤其当DISTINCT字段基数高、无索引时。
原因在于：
- MySQL通常用临时表+文件排序实现
COUNT(DISTINCT)，内存不足时落盘，IO压力大 - Oracle在12c+默认启用
APPROX_COUNT_DISTINCT优化（近似计算），精度误差但快10倍以上；而MySQL无此选项 - Oracle对
COUNT(DISTINCT col)能更好利用位图索引（如果存在），MySQL则基本无法受益
若迁移后查询变慢，优先检查执行计划中是否出现Using temporary; Using filesort（MySQL）或SORT GROUP BY（Oracle），再针对性加索引或改写。
MySQL的JSON_OBJECTAGG和Oracle的JSON_OBJECT不完全对等
MySQL 5.7+ 的JSON_OBJECTAGG(key, value)会自动把结果聚合成单个JSON对象，key重复时后值覆盖前值；Oracle 12cR2+ 的JSON_OBJECT(KEY key VALUE value)是行级函数，要配合JSON_ARRAYAGG才能模拟聚合效果。
常见翻车点：
- Oracle写成
JSON_OBJECTAGG会报错——根本不存在这个函数名 - 正确写法是：
JSON_ARRAYAGG(JSON_OBJECT(KEY 'k' VALUE v))，再用JSON_OBJECT外层包裹需额外解析逻辑 - MySQL允许
JSON_OBJECTAGG(NULL, value)（key为NULL时跳过），Oracle的JSON_OBJECT(KEY NULL VALUE ...)直接报错 - 字符集处理不同：MySQL默认UTF8MB4，Oracle依赖数据库字符集，若含emoji易出现乱码
LISTAGG截断策略、MySQL缺乏STATS_MODE、以及JSON聚合函数命名和语义的错位，是迁移时最容易被当成“语法相似”而忽略的硬伤。别只盯着函数名能不能替换，得看它在真实数据规模下会不会崩、返回结果是否真的等价。 
