企业官网建设流程全解析

1. 项目概述：为什么国产数据库迁移不能只靠“改驱动”

最近三个月，我接手了三个 Oracle 迁移至达梦（DM）的落地项目，客户清一色是省级政务系统、金融监管平台和央企ERP模块。他们最初的想法都很朴素：“换掉 JDBC 驱动，把 url 改成 dm.jdbc.driver.DmDriver，不就完事了？”结果上线前一周，SQL 报错率飙升到 37%，核心报表跑不出数据，分页查询直接超时，连最基础的TO_DATE('2024-01-01', 'YYYY-MM-DD')都提示“函数不存在”。这才意识到：Oracle 到达梦不是换轮胎，而是把燃油车整个拆解、重铸底盘、重写电控逻辑，再装上国产电机——表面都是“数据库”，内核已是两套语言体系。

这就是“Trae + SQLazy 实践 SQL 国产化移植：Oracle => 达梦”这个标题背后的真实战场。Trae 不是某个神秘工具，而是我们团队自研的一套轻量级 SQL 语义分析与上下文感知引擎（注意：不是开源项目 Trae CLI，也不是某款 IDE 插件，下文会详解其定位）；SQLazy 是配套的规则驱动型 SQL 重写框架，专为结构化语法迁移设计。它不碰应用代码，不改 Java 层 ORM 映射，只在 SQL 执行前做“外科手术式”精准变形——比如把ROWNUM <= 10拆成达梦支持的LIMIT 10+ 子查询包裹，把NVL(col, 'default')替换为CASE WHEN col IS NULL THEN 'default' ELSE col END，同时保留原 SQL 的执行计划意图和字段别名层级。

关键词里反复出现的“navicat 连接达梦”“达梦数据库安装”“oracle 分页”“oracle 过滤不可转为数字的字符串”，恰恰暴露了当前迁移中最痛的三类断层：第一是开发人员停留在“能连上就行”的初级阶段，第二是 DBA 习惯用 Oracle 思维调优达梦（比如盲目加大 shared_pool_size），第三是测试团队拿 Oracle 的 SQL 脚本直接跑到达梦上，报错就截图发群里问“这个函数达梦有没有对应版本”。而 Trae+SQLazy 的价值，就是在这三类断层之间架一座可审计、可回滚、可灰度的桥——它不承诺 100% 自动化，但能把人工校验成本从人均 80 小时压到 8 小时以内，且每一条改写都附带原始 SQL、目标 SQL、改写依据（如《达梦 V8 兼容性手册》第 4.2.7 条）、影响范围（是否涉及索引字段、是否改变执行顺序）四维元数据。

适合谁参考？如果你正面临以下任一场景，这篇就是为你写的：

• 你刚接到任务，要在一个季度内完成 200+ 张表、500+ 存储过程、3000+ 条业务 SQL 的 Oracle→达梦迁移，但团队里没人完整用过达梦；
• 你试过用 Navicat 的“SQL 转换器”或某些商业工具，结果生成的 SQL 在达梦里跑出数据偏差，却查不出哪条改写出了问题；
• 你发现 MyBatis 的<if test="xxx">动态 SQL 在达梦里因空字符串处理逻辑不同而漏查数据，但又不敢动业务代码；
• 你被要求“必须保留 Oracle 的分页写法”，但达梦不支持ROWNUM嵌套，领导说“你们技术团队自己想办法”。
  接下来的内容，全部来自这三套真实系统的迁移日志、SQL 重写记录、性能对比报告和踩坑笔记——没有理论推演，只有哪条规则在哪张表上生效、哪个函数替换导致索引失效、哪次灰度发布因字符集配置漏项引发乱码的实录。

2. 整体设计思路：为什么放弃“全量语法树解析”，选择“模式匹配+上下文锚点”

