每个人都可以，
拥有SSL证书

项目在往达梦数据库迁的时候，SQL 改写量最大的部分基本都集中在日期和空值处理上。

MySQL 里用惯了的几个函数，到达梦这边得换一种写法，还有一些参数如果不提前调好，线上跑起来直接报非法日期类型，排查起来挺折磨人的。

下面把遇到过的几个典型转换和问题捋一下。

日期格式化

MySQL 里格式化日期用 DATE_FORMAT，达梦用 TO_CHAR，格式化字符串的风格也完全不一样。

之前写 MySQL 是这样：

SELECT DATE_FORMAT(start_time, '%Y-%m-%d') AS start_time FROM your_table;

到达梦要改成：

SELECT TO_CHAR(start_time, 'YYYY-MM-DD') AS start_time FROM your_table;

大小写敏感，分隔符原样跟上就行。这个转换还算直接，批量替换就能搞定。

当前时间

MySQL 里拿当前时间直接 NOW()，达梦用 SYSDATE。

-- MySQL
SELECT NOW() AS current_time;

-- 达梦
SELECT SYSDATE AS current_time;

注意 SYSDATE 返回的是服务器当前的日期时间，跟 MySQL 的 NOW() 行为一致，不用多折腾。

空值处理

IFNULL 在 MySQL 里用来兜底空值，达梦对应的函数是 NVL，参数顺序一样，第一个是可能为空的字段，第二个是替代值。

-- MySQL
SELECT IFNULL(commission_pct, 0) AS commission_pct FROM employees;

-- 达梦
SELECT NVL(commission_pct, 0) AS commission_pct FROM employees;

如果代码里用了 IFNULL，全局搜索替换成 NVL 就行，基本不会出幺蛾子。

日期常量与 to_date 报错

这个地方坑比较多。

MySQL 里有种写法 DATE(0) 会生成一个 “0000-00-00” 的日期，在某些历史表里会见到。

到达梦这边，直接写 DATE '0000-00-00' 去查，大概率会碰到 “非法的时间日期类型数据” 这种报错。一开始我还以为是达梦根本不认全零日期，后来发现跟一个参数有关。

达梦有个参数叫 DATETIME_FAST_RESTRICT，默认值一般是 1，这个参数控制对日期字符串的严格程度。

当它设为 1 的时候，类似 DATE '0000-00-00' 或者带时间的字符串转日期时，就容易触发校验失败。解决办法是把它改成 0，允许更宽松的解析。

改完参数之后，DATE '0000-00-00' 就能正常使用了。同样的问题也会出现在 TO_DATE 函数上。

比如在没调参数之前，执行：

SELECT TO_DATE('2022-01-11 11:22:33', 'YYYY-MM-DD HH24:MI:SS') FROM DUAL;

直接报 “非法的时间日期类型数据”。

其实就是因为参数限制了，不让日期字符串里带时间部分。把 DATETIME_FAST_RESTRICT 调成 0 之后再跑，就过了。

改参数的方法：

sp_set_para_value(1, 'DATETIME_FAST_RESTRICT', 0);

这个设置是对整个库生效的，改之前跟 DBA 确认一下影响范围。我们当时在测试环境先调了一轮，确认没引起别的问题才上的生产。

回过头看，迁移过程中只要把日期格式化、当前时间、空值处理这几个函数改写到位，再把日期相关的参数提前调好，大部分常见报错就能避过去。

真正折腾人的倒不是改写本身，而是那些静默不报错但结果不一致的 SQL，那个就得靠大量比对数据去查了。