企业官网建设流程全解析

简介：《SAP Data Services如何连接MySQL》是一份面向数据集成工程师、ETL开发及SAP BI实施人员的实操指南，重点解决在Business Objects Data Services中从零配置MySQL数据源的流程痛点。文档基于完整截图与步骤拆解，详细演示了新建data store、选择MySQL类型、配置ODBC连接并测试、导入表元数据、查看表结构及预览数据等关键环节，并提示了MySQL服务状态、版本兼容性及认证安全等注意事项。资源共1个docx文件，压缩包大小约1.43MB，轻量便携，适合边看边操作。目前已有1618人学习使用，内容聚焦实际环境搭建，能帮助读者一次性跑通连接流程，避免反复排查，为后续数据抽取、转换与加载奠定基础。

1. 从一次 Job 连接失败说起：SAP Data Services 连 MySQL 到底卡在哪

项目实施，数据中心要抽 MySQL 业务库，账号申请下来了，3306 防火墙放开了，Designer 里点“测试连接”，屏幕直接弹 Unable to connect。运维第一反应查网络，结果开发机这台 Windows 能连 MySQL，Job Server 所在的 Linux 就是连不上。后来才发现 Job Server 的操作系统上根本没装 MySQL 的 ODBC 驱动。SAP Data Services（BODS）作为企业级 ETL 工具，链接 MySQL 本身不复杂，真正绕人的是它的连接模型：连接不是由你鼠标所在的设计器发起的，而是由后台 Job Server 发起，驱动要装在作业服务器所在操作系统，MySQL 8 的新认证插件还能让老驱动集体翻车。我按实际项目里的顺序，把连接机制、配置步骤和几个高频坑一次讲完，给正在把 MySQL 接进 BODS 的实施或运维同事一条能照着重现的路。

2. 连接机制要先理顺：谁在连、用什么驱动、走哪个端口

2.1 谁在发起连接：Designer 不是，Job Server 才是

SAP Data Services 的架构可以简单分成三层：Designer 只管开发，Job Server 负责执行，Management Console 做日常管理和调度。在这个模型里，datastore 的配置信息会从 Designer 发布到服务器，但真正建立 TCP 连接、执行 SQL、搬运数据的，是运行在 Job Server 上的引擎进程。这个问题被很多人忽略，因为开发机上装了驱动，Designer 测试连接能过，却不知道生产 Job Server 是另一台机器，连驱动都没有，于是 Job 一发布就跑挂。

还有一个常被当成玄学的细节：Job Server 进程是 32 位还是 64 位。Windows 上引擎进程的位数由安装包决定；如果 Job Server 是 64 位，系统里有 64 位 ODBC 驱动，没问题；如果服务是 32 位，机器上只有 64 位驱动，你在 ODBC 管理器里看得到驱动，但引擎加载时就是找不到。所以排查顺序应该是：先看 Job Server 的操作系统和引擎位数，再看驱动版本和位数，最后才看网络。顺序反了，你会把大量时间耗在根本不可能的路径上。

另外，MySQL 默认监听 3306/tcp，BODS 对 MySQL 就是走 TCP。开发机能连不代表 Job Server 能连，因为两边所在网段、防火墙策略经常不一样。最直接的验证方式是在 Job Server 机器上执行 telnet <数据库IP> 3306，能通再谈后面的事。如果数据库启用了 skip-name-resolve，DSN 里的 Server 字段最好直接写 IP 而不是主机名，否则解析环节就会卡住。

2.2 选 ODBC 还是 JDBC：BODS 里两种接法的适用边界

在 BODS 里建 MySQL 数据源，通常有两条路：一是用 ODBC 驱动建一个 DSN，然后 BODS 里选 MySQL 或 ODBC 类型的 datastore；二是用通用 JDBC 连接。实际项目里我用得最多的是 ODBC 路线，因为 BODS 对 MySQL 的原生连接底层往往还是要落到操作系统的 ODBC 驱动，配置上最直观，而且出了问题可以在操作系统层先用 isql 或 ODBC 测试工具单点排错，把问题切成“数据库连接问题”和“BODS 配置问题”两段。

JDBC 路线的优势是对时区、类型映射的处理更接近 Java 生态，在部分版本里对 MySQL 8 的兼容性更好，但部署时要额外维护 jar 包和连接参数，不同 BODS 版本对 JDBC 驱动的兼容要求很挑剔。我的建议是：初期别在两条路之间反复横跳，先把 ODBC 路线走通，因为越简单的链路越容易排错。如果你所在企业的环境约束明确要求走 JDBC，那就以那套环境的兼容性矩阵为准，但注意 JDBC 方案里驱动类名、URL 模板、classpath 三样东西必须一起核对，少一个都连不上。

