简介Kepserver与MySQL数据库对接的完整实操指南面向工业自动化工程师、数据采集与系统集成人员解决OPC服务器与关系型数据库之间的数据互通问题。资源以PDF文档形式呈现共1个文件整体仅3.89MB内容紧凑、步骤明确便于按章节逐步操作。已有2628人学习下载适合具备基础PLC或上位机知识、需要快速完成Kepserver数据落库的读者。文档从MySQL安装与Navicat管理工具配置讲起涵盖ODBC 32位驱动安装、Kepserver连接参数设置及Excel数据导入数据库等关键环节同时附有软件破解与避坑处理说明能够帮助读者跳过常见环境障碍直接跑通从设备数据采集到MySQL存取的完整链路。对于初次在Kepserver中配置数据库通道的工程师而言是一份高效、可落地的操作手册。1. Kepserver 连 MySQL从「能用」到「能扛」的差距在哪里我见过太多现场把 KepserverEX 和 MySQL 摆在一起以为只要装上 ODBC 驱动、建个 DSN、把标签地址填进去数据就能稳稳进库。实际跑起来之后有人俩小时就写爆连接有人半夜丢数据还有人发现库里多了几万条重复记录。同样的 PLC、同样的 MySQL差别几乎全在驱动选型和 SQL 绑定方式上——这也是我写这篇笔记的原因Kepserver 连 MySQL 这件事下限是能连上上限是能在生产环境里连续跑几个月不卡死、不丢点、不重复。这篇文章解决的就是从「能连上」到「能扛住」之间那段路驱动怎么选、连接串怎么填、标签地址怎么定、表怎么建、SQL 怎么绑、五个高频坑怎么绕。新手按章节走能一遍通熟手可以直接跳到第 5 章看坑在哪。2. 先选对驱动ODBC 与 ODBC Plus 的取舍以及 MySQL 连接串怎么写2.1 ODBC 和 ODBC Plus 差在哪一条 SQL 还是一批 SQLKepserverEX 连 MySQL 不是直接走 TCP 协议而是通过 ODBC 标准接口。你在通道配置里会看到两类驱动可选一类是常规 ODBC一类是 ODBC Plus通常显示为带有 Plus 标记的驱动。这两者的工作方式有本质区别第一次做选型的人最容易在这里踩空。常规 ODBC 驱动的写入逻辑是「一个标签一条 SQL」。每个标签检测到值变化或者到了更新周期驱动就单独执行一条 INSERT 或 UPDATE。这种模式在标签数量少、写入频率低比如几十个点、几秒写一次的时候完全够用配置也最简单——你只需要在标签的地址里写一段标识符然后在 SQL 属性里配好语句即可。ODBC Plus 则不一样。它支持把「多个标签的多条记录」打包成一个事务批量提交底层可以走存储过程或自动生成的 SQL 模板。简单说常规 ODBC 是每次写一条Plus 是攒一批写一次。现场点数超过两三百、写入频率到了秒级甚至毫秒级时常规 ODBC 的连接占用和日志写入会成为瓶颈而 Plus 可以明显把写库次数降下来。所以我的建议很直接新项目一律优先选 ODBC Plus除非你只是临时验证几个点的连通性。2.2 装 MySQL ODBC 驱动最容易翻车的地方32 位和 64 位选好驱动类型之后下一步是装 MySQL 的 ODBC 驱动。这一步看起来没技术含量却是翻车重灾区。Windows 上 ODBC 管理器分两套C:\Windows\System32\odbcad32.exe是 64 位C:\Windows\SysWOW64\odbcad32.exe是 32 位。KepserverEX 在 64 位 Windows 上默认以 64 位进程运行它只能加载 64 位的 ODBC 驱动。很多人装驱动时装了默认的 32 位版本然后在 ODBC 管理器里也能看到驱动、也能建 DSN测试连接也正常但 KepserverEX 新建通道时就是找不到这个驱动或者连接时报「Data source name not found」。这就是进程位数不匹配。解法是卸载 32 位驱动重新下载 64 位安装包装完后再确认 64 位管理器里能看到对应驱动条目。安装时还有一个容易被忽略的选项安装向导里会问是否把驱动安装为服务Install as service。这个建议勾上因为 KepserverEX 的运行时经常以 Windows 服务方式在后台跑勾选后驱动才能在服务上下文里被正常调用。如果装驱动时没勾之后连接服务时报权限类错误就得重新修复安装。2.3 连接串参数逐项拆解端口、字符集、超时、SSL驱动装好后你可以在 ODBC 管理器里建一个 DSN也可以不建 DSN直接在 KepserverEX 的设备连接串里写完整参数。我个人更推荐后者原因在第 5 章会详细讲——系统 DSN 和用户 DSN 在服务环境下会给你埋坑。连接串的典型写法如下SERVER192.168.1.10;PORT3306;DATABASEscada;UIDkepuser;PWDYourPass;OPTION4194304;charsetutf8mb4这段连接串的每个参数都有实际影响。SERVER和PORT是 MySQL 的地址和端口端口默认 3306如果 MySQL 改了端口这里必须同步。DATABASE指定要写入的库名。UID和PWD是数据库账号密码这里要注意账号权限至少要有 INSERT、SELECT如果走存储过程则还需要 EXECUTE 权限。OPTION4194304这个数字经常被忽略它实际是启用 ODBC 驱动的多语句支持如果写入逻辑里用了存储过程调用或者一条 SQL 里包含多条语句这个值必须带。charsetutf8mb4是字符集设置使用默认 latin1 或缺少这个参数中文标签名、设备名写进库后会出现乱码。如果 MySQL 开了 SSL 或者你需要调整连接超时可以追加SSL和CONNECTION TIMEOUT等键值不过绝大多数内网工业场景不需要 SSL。连接串填好后建议先在 Kepserver 的通道测试按钮上走一遍连通性测试能通过再进下一步避免后面建了一堆标签却全部连不上。3. 在 KepserverEX 里把通道、设备、标签串起来3.1 新建通道和设备的七步配置KepserverEX 的逻辑层级是通道Channel→ 设备Device→ 标签Tag。连接 MySQL 时通道负责承载驱动类型设备负责承载连接串标签负责定义具体写入内容。常见配置步骤是新建通道时选择 ODBC Plus 驱动然后用通道名称标识用途比如把通道命名为MySQL_HISTORY。通道建好后新建设备在设备属性里把上一步的连接串粘贴到连接字段设备名称建议用数据库表名或业务含义命名方便后面在日志里定位。# 设备连接串示例直接填在 KepserverEX 的设备属性字段里 SERVER192.168.1.10;PORT3306;DATABASEscada;UIDkepuser;PWDYourPass;OPTION4194304;charsetutf8mb4设备建好后先点测试按钮确认连接成功。这里有个容易被跳过的细节KepserverEX 的运行时引擎需要处于运行状态配置界面上的标签数值才会真正读写。如果你只改了配置没启动 Runtime测试工具显示正常但运行时始终不写入数据库检查这里。启动 Runtime 的方式通常在软件主界面的运行时控制区点一下启动即可。设备参数里还有一个「设备类型」选择列表会列出该通道驱动支持的所有具体类型。ODBC Plus 驱动下一般直接选默认项即可不要选成其它串口或网络类型否则连接串字段可能不显示。3.2 ODBC Plus 的标签地址三元组语法标签地址写法是 ODBC Plus 和常规 ODBC 最大的区别。常规 ODBC 驱动允许你写任意字符串标识符配合 SQL 属性里的语句工作。ODBC Plus 则使用固定的「表名;列名;标签名」三元组格式驱动会根据这个三元组自动生成插入语句。例如history;tag_value;Pressure_1这个地址的含义是把名为Pressure_1的 Kepserver 标签的当前值写入history表的tag_value列。驱动在运行时会对每个三元组执行一条 INSERT不需要你手写 SQL。如果你想同时写入多个测点的值比如压力和温度都要落库那就建两个标签地址分别为history;tag_value;Pressure_1 history;tag_value;Temperature_1注意这里三元组的第三个字段必须引用 Kepserver 内已经存在的标签名。很多人在这里写错成一个不存在的标签名结果驱动报「Tag not found」。另外三元组中间的字段是要写入的 MySQL 列名列的类型要和标签数据类型匹配。ODBC Plus 也支持自定义 SQL你可以让多个标签共用一条存储过程调用这点在第 4 章展开。3.3 扫描周期与写入方式别把采集周期当成写库周期KepserverEX 里每个设备都有「扫描周期」Scan Rate它决定 Kepserver 多久去读取或监测一次标签值。这里很多人会有一个误解把扫描周期当成了写库频率。实际上扫描周期只影响 Kepserver 内部对数据的采集和变化检测ODBC Plus 的写入由标签的「更新方式」控制。标签属性里有两种更新模式可选一种是变化触发On Change标签值变化了才写入数据库适合压力、温度这类连续变化的模拟量另一种是连续定时Continuous每隔固定时间强迫写一条记录即使值没变化也会写适合需要按时间轴保留状态的场景。这两种模式可以针对不同标签单独设置。实际项目中我一般把扫描周期设在 100 到 1000 毫秒把写入周期设在 1 到 10 秒。如果直接把扫描周期设成 100 毫秒又把写入设为变化触发又遇到一个抖动频繁的数字量数据库会瞬间涌入大量记录MySQL 写入压力陡增。这个问题通常在几天后才暴露——MySQL 的磁盘占用暴涨或者批量提交时锁等待超时。4. 建表与 SQL 绑定让写入从「能存」变成「好用」4.1 一张能扛住高频写入的 MySQL 表长什么样Kepserver 把数据送进 MySQL 之前你得先在建表上花点功夫。我看到过不少现场用默认建的表结构硬接数据流跑一段时间后查询慢、磁盘满、主键冲突全来了。针对工业实时数据写入场景我常用下面这个结构CREATE TABLE history ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, ts DATETIME NOT NULL, device_name VARCHAR(32) NOT NULL, tag_name VARCHAR(32) NOT NULL, tag_value DOUBLE NOT NULL, PRIMARY KEY (id), KEY idx_ts_device (ts, device_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;这个表设计有四个关键点。第一id用 BIGINT UNSIGNED 自增主键不要用标签时间戳当主键同一个时刻完全可能有多条记录同时到达时间戳主键会造成主键冲突。第二ts字段用 DATETIME 保存时间不要用 TIMESTAMPDATETIME 范围更大且不受 MySQL 时区转换影响。第三tag_value用 DOUBLE不用 FLOAT这是为了保住浮点精度工厂里很多模拟量需要精确到小数点后四位FLOAT 的有效精度大约 7 位换算成小数很可能出错。第四(ts, device_name)联合索引覆盖了按时间查设备数据的常见查询id主键则保证插入性能。如果数据量快速增长以上结构再加一条按时间范围做分区。工业数据有明显的冷热区分最近一个月的数据频繁查询三个月前的数据基本归档。分区语句可以在建表时带上ALTER TABLE history PARTITION BY RANGE (TO_DAYS(ts)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS(2025-02-01)), PARTITION p202502 VALUES LESS THAN (TO_DAYS(2025-03-01)), PARTITION pmax VALUES LESS THAN MAXVALUE );分区的好处是删除过期数据可以直接 DROP PARTITION比 DELETE 逐行删快几个数量级。注意分区键必须包含在表的主键里所以如果你按ts分区主键最好是(id, ts)复合主键计划用分区的话建表前提前规划。4.2 自动生成 SQL 和存储过程两种绑定的选择和代价ODBC Plus 提供了两种写入绑定方式。第一种是上一章讲的三元组自动生成 SQL驱动帮你拼 INSERT简单直接适合数据落库路径固定、不需要额外处理的场景。第二种是自定义 SQL 调用存储过程适合需要在写入前做去重、状态判断或者要同时更新多个表的场景。用存储过程时标签地址仍然遵循「表名;列名;标签名」规则但你可以另配一个简单的存储过程。先在 MySQL 里把存储过程建好DELIMITER // CREATE PROCEDURE sp_write_history ( IN p_tag_name VARCHAR(32), IN p_tag_value DOUBLE, IN p_ts DATETIME ) BEGIN INSERT INTO history (ts, device_name, tag_name, tag_value) VALUES (p_ts, SUBSTRING_INDEX(p_tag_name, ., 1), p_tag_name, p_tag_value); END // DELIMITER ;存储过程里SUBSTRING_INDEX可以从点分格式的标签名里截取设备名这样就不需要为每个设备建单独的表列。在 Kepserver 端标签的 SQL 属性里填CALL sp_write_history({tagname}, {value}, {timestamp})花括号变量是 Kepserver 的运行时占位符驱动执行时会替换成实际值。这里要特别强调占位符的类型敏感度。{value}在写字符串类型标签时必须用引号包起来数值类型不用{timestamp}建议用单引号包裹因为 DATETIME 字符串值需要。两者混用容易导致 SQL 语法错误报错信息会直接出现在 Kepserver 的日志里。如果你不希望花时间调试这种占位符问题就继续用默认自动生成 SQL代价是灵活性偏低。4.3 类型映射的三个边界整数、浮点、字符串Kepserver 标签的数据类型和 MySQL 字段类型之间有映射关系但并非完全透明。整数类型映射相对安全Kepserver 的 Short、Long 对应 MySQL 的 SMALLINT、BIGINT 基本不会出问题。字符串类型要注意宽度MySQL 的 VARCHAR(32) 在写入超过 32 个字符时会报数据过长错误Kepserver 端标签值会被拒写。若设备名、标签名较长VARCHAR 建议直接建到 64 或 128。浮点类型是最容易出问题的。Kepserver 从很多 PLC 驱动读到的数值默认是单精度浮点32 位。如果 MySQL 字段建成了 DOUBLE写入本身没问题但数据精度实际上在来源端就被截断了——你拿到的是一个「看起来 double、骨子里 float」的值。反过来如果 MySQL 字段是 FLOATKepserver 写入一个高精度浮点时MySQL 会按 FLOAT 的规则舍入小数位发生变化且这种变化是不可逆的。最好的策略是MySQL 字段统一用 DOUBLEKepserver 标签如果允许选数据类型也选双精度浮点两边精度一致才不丢数。还有一类容易被忽略的边界是 NULL。Kepserver 的标签在通信中断或者质量变差时写入的值可能是 NULL。如果 MySQL 字段设了 NOT NULL写入直接报错。因此建议把tag_value设成允许 NULL或者用 Kepserver 侧的逻辑把坏质量标签值替换成默认值。5. Kepserver 连接 MySQL 的 5 个高频坑现象、原因、解法5.1 系统 DSN 测试通了Kepserver 一运行就报连接失败现象在 ODBC 管理器里建好用户 DSN测试连接成功。Kepserver 设备配置里选了同一个 DSN点击测试也显示成功。但 Runtime 一启动日志里立刻刷连接失败。原因KepserverEX 的 Runtime 默认以 Windows 服务方式运行服务账户读不到当前登录用户的用户 DSN只能读系统 DSN。这属于典型的权限上下文问题。解决在 ODBC 管理器里重新建一个「系统 DSN」System DSN而不是「用户 DSN」User DSN或者按第 2 章做法根本不用 DSN直接在设备连接串里写完整参数。我后来一律用完整连接串省掉 DSN 这层间接引用问题不再出现。5.2 新版本 MySQL 默认认证插件导致连接被拒现象MySQL 版本较新ODBC 驱动版本较老连接时报错提示认证插件无法加载。原因新版 MySQL 默认使用 caching_sha2_password 认证而旧版 ODBC 驱动不认识这个插件。解决要么把 MySQL 账号认证方式改为 mysql_native_password要么升级 ODBC 驱动到支持新认证的版本。改认证方式的语句是ALTER USER kepuser% IDENTIFIED WITH mysql_native_password BY YourPass;5.3 值写得进去小数位全变了现象PLC 里读到压力值 12.3456库里查看却是 12.3450 或 12.34。原因两层引入。第一层 Kepserver 标签默认数据类型是 32 位单精度浮点精度约 7 位有效数字第二层 MySQL 字段如果用了 FLOAT 也是单精度两层舍入叠加后数值偏差放大。解决Kepserver 标签类型改为双精度浮点如果有这个选项MySQL 字段用 DOUBLE。改完后重新测试这一条能解决九成的小数位问题。5.4 数据库重启后连接不自动恢复现象MySQL 服务重启或网络抖动后Kepserver 一直显示连接失败必须手动重启 Kepserver 运行时才恢复。原因ODBC 连接在断开后没有自动重连机制驱动持有的连接句柄失效。解决在 ODBC 驱动层面打开重连选项一般是在连接串或驱动配置里开启「自动重连」再配合 Kepserver 设备属性里的重试机制一起使用。如果驱动版本不支持自动重连就用 Windows 计划任务定时检查日志检测到连接断开时通过命令行重启 Kepserver 运行时办法土但可靠。这个坑是现场最容易半夜被电话叫醒的提前做自动重连能省很多事。5.5 时间戳差 8 小时时区不是一个设置项现象库里看到的时间和本地时间相差 8 小时或者 PLC 记录的事件时间和你现场挂钟对不上。原因MySQL 的NOW()函数返回的是数据库服务器的系统时区时间跟 Kepserver 所在的机器时区不一定一致此外 Kepserver 的{timestamp}占位符写入的是本地采集时刻。两套时钟体系混在一起就差出了固定的偏移。解决统一以 Kepserver 采集时间为准在存储过程或 SQL 语句里显式使用{timestamp}占位符不要在 SQL 里用NOW()。MySQL 这边把ts字段按 DATETIME 存储同时在连接串里加时区参数固定行为例如connectionTimeZoneLOCAL让驱动按本机时区解释时间。6. 从连上到扛住批量写入与日常验证技巧6.1 批量写入的两种落地方式能连上只算第一步生产环境要看批量能力。ODBC Plus 驱动把多条记录攒成一个事务提交这是它的核心价值。你可以在 Kepserver 端调整写入批量大小让驱动每次提交几十条记录而不是一条一条地打数据库。MySQL 侧也要配合把innodb_flush_log_at_trx_commit从默认的 1 改成 2能显著降低每次事务提交的磁盘同步开销。注意这个参数存在断电丢失最近一秒事务的风险纯记录型采集场景可以接受涉及资金或安全数据的场景请保持默认值 1。建议现场按数据重要程度取舍不要盲目照抄。6.2 用一条 SQL 验证整条链路日常巡检我习惯用一条 SQL 检查数据链路是否健康SELECT COUNT(*) AS cnt, MAX(ts) AS last_time, TIMESTAMPDIFF(SECOND, MAX(ts), NOW()) AS lag_seconds FROM history WHERE ts NOW() - INTERVAL 1 HOUR;cnt能看到最近一小时的记录总量last_time显示最新一条写入时间lag_seconds代表写入延迟。正常情况下 lag_seconds 应该在几秒以内如果这个值持续增长说明数据入库已经跟不上采集速度需要回头看写入批量大小和 MySQL 的磁盘 IO。另一个验证技巧是故意改停一台 PLC 的通信看 Kepserver 日志里对应标签的质量是否由 Good 变成 Bad同时确认 MySQL 里不再新增该标签的记录。这套方法我沿用了多个现场能在数据事故发生前提前发现问题。养成的习惯是每周看一次 lag_seconds 走势趋势平稳就可以放心趋势抬头就提前处理别等数据库卡死再去查。希望帮到你。本文还有配套的精品资源点击获取