很多团队一上来就想搞“高大上”的方案：用 ANTLR 写 Oracle 和达梦的完整语法解析器，构建 AST（抽象语法树），再做节点映射转换。我带队试过两次，第一次花了 6 周写出基础解析器，结果发现 Oracle 的MODEL子句、PIVOT/UNPIVOT、复杂WITH递归嵌套等高级特性，在达梦 V8.1 中根本未实现，强行映射只会生成语法正确但语义错误的 SQL；第二次引入规则引擎 Drools，定义了 200+ 条转换规则，但实际运行时发现：同一条SELECT * FROM t WHERE col = NVL(?, 'a')，在 MyBatis 的<bind>标签里、在存储过程中、在触发器里，?的绑定时机和空值处理逻辑完全不同，Drools 规则无法感知这种上下文差异，导致NVL被错误替换成COALESCE后，达梦对COALESCE(NULL, '')返回空字符串，而 Oracle 返回NULL，最终业务判断col IS NULL失效。

于是我们彻底转向“轻量级、可解释、强可控”的设计哲学：Trae 不解析整条 SQL，只识别关键模式；SQLazy 不生成新 SQL，只做最小粒度的文本置换，并强制要求每处置换都携带上下文锚点。具体怎么操作？举个典型例子：

Oracle 原始 SQL：

SELECT id, name, TO_CHAR(create_time, 'YYYY-MM-DD HH24:MI:SS') AS fmt_time FROM user_log WHERE TO_DATE(create_date, 'YYYYMMDD') > SYSDATE - 7;

传统方案会试图解析TO_CHAR函数节点，找到参数类型，再映射到达梦的TO_CHAR（达梦确实有，但日期格式符不兼容）。而 Trae+SQLazy 的做法是：

1. Trae 扫描 SQL 文本，用正则锚定TO_CHAR\(([^)]+),\s*'([^']+)'\)模式，提取出create_time和'YYYY-MM-DD HH24:MI:SS'；
2. 同时检查该TO_CHAR是否出现在SELECT列表（而非WHERE子句），因为达梦对SELECT中的TO_CHAR格式符支持更全；
3. SQLazy 查规则库，发现达梦 V8.1 对'YYYY-MM-DD HH24:MI:SS'的支持需转换为'YYYY-MM-DD HH24:MI:SS'（表面一样，但达梦要求单引号内不能有空格？错，其实是达梦的TO_CHAR默认将HH24解析为HH，必须显式加FM修饰符）；
4. 最终输出：TO_CHAR(create_time, 'FMYYYY-MM-DD HH24:MI:SS')，并记录锚点：[位置: 第1行第25列, 上下文: SELECT 列表, 规则ID: DM-DATE-FORMAT-003]。

这个设计带来三个硬性优势：

• 可审计性：每条改写都能追溯到原始位置、上下文环境、规则依据，测试时发现数据偏差，直接按锚点定位到具体 SQL 片段，5 分钟内复现问题；
• 可灰度性：SQLazy 支持按 schema、table、甚至 SQL 注释中的/* TRAE:ENABLE */标签控制开关，上线初期只对user_log表启用TO_CHAR规则，其他表保持原 SQL 直通；
• 可扩展性：新增一条规则只需写一个正则模板、一个上下文判断函数、一个置换逻辑，平均 15 分钟就能上线，而 AST 方案每次新增函数支持都要重构解析器。

有人问：为什么不直接用达梦官方的迁移工具？我们对比过达梦 DTS 工具，它擅长表结构、数据迁移，但对 SQL 逻辑迁移束手无策——它会把ROWNUM直接删掉，或者把DECODE粗暴替换成CASE WHEN却不处理NULL与空字符串的语义差异。而 Trae+SQLazy 的核心价值，恰恰在于守住“SQL 语义不变”这条底线：改写后的 SQL 在达梦上执行，返回结果集的行数、字段值、NULL 性、排序稳定性，必须与 Oracle 原始 SQL 严格一致。这需要的不是语法转换能力，而是对两个数据库执行引擎底层行为的深度理解——比如 Oracle 的NVL在遇到VARCHAR2类型时会隐式转换，而达梦的COALESCE严格按参数类型判空，这就决定了NVL(col, 'a')在col为CHAR(10)时，Oracle 返回'a '（带空格），达梦返回'a'（无空格），必须加RPAD补齐。

3. 核心细节解析：Oracle 与达梦在 SQL 层的 7 类关键差异及 Trae+SQLazy 应对策略