值得提醒的是，不同 BODS 版本对 MySQL 具体小版本的支持范围不一样，上项目前先到 SAP 的 Product Availability Matrix 里核对一下你手里的 BODS 版本支持到 MySQL 哪个版本，别等配置完才发现组合不被支持，那是最尴尬的返工。

2.3 连接要过的三层验证：驱动、账号权限与网络安全

配置前建议做一轮三层检查。第一层是驱动，操作系统必须注册好 ODBC 驱动，且位数和 Job Server 进程位数一致。Windows 上打开“ODBC 数据源管理器”的“驱动程序”页，Linux 上执行 odbcinst -q -d，确认能看到对应的 MySQL 驱动条目。这一步通不过，后面全是白搭。

第二层是账号权限。MySQL 里给 BODS 建的账号最好做成专用账号，权限收敛到具体库表。如果只是抽取，授权 SELECT、SHOW VIEW 就够了；如果要回写，再单独评估 INSERT、UPDATE、DELETE 和 DDL。别直接用业务账号或 root 连，一方面权限太大会误伤，另一方面 MySQL 8 的认证插件问题会让你连 root 都连不上的时候更难排查——因为业务系统也在用这个账号，你不能随便改它的认证方式。

第三层是网络。确认 Job Server 到 MySQL 的 3306 端口出网正常，常见做法是 telnet 或 nc -vz。有些公司的防火墙策略只放通了应用服务器到数据库，没有放通 ETL 服务器，这会在排错时给你重重一击。三层检查过了再进 Designer 建 datastore，是最省时间的顺序。

3. 用 ODBC DSN 在 BODS 里搭好 MySQL 数据源：从装驱动到跑通数据流

3.1 先装对驱动：以 MySQL Connector/ODBC 8.0 为例

Windows 下安装 MySQL Connector/ODBC 8.0，选择 Unicode Driver，安装时要注意位数跟 Job Server 服务相符。安装过程如果提示缺少 MSVCP140.dll 或直接没反应，一般是机器上没有 Microsoft Visual C++ 2015-2022 Redistributable，先补运行库再装驱动。这个坑几乎每个项目都会踩一次。

装完用 odbcad32.exe 验证。注意 64 位 Windows 自带的 odbcad32.exe 是 64 位管理器，要查 32 位驱动得用 C:\Windows\SysWOW64\odbcad32.exe，两个管理器界面长得一样，很容易看错。在“驱动程序”页找“MySQL ODBC 8.0 Unicode Driver”，找到才算装成功。

提示：如果 Job Server 是 Windows 服务方式运行，装完驱动后记得重启 Data Services Job Server 服务，否则驱动注册信息不会热加载。

Linux 下以 unixODBC 为底座，安装 mysql-connector-odbc 后编辑 /etc/odbcinst.ini，内容大致是：

# /etc/odbcinst.ini [MySQL ODBC 8.0 Unicode Driver] Driver = /usr/lib/x86_64-linux-gnu/libmyodbc8w.so UsageCount = 1 Threading = 0

然后执行odbcinst -q -d，能看到刚才的章节名才算注册成功。参数说明：Driver 指向驱动动态库的真实路径，不同发行版路径可能不同，可以用 find / -name "libmyodbc8w.so" 先找一下；Threading=0 表示驱动使用线程安全模式，BODS 并行作业会同时开多个连接，这个值别乱改。

3.2 把连接信息装进系统 DSN：Windows 图形界面和 Linux 配置文件

Windows 上打开 ODBC 数据源管理器，选择“系统 DSN”，添加，选 MySQL ODBC 8.0 Unicode Driver，然后填关键字段：

在高级连接参数里务必加上 charset=utf8mb4，字符集问题后面再补就晚了。之所以建“系统 DSN”而不是“用户 DSN”，是因为 Job Server 服务可能以 SYSTEM 或自定义账号运行，用户 DSN 存在当前用户的注册表上下文里，服务进程不一定看得到。这也是“开发机能测通、服务器跑不通”的高频原因之一。

Linux 没有图形界面，在 /etc/odbc.ini 里写：

# /etc/odbc.ini [MYSQL_BODS] Description = MySQL DSN for BODS Driver = MySQL ODBC 8.0 Unicode Driver Server = 192.168.10.12 Port = 3306 Database = sapsource User = bods_ro Password = B0d$2025! Charset = utf8mb4

然后执行isql -v MYSQL_BODS bods_ro 'B0d$2025!'，看到 Connected 才算真通。isql 是 unixODBC 自带的测试工具，报错信息会直接告诉你驱动找不到还是账号密码错，比 BODS 里弹窗的“Unable to connect”精确得多。

