必须重写视图，因SQL引擎间语法、函数、语义不兼容：MySQL不支持FROM子查询，PostgreSQL无ISNULL/GETDATE函数，Oracle的ROWNUM不可移植，需人工转换语法与函数。
不能直接迁移，必须重写。SQL 视图不是“一次编写、到处运行”的组件，它的可移植性取决于底层 SQL 引擎对语法、函数、类型和执行语义的支持程度。
PostgreSQL 视图在 MySQL 中报 ERROR 1349 怎么办
这是最典型的迁移失败信号，错误信息 ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause 暴露了 MySQL 对视图定义的“可展平性”限制——它不允许视图主体中出现子查询作为表源。
- PostgreSQL 允许
SELECT * FROM (SELECT id, name FROM users) AS t这类嵌套，MySQL（尤其 5.7 和早期 8.0）会直接拒绝 - MySQL 8.0+ 虽支持 CTE，但要求显式写
WITH RECURSIVE，且不能依赖外部参数；而 PostgreSQL 的WITH可无条件使用 -
OFFSET+LIMIT在 PostgreSQL 视图中合法，在 MySQL 视图里虽能建，但ORDER BY会被忽略，导致结果不可控 - 解决路径：先用
pg_dump --schema-only -t view_name提取原始定义，再人工拆解——把子查询改写为JOIN，把标量子查询（如(SELECT COUNT(*) FROM logs WHERE user_id = u.id)）改为LEFT JOIN + GROUP BY
SQL Server 视图迁到 PostgreSQL 后函数全报错
常见报错如 function isnull(unknown, unknown) does not exist 或 function getdate() does not exist，本质是 T-SQL 函数在 PostgreSQL 中无对应内置实现。
-
ISNULL(a, b)→ 必须改用COALESCE(a, b)，但注意 PostgreSQL 要求所有参数类型兼容，必要时加::text或CAST() -
GETDATE()→ 替换为NOW()，若原逻辑需要无时区时间戳，得显式写NOW()::timestamp -
CONVERT(varchar, col, 120)→ 改用TO_CHAR(col, 'YYYY-MM-DD HH24:MI:SS')，模板大小写敏感，hh24写成HH24才有效 -
TOP 10→ 必须换成LIMIT 10，且必须放在整个查询末尾；若原视图含ORDER BY，必须一并保留，否则结果顺序不保证
Oracle 视图里的 ROWNUM 导致跨库结果错乱
Oracle 中常靠 WHERE ROWNUM 实现分页或取前 N 行，但该伪列是执行时动态分配的序号，在 PostgreSQL/MySQL 中没有等效机制，直接迁移会导致数据漏取或重复。
- ROWNUM 在 Oracle 中绑定执行计划阶段，不是窗口函数；而 PostgreSQL 的
ROW_NUMBER() OVER ()是标准窗口函数，行为不同 - 若原视图用 ROWNUM 做“取最新 10 条”，应重写为
ORDER BY created_at DESC LIMIT 10（PostgreSQL/MySQL）或FETCH FIRST 10 ROWS ONLY（标准 SQL） - 更隐蔽的问题：Oracle 视图若嵌套
ROWNUM+ORDER BY，实际执行顺序可能与预期不符；其他数据库不会复现这种“隐式排序优先级” - 检查是否用了
SYSDATE、REGEXP_LIKE()等 Oracle 特有函数——这些在目标库要么不存在，要么语法不兼容（如 PostgreSQL 用~，MySQL 用REGEXP）
真正难处理的从来不是语法替换，而是那些藏在视图背后的隐式行为：时区偏移、空值比较逻辑（ANSI_NULLS 开关）、字符串截断规则、甚至优化器对 COUNT(*) 的物化策略。这些不会报错，但会让结果在上线后悄悄漂移。