3.1 分页机制：从 ROWNUM 套娃到 LIMIT/TOP 的语义鸿沟

Oracle 的ROWNUM是“先取结果再编号”，所以WHERE ROWNUM <= 10能取前 10 行，但WHERE ROWNUM > 10永远为空（因为第一行 ROWNUM 就是 1，不满足 >10，后续行根本不会生成）。达梦不支持ROWNUM，但支持标准LIMIT offset, count和TOP n。问题来了：SELECT * FROM t ORDER BY id WHERE ROWNUM BETWEEN 11 AND 20这种经典 Oracle 分页，如果简单替换成SELECT * FROM t ORDER BY id LIMIT 10 OFFSET 10，在达梦上能跑，但语义是否一致？

我们做了 1000 次随机数据测试：当t表有重复id值时，Oracle 的ROWNUM分页会因ORDER BY稳定性不足，导致同一页数据在多次查询中顺序漂移；而达梦的LIMIT/OFFSET依赖ORDER BY字段的唯一性，若id不唯一，同样会漂移。但 Trae+SQLazy 的应对不是“修语法”，而是“补语义”：它检测到ROWNUM BETWEEN模式时，会强制在ORDER BY后追加主键字段（如ORDER BY id, pk_id），确保排序唯一性，并生成带LIMIT/OFFSET的 SQL，同时在日志中标记“已注入稳定性补丁”。这比单纯语法转换多了一层业务语义保障。

3.2 空值与空字符串处理：Oracle 的“空即空” vs 达梦的“空即零长度”

Oracle 中''和NULL完全等价，NVL(col, 'default')对空字符串也生效；达梦中''是非 NULL 的零长度字符串，COALESCE(col, 'default')只对NULL生效。这导致 MyBatis 的<if test="name != null">在 Oracle 下能过滤空字符串，在达梦下却放过''。Trae+SQLazy 的策略是双轨制：

• 对 SQL 层：将NVL(col, 'd')替换为CASE WHEN col IS NULL OR col = '' THEN 'd' ELSE col END，覆盖两种空值；
• 对应用层：生成迁移报告，标出所有可能受此影响的 MyBatis XML 文件路径，建议开发在test属性中加AND name != ''。

我们曾在一个用户管理模块栽跟头：Oracle 下SELECT * FROM user WHERE status = NVL(?, 'A')，传入''时查出所有status='A'的用户；达梦下COALESCE不触发，查出空结果集。Trae 在扫描时发现?绑定的是字符串类型，且出现在NVL第二参数，立即触发“空字符串敏感”规则，生成带OR col = ''的 CASE 语句，并在报告中高亮该 SQL 的业务含义——这是唯一一次我们主动要求开发改 Java 代码，因为 SQL 层无法 100% 模拟 Oracle 的空值哲学。

3.3 字符串函数兼容性：SUBSTR、INSTR、REPLACE 的参数陷阱

Oracle 的SUBSTR(str, start, length)中start为负数时从末尾计数（SUBSTR('abc', -1)返回'c'），达梦的SUBSTR不支持负数起始位；Oracle 的INSTR(str, substr, start, occurrence)支持第四个参数找第几次出现，达梦只支持前三个。Trae 的处理不是“找替代函数”，而是“降级保功能”：

• 检测SUBSTR(col, -n)时，用SUBSTR(col, LENGTH(col) + 1 - n)替代，虽然多一次LENGTH计算，但语义完全一致；
• 检测INSTR(col, 'x', 1, 2)时，拆成INSTR(INSTR(col, 'x') + 1, col, 'x')的嵌套调用，牺牲一点性能，换取逻辑正确。

这些替换看似笨拙，却是经过压测验证的：在千万级用户表上，SUBSTR(name, -3)改写后 QPS 仅下降 1.2%，而直接报错导致服务熔断的代价是 100% 不可用。

3.4 日期时间函数：SYSDATE、TO_DATE、ADD_MONTHS 的精度战争

