1 概述

在信创产业快速发展的背景下，国家正在积极推动信息技术创新，打造自主可控的 IT 环境。数据库作为企业业务系统的核心组成部分，进行国产化替换或迁移到新平台，成为落实这一战略的重要工作。
本方案针对企业迁移数据库时遇到的常见问题（如大小写规则不一致、语法差异等），提供了一套简单易懂的操作方法，帮助 Smartbi 等数据分析工具与新数据库顺利对接，确保企业业务系统在新环境下稳定运行，让数据迁移更轻松、更可靠。

1.1 备份“目标环境”的知识库

迁移操作会覆盖目标环境的知识库。因此，在迁移前，请务必备份目标环境的知识库。后续若需恢复目标环境，可通过备份文件进行操作。
备份知识库功能请参考：备份知识库。


注意：如果知识库也需要迁移，在迁移业务库之前，需要先做好知识库的迁移。


2 数据库迁移完全兼容的前置条件

数据库本身迁移好后，如果希望Smartbi产品中对应的数据源及相关的资源都能正常使用，需要满足一些必要条件，同时通过产品自动或人工手动对产品中的资源进行调整。

完全兼容的前置条件

1、迁移前后的数据库都是Smartbi产品支持的数据库类型。

2、数据库的字符集一致，或者新的数据库在新的字符集下不乱码。

3、迁移前后的数据库名称、表名、字段名完全一致（包括大小写）。

4、迁移前后数据库的Schema/Catalog名称及支持完全一致。

5、迁移前后表字段的数据类型、数值字段的精度完全一致。

6、有在产品中使用存储过程的，存储过程的名称，参数，和返回结果完全一致。

7、有在产品中使用分区字段的，迁移后需要有相同的分区字段设置。

3 数据库迁移常见问题及应对方案

下表列出了在产品中使用或者需要在产品中调整的内容，如果是数据库本身迁移的更多常见问题，可参考后面章节“附录”进行处理。

序号问题分类兼容性问题说明可能影响效果

迁移场景(源库——》目标库)

影响Smartbi产品的功能范围

Smartbi产品兼容处理方案建议解决方案
1


命名与大小写问题


不同数据库对表名、列名等的大小写区分规则不同，迁移前后大小写规则可能变化


查询失败、BI图表报错


源库——》目标库表、字段的大小写规则一致

1、数据源（表、字段）。
2、拖动生成的数据集、计算字段等。

3、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））

自动兼容


源库的表、字段全部大写或全部小写——》目标库不区分大小写

1、数据源（表、字段）。
2、拖动生成的数据集、计算字段等。

3、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））

自动兼容统一命名规范，使用小写并避免保留字；如需保留大小写，建议统一使用双引号或数据库特定设置。

源库的表、字段全部大写或全部小写——》目标库区分大小写


1、数据源（表、字段）。

2、拖动生成的数据集、计算字段等。

自动兼容需要先把源库改成目标支持的大小写规则。
手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）手动兼容在产品中手工调整对应资源，以适配新的规则
源库表、字段不区分大小写含有大小写混合——》目标库区分大小

1、数据源（表、字段）。

2、拖动生成的数据集、计算字段等。

需要定制产品不知道用什么规则配对已生成的表、字段ID，需要通过定制扩展包处理。要定制并配置t_schema_idrule表，sql查询等要手工调整。
1、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）手动兼容
源库表、字段不区分大小写含有大小写混合——》目标库不区分大小

1、数据源（表、字段）。

2、拖动生成的数据集、计算字段等。

需要定制要定制并配置t_schema_idrule表
1、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）定制扩展包之后会自动兼容
2SQL语法差异不同数据库的 SQL 语法有差别，比如分页（LIMIT vs TOP）、子查询支持程度不同手写SQL失效，BI图表报错

源库——》目标库的SQL语法有差异

1、数据源（表、字段）

2、拖动生成的数据集、计算字段等

自动兼容避免手写SQL，优先使用BI工具生成的兼容SQL，或在迁移过程中进行SQL重构与适配。
手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））手动兼容在产品中手工调整成目标业务库的语法
3函数不一致不同数据库的函数名或语法不同（如 NVL、IFNULL、COALESCE）指标计算错误、查询失败，BI图表报错源库——》目标库的函数不一致