3.3 在 BODS 数据中心里建 MySQL 数据源：字段填写注意点

打开 SAP Data Services Designer，左侧 Datastore 视图右键新建数据源，名称填业务逻辑名比如 BODS_MYSQL，数据库类型选 MySQL（不同版本里可能叫 ODBC，以你界面弹出的列表为准），然后找到“数据源名称”字段，填 DSN 名 MYSQL_BODS。这里容易犯的错是把 DSN 名和 datastore 名搞混，BODS 里 datastore 是逻辑名称，数据源名称才是操作系统 DSN 的引用。

用户密码栏目如果 DSN 里没存密码，这里要填，也可以留空让引擎在运行时去读配置文件。填完点“测试连接”，返回成功代表开发环境配置没问题。但要清楚，Designer 测试用的驱动来自 Designer 所在机器，发布后 Job Server 跑的时候用的是 Job Server 所在机器的驱动，所以跨机器部署时，3.1 和 3.2 的步骤必须在 Job Server 上重新做一遍，这步省不得。

3.4 用最小数据流把 MySQL 表读出来：先写 CSV，别急着写表

建一个 Job，数据流里加一个读取节点，数据源选择刚建的 BODS_MYSQL，可以选表也可以输入自定义查询。做连通性验证时，我建议用自定义 SQL 而不是直接选表，一是可以控制抽取范围，二是能顺便验证语法兼容性：

SELECT OrderId, OrderDate, Amount FROM orders WHERE OrderDate >= '2025-01-01' AND OrderDate < '2025-02-01';

数据流里这个查询节点的输出接到一个文件目标，写 CSV，然后运行 Job。为什么用文件目标而不是直接写回 MySQL 表？因为文件目标能直观看到查询结果里的 NULL、乱码、日期格式，把源连接和 SQL 的问题一次性暴露出来。跑完打开 CSV，确认行数和关键字段值，源连接这块就真正闭环了，之后再换成目标表写数，排错范围会小很多。

4. BODS 连 MySQL 的避坑清单：驱动位数、认证插件、并发超时与字符集

4.1 设计器测试通过，Job Server 一跑就断：驱动装错了机器

现象：Designer 里测试连接成功，发布后执行 Job，报 Driver could not be loaded 或 DataStore connection failure。

原因：开发客户端和 Job Server 不在同一台机器，驱动只装在客户端。Job Server 发起连接时，操作系统找不到 ODBC 驱动，或者找到了但位数不匹配。

解决：在 Job Server 机器上重做驱动安装和 DSN 配置，并用 isql 或 odbcad32 验证。如果 Job Server 是 Linux，就用 /etc/odbc.ini 那套，不要拿 Windows 的 DSN 概念硬套。这是我见过最多的翻车现场，没有之一，去现场第一件事永远是问“驱动装在哪个机器”。

4.2 MySQL 8 报 Authentication plugin 错误：新版认证与老驱动的冲突

现象：测试连接报 Authentication plugin 'caching_sha2_password' cannot be loaded，或者提示 RSA encryption not supported。

原因：MySQL 8.0 默认认证插件是 caching_sha2_password，MySQL Connector/ODBC 5.x 驱动不认识这个插件，双方握手阶段直接失败。

解决：两个方向二选一。一是把驱动升级到 MySQL Connector/ODBC 8.0 及以上，新版驱动支持 caching_sha2_password；二是不方便升级驱动时，让 DBA 给 BODS 建一个使用 mysql_native_password 的专用账号：

CREATE USER 'bods_ro'@'%' IDENTIFIED WITH mysql_native_password BY 'B0d$2025!'; GRANT SELECT, SHOW VIEW ON sapsource.* TO 'bods_ro'@'%'; FLUSH PRIVILEGES;

注意一定要建专用账号，别去改业务账号的认证方式，否则影响其他系统不说，排查范围还会扩大。SHOW VIEW 权限是给 BODS 抽视图用的，如果数据源涉及存储过程，还要加 EXECUTE。

4.3 大表抽取中途断连：连接数打满和 Array Fetch Size 没调

现象：跑大表时源端 max_connections 被打满，或者 Job 跑到一半报 Lost connection to MySQL server。

原因：BODS 并行作业会对同一个 DSN 同时开多个连接，如果源表没做分区，一条 SELECT 全表扫长期持有连接，MySQL 的 wait_timeout 一到就把连接踢了；如果并行度开太高，连接数直接打满。

解决：先拆查询，再调连接参数。按主键或日期分片是最通用的做法：

-- 分片 1 SELECT * FROM orders WHERE id >= 0 AND id < 500000; -- 分片 2 SELECT * FROM orders WHERE id >= 500000 AND id < 1000000;

