标准sql语句不能直接跨数据库执行，因各库在语法、函数、类型、权限上差异显著；仅ansi sql-92最小交集部分兼容，需规避方言特性，如禁用引号表名、专属函数、隐式转换及非标准分页。
标准 SQL 语句本身不能直接跨数据库执行——不同数据库对语法、函数、类型、权限的实现差异太大，所谓“标准”只在最基础的 SELECT / WHERE / JOIN 层面勉强通用。
为什么 SELECT * FROM users WHERE created_at > '2024-01-01' 在 MySQL 和 PostgreSQL 中可能失败
表面看是同一句话，但实际运行时容易卡在几个隐性环节：
-
created_at字段类型可能是DATETIME（MySQL）、TIMESTAMP WITH TIME ZONE（PostgreSQL）或DATE（SQL Server），字符串字面量格式稍有偏差就会报错，比如 PostgreSQL 对时区敏感，'2024-01-01'默认被解释为UTC时间 - MySQL 默认允许隐式类型转换（如把字符串当日期用），PostgreSQL 则严格要求显式
::timestamp或TO_TIMESTAMP() - SQL Server 的默认日期格式受
DATEFORMAT设置影响，'2024-01-01'可能被当成MM-DD-YYYY
哪些 SQL 片段真正具备跨库兼容性
仅限 ANSI SQL-92 最小交集部分，且需主动规避方言特性：
- 表名、字段名不用双引号或反引号：
users✅，"users"❌（PostgreSQL 强制小写，MySQL 默认忽略大小写但引号会锁死大小写） - 避免所有数据库专属函数：
NOW()（MySQL）、CURRENT_TIMESTAMP（PostgreSQL/SQL Server）、GETDATE()（SQL Server）全部不用；统一用CURRENT_DATE或参数化传入时间值 -
JOIN只用显式INNER JOIN/LEFT JOIN，不写逗号连接；ON条件里不出现函数，比如ON u.id = o.user_id✅，ON YEAR(u.created_at) = 2024❌ - 排序用
ORDER BY 1, 2（按列序号）比ORDER BY created_at DESC更稳妥，尤其当字段别名含空格或关键字时
实际查业务数据时，必须手动适配的三类地方
哪怕你写的是“标准 SQL”，只要连真实库，就得检查这三项：
-
字符串匹配：MySQL 默认不区分大小写，PostgreSQL 默认区分；要用
ILIKE（PostgreSQL）或COLLATE utf8mb4_0900_as_cs（MySQL 8.0+）统一行为，或者干脆用LOWER(name) = LOWER(?) -
分页写法：
LIMIT 10 OFFSET 20（MySQL/PostgreSQL）不被 SQL Server 支持，得改用OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY；Oracle 12c+ 也支持后者，但旧版只能靠ROWNUM嵌套 -
空值处理：
COALESCE(status, 'unknown')是安全的，但IFNULL()（MySQL）、ISNULL()（SQL Server）必须换掉；注意 PostgreSQL 中COALESCE对text和varchar混用可能触发隐式转换警告
真正跨库查询不是靠写“标准 SQL”，而是靠明确目标库、提前做方言映射、把动态部分抽成配置——比如分页参数、日期格式、空值默认值，全交给 DAO 层或查询构建器（如 jOOQ、MyBatis 的 <bind></bind>）处理。手写 SQL 时，先想清楚你到底连的是哪个库，再决定写哪一版。
