postgresql视图不支持select列表中的标量子查询，必须改写为left join聚合子查询或cte；函数如getdate()、isnull()需分别替换为now()和coalesce()并注意类型一致。
MySQL 视图迁移到 PostgreSQL 时标量子查询报错
MySQL 允许视图里写 (SELECT COUNT(*) FROM logs WHERE user_id = u.id) 这类标量子查询，PostgreSQL 直接拒绝，报 ERROR: subquery in SELECT clause not allowed in view。这不是语法拼写问题，而是 PostgreSQL 对视图定义更严格——它要求所有子查询必须显式关联（即 JOIN），不能“悬空”在 SELECT 列表里。
实操建议：
- 把标量子查询改写为
LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM logs GROUP BY user_id) l ON l.user_id = u.id - 如果聚合逻辑复杂（比如带 WHERE 或 DISTINCT），先建物化临时表或 CTE，再 JOIN；PostgreSQL 8.0+ 支持 WITH 子句，但 CTE 必须放在 CREATE VIEW 语句最前面
- 别依赖 MySQL 的“隐式类型转换”：PostgreSQL 中
COALESCE(int_col, 'N/A')会失败，必须显式写成COALESCE(int_col::TEXT, 'N/A')
SQL Server 视图含 GETDATE() 或 ISNULL()，在 MySQL/PostgreSQL 中执行失败
错误信息通常是 function getdate() does not exist 或 function isnull(unknown, unknown) does not exist。这些是 T-SQL 特有函数，目标库压根没注册，不是大小写或括号问题。
实操建议：
-
GETDATE()→ MySQL 用NOW()，PostgreSQL 也用NOW()（但返回timestamptz，如需无时区时间，加::timestamp） -
ISNULL(a, b)→ 统一替换为COALESCE(a, b)，但注意所有参数类型必须一致；若 a 是INT、b 是字符串，得补类型转换：COALESCE(a::TEXT, b) -
CONVERT(VARCHAR, col, 120)→ MySQL 用DATE_FORMAT(col, '%Y-%m-%d %H:%i:%s')，PostgreSQL 用TO_CHAR(col, 'YYYY-MM-DD HH24:MI:SS')，模板大小写敏感，不能写小写hh24
Oracle ROWNUM 在 MySQL/PostgreSQL 视图中导致结果错乱
Oracle 常用 WHERE ROWNUM 实现分页，但直接迁移到 MySQL/PostgreSQL 会出错：MySQL 视图里允许 <code>LIMIT，但 Oracle 的 ROWNUM 是执行时动态分配的序号，没有 ORDER BY 时语义不保；PostgreSQL 根本不识别 ROWNUM。
实操建议：
- Oracle 的
SELECT * FROM t WHERE ROWNUM → MySQL 改成 <code>SELECT * FROM t LIMIT 10，但必须确认原逻辑是否隐含排序；若 Oracle 原句没ORDER BY，迁移后结果不可靠，应补上 - Oracle 的
SELECT * FROM (SELECT ..., ROWNUM rn FROM t ORDER BY x) WHERE rn BETWEEN 11 AND 20→ PostgreSQL/MySQL 都得改用窗口函数：ROW_NUMBER() OVER (ORDER BY x) AS rn，再套一层WHERE rn BETWEEN 11 AND 20 - MySQL 5.7 不支持窗口函数，只能用变量模拟（
@rn := @rn + 1），但变量在视图中不可靠，建议升级到 8.0+ 或改用应用层分页
跨库引用（如 other_db.users）在目标库执行时报 ERROR 1356
源视图定义里写了三段式名称 SELECT * FROM prod.users，目标库没有 prod 库，或者同名表结构已变，执行时不会在 CREATE 阶段报错，而是在首次 SELECT 时抛 ERROR 1356 (HY000): View 'db.v' references invalid table(s) or column(s)。
实操建议：
- 迁移前必须用
SHOW CREATE VIEW your_view拿完整语句，不能只查information_schema.VIEWS.VIEW_DEFINITION—— 后者丢掉算法、字符集、SQL SECURITY 等关键上下文 - 所有库名必须显式重写：把
prod.users改成目标库实际库名，如staging.users；如果目标库不允许跨库访问，就得提前把依赖表同步过去 - 检查
SQL SECURITY DEFINER用户是否存在于目标库；若不存在，要么创建该用户，要么改成SQL SECURITY INVOKER，否则视图创建成功但只有 DEFINER 能查
视图迁移最难的不是语法改写，而是那些创建成功却查不出数据的隐形坑：权限缺失、字符集不匹配、DEFINER 用户不存在、跨库路径失效——它们都不报在 CREATE 阶段，而是在业务第一次调用时才暴露。