把分片查询分散到多个数据流并行执行，同时把数据流属性里的 Array Fetch Size 从默认值调大，减少网络往返。经验取值 100 到 1000，先按 500 试跑，观察内存和耗时再调整，不要一上来就拉满 5000，Java heap 会先撑不住。调完这些再去看 MySQL 侧 max_connections，顺序反了容易掩盖真正瓶颈。

4.4 中文乱码：DSN 没锁字符集，抽完才知道晚

现象：CSV 里中文变成 ??，或者目标表落库后中文全是乱码。

原因：MySQL 会话字符集是 latin1，DSN 连接参数没指定 utf8mb4，驱动按默认字符集取数，中文自然变形。

解决：在 DSN 连接参数里加 charset=utf8mb4，Windows 图形界面在高级参数里填，Linux 写在 /etc/odbc.ini 的 Charset 字段。这个参数在建 DSN 时就要就位，不要抽完一批数据再回头改。如果源库表本身不是 utf8mb4，比如字段 Collation 是 latin1_swedish_ci，那连接再对也没用，要先把源库字段迁移成 utf8mb4。BODS 数据流里也可以写 SET NAMES utf8mb4，但 BODS 可能对每个分区开新会话，会话级设置在并行场景下覆盖不全，不如 DSN 级别稳。

4.5 SSLMode 与特殊字符密码：两个不起眼但会卡死的连接参数

现象：连接报 SSL connection error，或者 SSL_choose_client_version 握手失败；另一种情况是密码里带着 @、$、! 等字符时，报 Access denied。

原因：MySQL 8 默认开启了 SSL，ODBC 驱动默认会协商 TLS，双方版本或证书配置不合导致握手中止；特殊字符密码在 Linux odbc.ini 解析时被截断或转移，实际提交给 MySQL 的密码已经变了。

解决：内网可信环境可直接把高级连接参数里的 SSLMode 设为 DISABLED 或 PREFERRED，生产环境建议给 MySQL 配好 CA 证书，SSLMode 设为 VERIFY_CA。密码特殊字符问题，要么在 /etc/odbc.ini 里给密码加引号，要么干脆把 BODS 专用账号的密码换成只包含字母、数字和下划线的组合，省得被各种解析器坑。改完连接参数后记得重启 Job Server 服务，ODBC 驱动不会热加载配置，这一步很容易忘。

5. 连接验证只做对一半：上线前把类型映射与抽取性能也卡一遍

5.1 抽样验证别只看行数

建好 datastore，跑通过一条数据流，并不代表可以放心交付。上线前我会做一次类型映射抽样：预览源表三到五条，重点看日期时间、DECIMAL、TINYINT、NULL 四类字段。MySQL 的 DECIMAL(20,4) 在 BODS 里如果被映射成 Double，财务金额会失真；TINYINT(1) 在部分版本里会被当成 BIT，目标端落库变成 true/false；DATE 字段里的 0000-00-00 在 MySQL 合法，在 BODS 里会直接报非法日期，导致数据流中途中断。

发现字段类型走样，优先改目标表的建表语句字段类型，而不是在数据流里叠加函数转换。源元数据不修正，每次跑作业都要多算一层，性能损失不值得。真需要在查询层处理脏日期，可以这样兜底：

SELECT CAST(Amount AS CHAR) AS Amount, CASE WHEN OrderDate = '0000-00-00' THEN NULL ELSE OrderDate END AS OrderDate FROM orders;

5.2 抽数性能与交付习惯

日增千万级的表，连接通了只是第一步。长时间抽取前一定要分片，按主键取模是最通用的做法：

SELECT * FROM orders WHERE MOD(id, 4) = 0; SELECT * FROM orders WHERE MOD(id, 4) = 1; -- 以此类推，拆成四路

四个数据流并行跑，每路配 fetch 500，比单条 SQL 全表扫通常快一半以上。同时注意 BODS 服务器和 MySQL 别跨公网机房部署，网络延迟一上来，吞吐量掉得极快，这是花再多调优都补不回来的物理短板。

交付时我习惯在项目文档里维护一张连接配置核对表，只记四行：驱动版本、DSN 名称、字符集、SSL 模式，再把专用账号的授权范围写清楚。半年后出问题，翻这个表十分钟就能定位。这套连接配置我还会每季度做一次真查询巡检，用 Job 里的自定义查询抽一条真实业务数据，而不是只点测试连接，因为测试连接很多时候恰好不会触发认证插件、字符集和 SSL 这类问题。这个习惯帮我挡过好几次源端密码轮换和网络策略变更造成的静默故障。希望帮到你。

本文还有配套的精品资源，点击获取