NineData 7 月更新把 SQL 开发和复制稳定性继续往前推

数据库类型越来越多、慢 SQL 越来越难统一处理、复制任务又常常卡在依赖和并发上，这些都是团队日常会遇到的问题。

 

NineData 7 月更新正是从这些使用环节切入，新增数据源适配、治理能力和复制优化，把多项常见问题放进可操作的产品链路里。

先把更多数据源接进 SQL 开发工作台

 

真正影响日常使用的地方在于，本轮调整中，SQL 窗口和 SQL 任务补充 MaxCompute，SQL 窗口新增 AWS Redshift 与 YashanDB MySQL 数据库类型。

在具体使用环节，Greenplum 对象树向 PostgreSQL 功能对齐，支持函数编辑和调试；Oracle 检索新增 Package，SQL Server 可编辑非表对象，多个 PG 系数据库类型补充对象悬浮提示。 先把能连、能写、能查的范围补全，开发人员切换数据库时就少一道阻碍。 很多人先感受到的是数据库多了不好管，实际更容易拖慢节奏的，是对象操作和日常开发总要换一套处理方法。

再把慢查询和安全流程管得更细

 

对应到数据库工作流，慢查询分析新增 OceanBase MySQL、OceanBase Oracle、达梦集中式、TDSQL PostgreSQL、TDSQL Oracle、PolarDB Oracle、PolarDB-X 与 Vastbase 覆盖。

对多数据源环境而言，脱敏与敏感数据扫描补充 GaussDB、openGauss，识别增加列名精确匹配，权限按角色收敛；核心业务表变更及 FIRST、AFTER 语法检查纳入安全规范，审批节点名称可自定义显示。

审批流程显示自定义节点名称后，复杂审批链路中每个节点所代表的处理责任会更直观。慢 SQL、敏感数据和审批本来就常在同一工作里出现，分开处理反而容易出问题。

导入导出和迁移前检查增加新入口

 

在实际任务处理中，数据导入导出新增 Elasticsearch，结果集导出兼容 UTF-8 with BOM。

从功能衔接的角度，迁移评估补充 HaishanDB。TDSQL PostgreSQL 可录入多连接地址并指定 Oracle 或 PostgreSQL 模式，Oracle 模式新增 Package、同义词、对象提示和执行计划。 导入导出与迁移评估的更新，解决的是任务开始前最容易被忽略的准备环节。

YashanDB 与 Kafka 场景进入复制能力范围

 

围绕这一类场景，MySQL、Oracle、PostgreSQL、SQL Server 等可复制到 YashanDB，YashanDB 也能向多种关系型数据库进行结构和全量复制，具体类型以链路配置页面为准。

在日常管理过程中，关系库复制到 Kafka 可投递 Avro 并配置 Confluent Schema Registry，适合对接流式平台、数据湖和下游消费应用。 数据需要流出去时，目标库和消息消费端都拥有了更清楚的衔接方式。

高并发和复杂依赖下的复制任务更稳

 

落到运行细节上，PostgreSQL 增量可按表攒批并发；不按主键行级逻辑合并时，可按 INSERT、UPDATE、DELETE 聚合并发。Oracle 写入端会识别依赖冲突并调整顺序，降低外键导致的失败风险。

从链路稳定性的维度，Oracle 至 PolarDB Oracle 的结构和增量复制支持 Materialized View Log；SQL Server 过滤更多系统表。PolarDB-X 集中式、GoldenDB、MariaDB 补充双向复制预检查及防循环条件；Doris 热点表支持表内并发，StarRocks 通过 StreamLoad 支持批量 DELETE 和部分字段 UPDATE，并优化 MySQL、OceanBase MySQL、MongoDB 等场景的连接、日志解析和任务执行。 复制真正难的不是启动任务，而是并发、依赖和循环等问题出现后的处理。 复制一旦进入复杂业务链路，最怕的是前面看似跑通、后面才暴露格式不一致、依赖冲突或延迟无法解释。

AI 对话和模型配置少一些操作阻力

 

在交互和诊断环节，ChatDBA 改善对话历史选择和 SQL 标签渲染，表格可横向滚动并适配暗色模式；可按请求语言返回中文或英文，适配 vLLM 部署体系 API，并修复 SQL 智能诊断的上下文异常。

面向配置管理操作，模型管理移除模型类型配置，模型名称改为手动输入，并增加模型配置测试与必填项提示。 AI 体验没有停在展示层面，而是落到对话、诊断和模型接入这些高频动作上。 这次 AI 体验的更新更像把高频卡点提前处理掉，让查询和接入不用在细枝末节上反复停顿。 把这些变化放在一起看，更新的重点是让复杂数据库工作少依赖零散处理方式。