1、数据源（表、字段）

2、拖动生成的数据集、计算字段等

自动兼容抽象封装公共函数或使用BI平台提供的函数映射功能；复杂逻辑建议使用统一的计算层。
手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））手动兼容在产品中手工调整成目标业务库对应的函数
4Catalog 和 Schema 支持差异一些数据库只有 database，无 schema；有些同时有 catalog 和 schema表找不到、权限错误、SQL报错源库——》目标库的catalog、Schema 一致直接修改数据源连接自动兼容在迁移前设计好 Schema/Catalog 映射策略；BI中使用动态变量配置 schema/catalog 前缀。
源库——》目标库的catalog、Schema 不一致
手工兼容

需通过 ID 规则统一大小写（如 UPPER_CATALOG 规则,详细查看：业务库迁移之后ID替换操作）。

5分区与分布机制一些数据库支持分区表而目标数据库不支持查询效率降低源库有分区表设置——》目标库无分区表设置数据库表分区字段设置不兼容

无法兼容，之前设置的分区字段不生效

数据迁移后重新设计分区策略，或使用分布式中间件（如Doris、StarRocks等）适配分析场景。

6NULL处理差异某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致逻辑判断出错源库—》目标库，NULL处理差异回写、excel导入、指标模型创建表自动兼容
ETL写入手动兼容在产品中调整ETL对应节点，在ETL中明确NULL与空值的处理规则；统一布尔字段值的处理方式（如0/1或TRUE/FALSE）。

4 业务库迁移兼容性适配实操示例

4.1  源库与目标库信息完全一致的迁移

适用情况

具体操作步骤：

1、打开已有的数据源，修改其连接字符串的数据库名称及其对应的用户名密码：

2、点击【测试连接】确保数据库能正常连接，再点击【保存】按钮即可。
3、验证功能：

4.2 源库与目标库“大小写规则不一致”的迁移

背景：

某银行计划将原有 Impala 数据库替换为 StarRocks 数据库，需迁移表和数据。但 StarRocks 要求表名、字段名必须为全小写，不支持大小写混合（例如 Impala 中表名 “OrderInfo” 在 StarRocks 中需改为 “orderinfo”）。

问题影响：
Smartbi 中表和字段的 “身份 ID”（即系统识别的唯一标识）是根据数据库实际名称生成的。若迁移后表名 / 字段名变更（如从 “OrderInfo” 变为 “orderinfo”），Smartbi 中基于旧库创建的报表、数据集、数据模型等上层资源，会因找不到对应的 “旧 ID” 而报错（例如提示 “表不存在”“字段匹配失败”）。

解决方案：

  1. 统一命名规范：在数据迁移前，将 Impala 数据库中的表名、字段名统一修改为全小写（如 “OrderInfo”→“orderinfo”，“CreateTime”→“createtime”），确保与 StarRocks 的命名规则一致。

  2. ID 规则自动映射（兼容旧资源）：使用 ID 规则强制转换（如 LOWER_CATALOG规则将表ID转为小写）,详细可查看：业务库迁移之后ID替换操作。


4.3 源库与目标库"Catalog 、Schema 不一致"的迁移

背景：

在企业数字化转型中，数据库迁移常面临跨类型数据库架构差异与版本升级适配两大核心挑战：

  1. 跨数据库类型的天然差异：当从无 Catalog/Schema 的数据库（如旧版 MySQL）迁移至有层级结构的数据库（如 PostgreSQL）时，表的定位路径（如 “Schema. 表名”）会发生根本变化。

  2. 版本升级与多 Catalog 支持：

问题影响：元数据解析失效

Smartbi 通过 “数据源→Catalog→Schema→表→字段” 的层级关系生成唯一标识（ID），若 Catalog/Schema 名称或层级变更，上层资源（报表、数据集、数据模型）会因 “找不到旧 ID 对应的新路径” 报错，具体表现为：

解决方案：

这时候需要先把Schema/Catalog的ID替换成新的规则，详细操作可查看：业务库迁移之后ID替换操作。

4.4 源库与目标库“SQL语法有差异”的迁移

如果源库与目标库的SQL语法有差异，需要手工调整SQL语句。

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询使用子查询，如果替换成了oracle 业务库，需要手动在SQL语句中调整成Oracle 语法：

