简介《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 能连 MySQLJob Server 所在的 Linux 就是连不上。后来才发现 Job Server 的操作系统上根本没装 MySQL 的 ODBC 驱动。SAP Data ServicesBODS作为企业级 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/tcpBODS 对 MySQL 就是走 TCP。开发机能连不代表 Job Server 能连因为两边所在网段、防火墙策略经常不一样。最直接的验证方式是在 Job Server 机器上执行 telnet 数据库IP 3306能通再谈后面的事。如果数据库启用了 skip-name-resolveDSN 里的 Server 字段最好直接写 IP 而不是主机名否则解析环节就会卡住。2.2 选 ODBC 还是 JDBCBODS 里两种接法的适用边界在 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 先找一下Threading0 表示驱动使用线程安全模式BODS 并行作业会同时开多个连接这个值别乱改。3.2 把连接信息装进系统 DSNWindows 图形界面和 Linux 配置文件Windows 上打开 ODBC 数据源管理器选择“系统 DSN”添加选 MySQL ODBC 8.0 Unicode Driver然后填关键字段参数填写示例说明Data Source NameMYSQL_BODSBODS 里要引用这个名字TCP/IP Server192.168.10.12数据库内网 IPPort3306MySQL 默认端口Userbods_roBODS 专用只读账号Password略建议不勾选“保存密码”Databasesapsource默认连接的库在高级连接参数里务必加上 charsetutf8mb4字符集问题后面再补就晚了。之所以建“系统 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_passwordMySQL 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 试跑观察内存和耗时再调整不要一上来就拉满 5000Java heap 会先撑不住。调完这些再去看 MySQL 侧 max_connections顺序反了容易掩盖真正瓶颈。4.4 中文乱码DSN 没锁字符集抽完才知道晚现象CSV 里中文变成 ??或者目标表落库后中文全是乱码。原因MySQL 会话字符集是 latin1DSN 连接参数没指定 utf8mb4驱动按默认字符集取数中文自然变形。解决在 DSN 连接参数里加 charsetutf8mb4Windows 图形界面在高级参数里填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 默认开启了 SSLODBC 驱动默认会协商 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/falseDATE 字段里的 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 这类问题。这个习惯帮我挡过好几次源端密码轮换和网络策略变更造成的静默故障。希望帮到你。本文还有配套的精品资源点击获取