Oracle 的SYSDATE包含秒和毫秒，达梦的SYSDATE默认只到秒；Oracle 的TO_DATE('2024-01-01', 'YYYY-MM-DD')能接受任意分隔符，达梦要求分隔符必须与格式符严格匹配。Trae+SQLazy 的对策是“精度分级”：

• 对SYSDATE：在SELECT列表中直接替换为SYSDATE（达梦兼容），但在WHERE子句中如create_time > SYSDATE - 1，则替换为create_time > DATEADD(day, -1, SYSDATE)，避免达梦SYSDATE - 1计算精度丢失；
• 对TO_DATE：建立格式符映射表，'YYYY-MM-DD'→'YYYY-MM-DD'，'YYYY/MM/DD'→'YYYY/MM/DD'，但'YYYY.MM.DD'会被拦截并告警，要求人工确认——因为达梦不支持点号分隔符，必须改数据源或预处理。

我们曾因TO_DATE分隔符不匹配，在财务对账模块漏掉 3 天数据，Trae 的拦截告警功能成了最后一道防线。

3.5 集合操作：UNION ALL 的隐式类型转换与达梦的严格校验

Oracle 允许SELECT 1 FROM dual UNION ALL SELECT '1' FROM dual，自动将数字1转为字符串'1'；达梦要求UNION两侧字段类型严格一致，否则报错。Trae 的扫描逻辑会标记所有UNION ALL语句，并对每一对字段做类型推导：若左侧是NUMBER，右侧是VARCHAR2，则在右侧SELECT中插入TO_CHAR()包裹。但这里有个坑：TO_CHAR(1)在 Oracle 返回'1'，在达梦返回'1 '（带空格），因为达梦TO_CHAR默认右填充。解决方案是TRIM(TO_CHAR(1))，Trae 规则库已内置此修正。

3.6 正则表达式：REGEXP_LIKE 的方言割裂

Oracle 的REGEXP_LIKE(col, '\d+')支持\d，达梦的REGEXP_LIKE只支持 POSIX 字符类[0-9]。Trae 的正则扫描器会识别\d、\w、\s等 Perl 风格简写，并替换为达梦支持的等价形式。但更隐蔽的问题是：Oracle 的正则引擎默认区分大小写，达梦需显式加i标志。Trae 在替换时会检查原始正则是否含i标志，若无，则在达梦版正则末尾追加i，确保行为一致。

3.7 存储过程与 PL/SQL：从语法糖到执行模型的全面重构

这是迁移中最重的模块。Oracle 的FOR UPDATE NOWAIT、BULK COLLECT、PRAGMA AUTONOMOUS_TRANSACTION，达梦要么不支持，要么语义不同。Trae+SQLazy 不处理存储过程主体，而是生成“过程级迁移清单”：

• 标出所有FOR UPDATE NOWAIT语句，建议改用达梦的SELECT ... FOR UPDATE WAIT 0；
• 对BULK COLLECT，提供批量 INSERT/UPDATE 的达梦等效写法模板；
• 对自治事务，明确告知“达梦无此特性，需拆分为独立事务或应用层补偿”。

我们一个 ERP 的库存扣减存储过程，含 12 处BULK COLLECT，Trae 生成的清单直接给出达梦版的INSERT ALL批量语法，并附上性能对比数据：在 10 万行数据下，Oracle 原过程耗时 1.2 秒，达梦版INSERT ALL耗时 0.8 秒——因为达梦的批量插入优化更好。

4. 实操过程：从环境搭建到灰度上线的 5 个关键环节

4.1 Trae+SQLazy 环境部署：不依赖任何中间件，纯 Java Agent 注入

Trae+SQLazy 不是独立服务，而是以 Java Agent 形式注入到应用 JVM 中。这意味着：

• 无需改应用代码，不侵入业务逻辑；
• 不增加网络跳转，SQL 改写在内存中毫秒级完成；
• 可与现有监控体系（如 SkyWalking）无缝集成，改写日志自动上报。

部署步骤极简：

1. 下载trae-sqlazy-agent.jar（约 2.3MB，含所有规则库）；
2. 修改应用启动脚本，在java -jar命令后添加-javaagent:/path/to/trae-sqlazy-agent.jar=conf=/path/to/config.yml；
3. 编写config.yml，核心配置只有三项：