其他数据库之间不同语法，可通过AI搜索进行调整。


4.5 源库与目标库”函数不一致“的迁移

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询获取当前日期，如果替换成了PostgreSQL业务库，需要在手动在SQL语句中调整成PostgreSQL函数：


5 附录

5.1 数据库迁移其他问题与解决方案参考

该表列出了数据库迁移中跟产品功能没有直接关系，需要先在数据库层面处理好的问题。

序号问题分类兼容性问题说明可能影响效果

迁移场景(源库——》目标库)

建议解决方案
1分区与分布机制一些数据库支持分区表而目标数据库不支持查询效率降低源库有分区表设置——》目标库无分区表设置

无法兼容，之前设置的分区字段不生效

数据迁移后重新设计分区策略，或使用分布式中间件（如Doris、StarRocks等）适配分析场景。

2编码/字符集问题源数据库和目标数据库字符集不同，可能导致中文乱码文本乱码，查询结果错误源库—》目标库，编码/字符集不同迁移前统一字符集编码（如UTF-8）；采用ETL工具进行字符转换并校验。
3NULL处理差异某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致逻辑判断出错源库—》目标库，NULL处理差异
ETL中明确NULL与空值的处理规则；统一布尔字段值的处理方式（如0/1或TRUE/FALSE）。
4数据精度问题数值字段在不同数据库中精度定义不一致（如浮点型精度丢失）数据计算结果不准源库—》目标库，数据精度不一致明确字段精度范围，在迁移脚本中定义精度转换；关键字段建议使用字符串或DECIMAL类型保存。
5事务隔离级别与锁机制差异数据库事务隔离机制不同（如Snapshot、Serializable），锁粒度不一致并发异常、数据脏读源库—》目标库，数据库事务隔离机制不同避免在BI中使用事务；使用ETL调度平台时明确隔离级别，尽量避免行级锁冲突。
6执行计划优化器差异不同数据库的执行计划优化器行为不同（如JOIN顺序、并行策略）查询变慢、索引失效源库—》目标库的执行计划优化器行为不同避免强依赖某一数据库的执行计划逻辑；关键SQL可手动优化，或写入提示（hint）适配。
7跨库引用与远程表支持部分数据库支持dblink/FDW远程表，部分不支持查询失败源库—》目标库，使用数据同步中间层；或将所有依赖表迁移至同一数据库。
8数据库对象名长度限制不同数据库对表名、字段名长度有限制（如 Oracle 30 字符）无法创建表，BI建模失败源库—》目标库 表名、字段名长度有限制不一样统一命名规范，限制对象名长度 ≤ 30；可使用简写或别名方式规避。
9数据类型不兼容同一数据在不同数据库中数据类型不同（如 TEXT vs CLOB，BOOLEAN vs CHAR(1)）导入/导出失败，BI报错源库—》目标库 数据类型不同在ETL/数据同步前统一数据类型映射规则，使用中间层或数据建模工具进行类型转换。

5.2 Smartbi适配的数据库，大小写敏感配置参考