enable: true # 全局开关 mode: "audit" # audit（只记录不改写）/ rewrite（改写并执行）/ dry-run（模拟改写） rules: - id: "DM-ROWNUM-PAGING" enable: true schemas: ["finance", "user"] # 仅对指定 schema 生效

提示：首次上线务必设为audit模式，Trae 会将所有捕获的 SQL 及改写建议写入日志文件，供 DBA 逐条审核。我们三个项目都走了这步，平均发现 12.7% 的 SQL 需要人工干预，比如涉及MODEL子句的报表 SQL，Trae 直接标记为“UNSUPPORTED”，不尝试改写。

4.2 规则库初始化：基于达梦 V8.1 官方文档的 137 条原子规则

我们没用通用规则库，而是针对客户实际使用的达梦版本（V8.1.2.123）和 Oracle 版本（11gR2/12c），手工梳理出 137 条原子规则。每条规则包含：

• 触发模式：正则表达式，如(?i)to_char\s*\(\s*([^,]+)\s*,\s*'([^']+)'\s*\)；
• 上下文条件：Java 函数，返回布尔值，如isInSelectList(sql, matchStart)；
• 置换逻辑：字符串模板，如TO_CHAR($1, 'FM$2')；
• 影响说明：Markdown 文本，解释为何这样改，附 Oracle/达梦执行结果对比截图。

例如DM-NVL-NULL-STRING规则：

• 触发模式：(?i)nvl\s*\(\s*([^,]+)\s*,\s*([^)]+)\s*\)；
• 上下文条件：检查第二个参数是否为字符串字面量（非变量、非函数）；
• 置换逻辑：CASE WHEN $1 IS NULL OR $1 = '' THEN $2 ELSE $1 END；
• 影响说明：“达梦中空字符串''不等于NULL，此改写确保NVL语义全覆盖。注意：若$2为变量（如?），此规则不触发，需应用层处理。”

规则库以 YAML 格式管理，支持热加载——修改rules/目录下的 YAML 文件，Trae 会在 30 秒内自动 reload，无需重启应用。

4.3 SQL 采集与分析：用 Trae 的“SQL 血缘图谱”锁定高危语句

Trae 内置 SQL 采集器，可连接应用的 DataSource，实时捕获所有执行 SQL。但它不止于采集，而是构建“血缘图谱”：

• 横向关联：同一事务内的多条 SQL，标记为“事务组”；
• 纵向追踪：某条 SQL 的?参数来源（MyBatis 的#{}、JDBC 的setString、还是硬编码）；
• 风险评分：基于规则匹配数、是否含UNION、是否调用SYS.DBMS_RANDOM等，给出 0-100 分风险值。

我们用它扫描一个医保结算系统，发现风险值 >80 的 SQL 有 47 条，其中 23 条集中在“费用明细导出”功能，原因竟是该功能用了 Oracle 特有的XMLAGG函数拼接字符串。Trae 直接标记为“HIGH-RISK: XMLAGG NOT SUPPORTED”，并建议改用达梦的LISTAGG——但LISTAGG在达梦中最大长度为 4000 字符，而 Oracle 的XMLAGG无此限制。最终方案是：Trae 拦截该 SQL，返回自定义异常，由应用层分页拼接，既保功能又避坑。

4.4 灰度发布策略：按“schema-表-SQL 注释”三级开关控制

Trae+SQLazy 的灰度不是“按流量比例”，而是“按 SQL 语义粒度”：

• Schema 级：config.yml中schemas列表，只对指定库生效；
• 表级：SQL 中添加注释/* TRAE:TABLE=user_log */，Trae 识别后才启用规则；
• SQL 级：/* TRAE:ENABLE */开启改写，/* TRAE:DISABLE */直通。

上线首周，我们只对user_log表开启TO_CHAR和ROWNUM规则，其他表 SQL 全部直通。第二周加入order_info表，并启用NVL规则。每晚 22 点自动比对 Oracle 和达梦的查询结果集（抽样 1000 行），生成差异报告。某次发现order_info表的SUM(amount)在达梦中少计算了 0.01 元，追查发现是达梦对NUMBER(10,2)的舍入规则与 Oracle 不同，Trae 立即新增DM-NUMBER-ROUNDING规则，在SUM前加ROUND(..., 2)显式控制精度。

4.5 上线后验证：不只是“能跑”，而是“跑得准、跑得稳、跑得快”

验证分三层：

• 准确性验证：Trae 自动生成“SQL 对照表”，列出 Oracle 原 SQL、达梦改写 SQL、执行结果哈希值（MD5），100% 匹配才算通过；
• 稳定性验证：用 JMeter 模拟 500 并发，持续压测 2 小时，监控达梦的SESSION_COUNT、MEMORY_USED、IO_WAIT，确保无连接泄漏、无内存溢出；
• 性能验证：对比相同 SQL 在 Oracle 和达梦的执行计划，重点看FULL TABLE SCAN是否变多、INDEX RANGE SCAN是否失效。我们发现一条WHERE status IN ('A','B')的 SQL，在达梦中因统计信息不准确，走了全表扫描，Trae 的日志里自动标记“PLAN DEGRADED”，DBA 依此更新统计信息后，性能提升 8 倍。

注意：Trae 的日志不是简单记录“某条 SQL 被改写”，而是结构化输出：

{ "timestamp": "2024-05-20T14:23:11.882Z", "original_sql": "SELECT * FROM user WHERE ROWNUM <= 10", "rewritten_sql": "SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) rn FROM user) t WHERE t.rn <= 10", "rule_id": "DM-ROWNUM-LIMIT", "context": {"schema":"user_db","table":"user","in_transaction":true}, "performance_impact": {"exec_time_oracle_ms":12,"exec_time_dm_ms":15,"plan_change":"INDEX->FULL_SCAN"} }

这种日志让问题定位从“大海捞针”变成“按图索骥”。

5. 常见问题与排查技巧实录：来自三个项目的 12 个真实故障现场

5.1 故障 1：Navicat 连接达梦报错 “[HY000] 用户名或密码错误 (-2501)”

现象：开发用 Navicat 配置达梦连接，填了正确的用户名密码，却报错-2501。
排查：这不是 Trae 的问题，但常被误认为迁移工具故障。真相是达梦默认开启“口令复杂度校验”，要求密码至少含大小写字母+数字+特殊字符，而 Navicat 的密码框可能自动过滤了特殊字符（如@）。
解决：在达梦管理工具中执行SP_SET_PWD_POLICY(0);关闭复杂度校验，或重置密码为符合要求的格式。Trae 日志里不会记录此错误，因为它发生在连接建立前。

5.2 故障 2：Trae 启用后，部分 SQL 执行变慢 5 倍

现象：开启rewrite模式后，一条简单SELECT COUNT(*) FROM t耗时从 20ms 升到 100ms。
排查：Trae 的日志显示该 SQL 匹配了DM-COUNT-STAR规则，原因是达梦对COUNT(*)的优化不如 Oracle，Trae 试图用COUNT(1)替代，但COUNT(1)在达梦中仍需全表扫描。
解决：在config.yml中禁用该规则，或改用达梦的物化视图预计算总数。Trae 的价值在此刻体现：它不是盲目优化，而是暴露底层差异，逼你直面数据库特性。

5.3 故障 3：MyBatis 的<foreach>动态 SQL 在达梦中生成无效语法

现象：<foreach collection="list" item="item" open="(" separator="," close=")">#{item}</foreach>在 Oracle 下生成(1,2,3)，在达梦中却生成(1,2,3,)，末尾多逗号。
排查：达梦的 SQL 解析器对末尾逗号更严格。Trae 的DM-FOREACH-COMMA规则本应处理，但发现该规则只覆盖了IN子句，未覆盖VALUES子句。
解决：更新规则库，增加对INSERT INTO t VALUES <foreach>的专用处理，用TRIM(TRAILING ',' FROM ...)清理。此问题在 Trae 的 GitHub Issue 中已有反馈，我们提交了 PR。

5.4 故障 4：达梦执行SELECT * FROM t ORDER BY col DESC NULLS LAST报错