数据库名称默认大小写敏感配置方式备注
星环ArgoDB敏感无动态配置，需手动处理基于分布式架构，标识符严格区分大小写。
星环Inceptor敏感无动态配置兼容Hive语法，表名和字段名区分大小写。
Aliyun AnalyticDB不敏感自动转换为小写表名存储为小写，查询时不区分大小写。
Aliyun MaxCompute不敏感无配置项表名和字段名统一转换为小写。
CirroData敏感需使用双引号包裹标识符基于PostgreSQL扩展，继承其敏感特性。
ClickHouse敏感无配置项严格区分大小写。
DaMeng7（达梦）敏感安装时设置CASE_SENSITIVE参数（0=不敏感，1=敏感）默认敏感，建议迁移前统一标识符格式。
DB2敏感通过CREATE DATABASE时指定COLLATE规则默认区分大小写，可通过排序规则调整。
Doris不敏感自动转换为小写表名和字段名存储为小写。
GaussDB敏感类似PostgreSQL，需用双引号保留大小写华为数据库，兼容PostgreSQL语法。
GaussDB（DWS）敏感同GaussDB华为数据仓库版，行为与GaussDB一致。
Gbase-8S-V8.8敏感无动态配置表名和字段名严格区分大小写。
GoldenDB不敏感同MySQL配置（lower_case_table_names）基于MySQL开发，默认不敏感。
Greenplum敏感类似PostgreSQL基于PostgreSQL，需用双引号保留大小写。
HANA敏感默认区分大小写，可通过CASE_INSENSITIVE参数设为不敏感SAP内存数据库，建议统一大写命名。
Hive[HADOOP_HIVE]不敏感通过hive.conf设置hive.support.quoted.identifiers=none强制不敏感元数据存储为小写，但查询时不敏感。
HSQL（HyperSQL）不敏感无配置项默认不区分大小写。
HuaWei FusionInsight HD敏感依赖底层组件（如Hive或HBase）的配置需根据具体组件调整。
IMPALA不敏感同Hive配置与Hive元数据兼容，默认不敏感。
Infobright敏感无配置项基于MySQL，但默认敏感。
Informix敏感通过DBCASE环境变量设置（lower/preserve）默认区分大小写。
Kingbase敏感通过LOWER_CASE_TABLE_NAMES参数（0=敏感，1=不敏感）人大金仓数据库，类似MySQL配置逻辑。
Kingbase Analytics敏感同Kingbase分析版与标准版行为一致。
Kylin（麒麟）不敏感无配置项表名和字段名统一转换为大写。
Kyligence不敏感同Kylin商业版Kylin，默认不敏感。
MariaDB同MySQL与MySQL配置参数一致（lower_case_table_names）继承MySQL特性。
MogDB敏感类似PostgreSQL基于openGauss，需用双引号保留大小写。
MonetDB不敏感无配置项表名存储为小写。
MongoDB敏感无配置项集合和字段名严格区分大小写。
MySQL系统依赖lower_case_table_names=1（不敏感），0（敏感）Linux敏感，Windows不敏感。
Obase不敏感无配置项表名自动转换为小写。
OceanBase不敏感无动态配置表名和字段名统一小写存储。
Oracle不敏感强制大写，双引号包裹保留大小写未加双引号的标识符会被转换为大写。
Oracle TimesTen敏感无配置项内存数据库，区分大小写。
PanWeiDB敏感需手动处理基于PostgreSQL，继承其敏感特性。
PostgreSQL敏感使用双引号包裹标识符可保留大小写表名存储为小写，双引号保留原始大小写。
Presto不敏感依赖底层数据源（如Hive）的配置查询引擎自身不敏感，但数据源可能敏感。
RapidsDB敏感无配置项高性能数据库，严格区分大小写。
SelectDB不敏感自动转换为小写基于Doris，表名统一小写存储。
ShenTong（神通）敏感类似Oracle，需双引号保留大小写国产数据库，默认区分大小写。
SinoDB敏感通过CREATE DATABASE指定COLLATION原Informix数据库分支，默认敏感。
Smartbi Jdbc4Olap依赖数据源由连接的OLAP数据库决定仅为JDBC连接器，无独立行为。
Smartbi JDBC for Excel不敏感无配置项虚拟JDBC驱动，统一处理为不敏感。
Spark SQL不敏感同Hive配置默认不敏感，与Hive元数据兼容。
SQL Server取决于排序规则安装时选择Case-Sensitive或CI排序规则全局配置，无法动态修改。
StarRocks不敏感自动转换为小写表名和字段名统一小写存储。
Sybase敏感通过case参数设置（case=ignore/respect）默认敏感，需调整配置。
Teradata不敏感无配置项表名存储为大写，查询时不敏感。
TiDB不敏感同MySQL（lower_case_table_names=1）兼容MySQL，默认不敏感。
Tinysoft不敏感无配置项金融领域数据库，表名自动小写。
Vastbase敏感类似PostgreSQL基于openGauss，需用双引号保留大小写。
Vertica不敏感通过EnableCaseSensitiveIdentifier参数配置（默认关闭）默认不敏感，开启后严格区分大小写。
YMatrix敏感无配置项时序数据库，严格区分大小写。
Gbase 8C敏感无动态配置基于PostgreSQL，需手动处理大小写。
TDSQL MySQL不敏感同MySQL（lower_case_table_names=1）腾讯云分布式MySQL，默认不敏感。