现象：Oracle 支持NULLS LAST，达梦不支持，但 Trae 未拦截。
排查：Trae 的规则库默认只覆盖高频 SQL，NULLS LAST属于低频特性。日志中rule_id为空，表示未匹配任何规则。
解决：手动添加规则，将NULLS LAST替换为ORDER BY NVL(col, 'ZZZZZZZZ') DESC（用极大字符串占位），或改用CASE WHEN col IS NULL THEN 1 ELSE 0 END, col DESC。Trae 的设计哲学是：不覆盖的特性，宁可报错，也不做错误改写。

5.5 故障 5：Trae 日志爆满，磁盘空间告急

现象：audit模式下，一天生成 50GB 日志。
排查：Trae 默认记录所有 SQL 的完整文本，包括大字段CLOB的INSERT语句。
解决：在config.yml中配置log_level: "summary"，只记录 SQL 摘要（前 200 字符）、规则匹配情况、执行耗时，日志体积降至 2GB/天。真正的 SQL 文本只在DEBUG级别下输出。

5.6 故障 6：达梦中SELECT SYSDATE FROM DUAL返回时间比 Oracle 慢 3 秒

现象：两个数据库服务器时间同步，但SYSDATE查询结果差 3 秒。
排查：达梦的SYSDATE依赖系统时钟，而 Oracle 的SYSDATE有内部时钟缓存。Trae 的DM-SYSDATE规则未考虑此延迟。
解决：不在 SQL 层修复，而在应用层统一用new Date()获取时间，SQL 中避免SYSDATE。Trae 的日志中标记此为“TIME_SYNC_ISSUE”，推动架构调整。

5.7 故障 7：Trae 启用后，Spring Boot 的@Transactional失效

现象：事务方法中多条 SQL，部分成功部分失败，但未回滚。
排查：Trae Agent 注入改变了类加载顺序，导致 Spring 的事务代理失效。
解决：在@Transactional方法上加@Transactional(propagation = Propagation.REQUIRED)显式声明，并升级 Spring Boot 至 2.7.18（修复了 Agent 冲突）。Trae 的兼容性列表已更新此适配项。

5.8 故障 8：达梦执行SELECT * FROM t WHERE col LIKE '%abc%'极慢，Oracle 很快

现象：LIKE模糊查询在达梦中全表扫描。
排查：达梦的LIKE索引优化不如 Oracle，Trae 无法改写 SQL，但可在日志中标记“INDEX_UNUSABLE_FOR_LIKE”。
解决：DBA 为col字段创建全文索引，或改用达梦的CONTAINS函数。Trae 的价值是提前预警，而非越俎代庖。

5.9 故障 9：Trae 生成的LIMITSQL 在达梦中返回行数不一致

现象：SELECT * FROM t LIMIT 10返回 12 行。
排查：达梦的LIMIT是“最多返回”，但若 SQL 含UNION ALL，LIMIT作用于整个结果集，而 Oracle 的ROWNUM作用于每个子查询。
解决：Trae 新增DM-LIMIT-UNION规则，对UNION ALL语句外层包裹子查询再LIMIT，确保语义一致。

5.10 故障 10：达梦中INSERT INTO t SELECT * FROM s报错 “列数不匹配”

现象：Oracle 下s表有 5 列，t表有 5 列，但达梦报错。
排查：达梦严格校验列类型，Oracle 允许隐式转换（如NUMBER→VARCHAR2），达梦不允许。
解决：Trae 的DM-INSERT-SELECT-TYPE规则自动为SELECT列表添加TO_CHAR、TO_NUMBER显式转换，确保类型精确匹配。

5.11 故障 11：Trae 的config.yml修改后不生效

现象：改了rules列表，但 Trae 仍按旧规则运行。
排查：Trae 的热加载依赖文件最后修改时间，若用cp命令覆盖，时间戳可能不变。
解决：用touch config.yml更新时间戳，或重启应用。Trae 日志中会记录 “Config reloaded at [time]”，可据此确认。

5.12 故障 12：达梦执行SELECT /*+ INDEX(t idx_col) */ * FROM t忽略 HINT

现象：Oracle 的 `