简介这份资源面向使用 Delphi尤其是 Delphi 7开发、需要通过 dbExpress 连接 MySQL 5.7 数据库的开发者重点解决网上多数 libmysql.dll 与 dbxopenmysql50.dll 版本不匹配、连接失败的问题。压缩包共 17 个文件约 1.3MB包含两个关键动态库 libmysql.dll、dbxopenmysql50.dll以及可直接运行的示例工程源码dpr、pas、dfm、dcu、测试用 SQL 脚本、可视化配置说明文档 docx 和编译好的 exe 等覆盖从库文件到可运行 Demo 的完整链路。作者在自身项目中亲测可用并额外演示了如何判断数据库字段是空值还是空字符串这一常见易错点程序可在 Windows XP 与 Windows 10 下运行发布时只需携带 libmysql、dbxopenmysql50 和 madia 三个库即可。目前已有 826 人学习下载适合需要快速打通 Delphi 连接 MySQL 5.7 环境、减少踩坑时间的开发者参考。1. 老 Delphi 项目连 MySQL 5.7为什么总卡在 libmysql.dll 这一步接手一个维护了七八年的 Delphi 老系统数据库要从 MySQL 5.5 升到 5.7代码里用的是 dbExpress 那套TSQLConnection结果一编译运行就报Cannot load vendor library [libmysql.dll]。这不是玄学是 dbExpress 的 MySQL 驱动本身不直接跟 MySQL 通信它中间要垫一层客户端动态库。这个压缩包里就是两块拼图libmysql.dll负责跟 MySQL 服务端握手、认证、收发协议包dbxopenmysql50.dll是 dbExpress 的驱动桥接层把 dbExpress 的接口翻译成 MySQL C API 调用。少了任何一个TSQLConnection都起不来。适合谁还在维护 Delphi 7 到 Delphi 2010 这段老项目、又必须对接 MySQL 5.7 的同行。下面把我拆包、部署、排错的完整过程写清楚。2. 两个动态库各管什么dbExpress 驱动链路的拆解2.1 libmysql.dll 与 dbxopenmysql50.dll 的分工很多人以为装了 MySQL 就万事大吉其实 MySQL 安装目录下的libmysql.dll是给 C 程序用的Delphi 的 dbExpress 不认。dbExpress 的架构是分层的上层是TSQLConnection、TSQLQuery这些组件中间是 dbExpress 驱动dbxopenmysql50.dll底层才是 MySQL 客户端库libmysql.dll。dbxopenmysql50.dll这个名字里的50指的是它对接 MySQL 5.0 以后的 C API 接口5.7 的客户端库在 ABI 上基本兼容所以能配。但要注意dbxopenmysql50.dll是 32 位还是 64 位必须跟你的 Delphi 编译器目标平台一致也跟libmysql.dll的位数一致。三者位数不统一就是最常见的翻车点。2.2 版本匹配为什么 5.7 的库不能随便拿 8.0 的替MySQL 8.0 的libmysql.dll改了默认认证插件从mysql_native_password换成了caching_sha2_password而dbxopenmysql50.dll是按老认证流程写的拿 8.0 的库去连 5.7 的服务端或者反过来都会在认证阶段直接断掉。所以这个包里配的是跟 5.7 匹配的客户端库。我一般会先确认服务端的认证插件-- 在 MySQL 5.7 服务端执行确认用户用的认证方式 SELECT user, host, plugin FROM mysql.user WHERE user your_user;如果plugin显示mysql_native_password那这套库就能直接用如果显示caching_sha2_password要么改用户认证方式要么换库。参数说明user和host定位具体账号plugin字段决定握手阶段用哪套算法。这一步不做后面报的错会很有迷惑性比如Lost connection to MySQL server at reading initial communication packet看着像网络问题其实是认证不匹配。2.3 部署位置放 exe 旁边还是放系统目录dbxopenmysql50.dll必须能被 Delphi 运行时找到。dbExpress 默认会去 exe 所在目录、当前工作目录、系统PATH里找。最稳的做法是两个 dll 都放 exe 同目录不要图省事丢进C:\Windows\System32。原因有两个一是系统目录里可能已经有别的版本的libmysql.dll加载顺序不可控二是 32 位程序在 64 位系统上System32里放的是 64 位库放进去反而加载失败。我习惯在项目输出目录建一个libs子目录然后在代码里显式指定路径下面会给做法。3. 从零配通 TSQLConnection参数、路径与连接测试3.1 放置动态库并确认位数先把压缩包解压得到libmysql.dll和dbxopenmysql50.dll。用 Dependency Walker 或者dumpbin /headers确认位数# 在 VS 开发者命令行里执行看 machine 字段 dumpbin /headers libmysql.dll | findstr machine dumpbin /headers dbxopenmysql50.dll | findstr machine逻辑说明输出14C machine (x86)就是 32 位8664 machine (x64)是 64 位。两个 dll 必须一致且跟你 Delphi 项目的 Target Platforms 一致。参数说明/headers读 PE 头findstr过滤关键行。如果这里就不一致后面所有配置都是白费。3.2 配置 TSQLConnection 的关键属性在窗体上放一个TSQLConnection双击打开连接编辑器或者直接在对象观察器里设。核心属性如下属性值说明DriverNameMySQL走 dbExpress 的 MySQL 驱动LibraryNamedbxopenmysql50.dll驱动桥接层文件名VendorLiblibmysql.dll底层客户端库文件名HostName127.0.0.1服务端地址Databaseyour_db库名UserNameyour_user账号Passwordyour_pass密码Port3306默认端口LibraryName和VendorLib这两个属性是重点很多人只填了LibraryName忘了VendorLib结果驱动加载了但底层库找不到报错信息还不直接指向libmysql.dll。3.3 用代码显式指定路径并测试连接如果 dll 不在 exe 同目录可以在程序启动时改路径。下面这段放在主窗体OnCreate里procedure TMainForm.FormCreate(Sender: TObject); var LibPath: string; begin // 拼出 dll 所在目录假设放在 exe 同级的 libs 下 LibPath : ExtractFilePath(Application.ExeName) libs\; // 显式指定两个库的完整路径避免加载顺序问题 SQLConnection1.LibraryName : LibPath dbxopenmysql50.dll; SQLConnection1.VendorLib : LibPath libmysql.dll; SQLConnection1.Params.Values[HostName] : 127.0.0.1; SQLConnection1.Params.Values[Database] : your_db; SQLConnection1.Params.Values[User_Name] : your_user; SQLConnection1.Params.Values[Password] : your_pass; try SQLConnection1.Connected : True; ShowMessage(连接成功); except on E: Exception do ShowMessage(连接失败: E.Message); end; end;逻辑说明ExtractFilePath(Application.ExeName)拿到 exe 目录拼上libs\后赋给两个库属性。参数说明LibraryName是 dbExpress 驱动VendorLib是 MySQL 客户端库两个都要给全路径。Params.Values里的键名注意是User_Name而不是UserName这是 dbExpress 的历史遗留写错了会提示参数无效。测试连接时把异常捕获住把E.Message打出来比直接崩掉好排查。3.4 用 dbxopenmysql50 的注意事项dbxopenmysql50.dll对字符集比较敏感。MySQL 5.7 默认utf8mb4如果连接参数里没指定字符集中文可能乱码。可以在Params里加一行SQLConnection1.Params.Values[CharacterSet] : utf8mb4;参数说明CharacterSet告诉客户端库用哪个字符集跟服务端通信跟服务端的character_set_server对应。如果服务端是utf8这里写utf8是utf8mb4就写utf8mb4。写错不会报错但取出来的中文会是问号属于典型的静默翻车。4. 避坑与排查连接失败时先看这几处4.1 报 Cannot load vendor library现象程序启动或Connected : True时抛Cannot load vendor library [libmysql.dll]。原因libmysql.dll不在搜索路径或者位数不对或者依赖的 VC 运行库缺失。解决先把两个 dll 放 exe 同目录用dumpbin确认位数再用 Dependency Walker 看libmysql.dll是否缺MSVCR120.dll之类的依赖。缺运行库就装对应的 VC Redistributable。4.2 报 Client does not support authentication protocol现象连接时提示客户端不支持认证协议。原因服务端用户用了caching_sha2_password而 5.7 时代的客户端库只认mysql_native_password。解决在服务端把该用户改成老认证方式ALTER USER your_user% IDENTIFIED WITH mysql_native_password BY your_pass; FLUSH PRIVILEGES;参数说明IDENTIFIED WITH指定认证插件FLUSH PRIVILEGES让权限表立即生效。改完再连基本能通。4.3 中文乱码但连接正常现象能连上查询出来的中文是乱码或问号。原因连接字符集跟服务端不一致。解决在Params里显式设CharacterSet并确认服务端的character_set_server和表的字符集。三处统一成utf8mb4最稳。4.4 32 位程序在 64 位系统上加载失败现象开发机 64 位编译的 32 位程序连不上换 64 位编译又报别的错。原因系统目录里的libmysql.dll是 64 位32 位程序加载不了。解决永远把 32 位 dll 放 exe 同目录不要依赖系统目录。Delphi 项目如果还要兼容老组件就统一用 32 位编译两个 dll 也用 32 位版本。4.5 换机器后突然连不上现象本机跑得好好的拷到客户机器就报错。原因客户机器上装了别的 MySQL 客户端PATH里有另一个版本的libmysql.dll加载顺序被抢。解决用全路径指定VendorLib或者在程序启动时用SetDllDirectory把 exe 目录提到搜索最前。我一般直接在代码里写全路径省得跟环境变量斗智斗勇。5. 进阶把库路径做成可配置并验证加载结果5.1 用 ini 文件管理库路径硬编码路径在部署时很被动客户可能把程序装到任意目录。我习惯用一个dbx.ini放在 exe 同目录内容就两行[dbx] LibraryNamelibs\dbxopenmysql50.dll VendorLiblibs\libmysql.dll读取代码procedure TMainForm.LoadDbxConfig; var Ini: TIniFile; BaseDir: string; begin BaseDir : ExtractFilePath(Application.ExeName); Ini : TIniFile.Create(BaseDir dbx.ini); try // 相对路径拼成绝对路径避免工作目录变化导致找不到 SQLConnection1.LibraryName : BaseDir Ini.ReadString(dbx, LibraryName, libs\dbxopenmysql50.dll); SQLConnection1.VendorLib : BaseDir Ini.ReadString(dbx, VendorLib, libs\libmysql.dll); finally Ini.Free; end; end;逻辑说明TIniFile读配置BaseDir保证相对路径基于 exe 目录而不是当前工作目录。参数说明ReadString的第三个参数是默认值配置缺失时兜底。这样客户换目录、换库版本改 ini 就行不用重新编译。5.2 验证 dll 是否真的加载成功光看Connected为 True 还不够有时候是缓存了旧连接。可以在连接成功后打印一下实际加载的模块路径function GetLoadedModulePath(const ModuleName: string): string; var Handle: HMODULE; Buf: array[0..MAX_PATH] of Char; begin Handle : GetModuleHandle(PChar(ModuleName)); if Handle 0 then Exit(未加载); SetString(Result, Buf, GetModuleFileName(Handle, Buf, MAX_PATH)); end;调用GetLoadedModulePath(libmysql.dll)如果返回的是你期望的libs目录下的路径说明加载正确如果返回系统目录的路径说明被抢了。这个习惯帮我省过很多次「明明放了新库却还是老行为」的排查时间。5.3 一个容易忽略的细节连接池与重连dbExpress 的TSQLConnection默认会保持连接如果 MySQL 服务端设了wait_timeout空闲久了会被断开下次查询报MySQL server has gone away。可以在Params里加Compress和ConnectTimeout但更稳的是在异常处理里做一次重连procedure TMainForm.ReconnectIfNeeded; begin try if not SQLConnection1.Connected then SQLConnection1.Connected : True; except on E: Exception do // 记录日志不要直接弹框打断用户 LogError(重连失败: E.Message); end; end;参数说明Connected属性读写会触发实际的连接动作放在try里避免异常冒泡。这个逻辑放在每次查询前调用一次能挡掉大部分空闲断连的问题。从那以后我每次部署这套库都强制走一遍「确认位数 → 放同目录 → 全路径指定 → 打印加载路径」的流程再也没在客户现场因为 dll 问题返工。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 10:16:22 · 阅读 1.2k Delphi 老项目连 MySQL 5.7：libmysql.dll 与 dbxopenmysql50.dll 配置避坑指南
简介这份资源面向使用 Delphi尤其是 Delphi 7开发、需要通过 dbExpress 连接 MySQL 5.7 数据库的开发者重点解决网上多数 libmysql.dll 与 dbxopenmysql50.dll 版本不匹配、连接失败的问题。压缩包共 17 个文件约 1.3MB包含两个关键动态库 libmysql.dll、dbxopenmysql50.dll以及可直接运行的示例工程源码dpr、pas、dfm、dcu、测试用 SQL 脚本、可视化配置说明文档 docx 和编译好的 exe 等覆盖从库文件到可运行 Demo 的完整链路。作者在自身项目中亲测可用并额外演示了如何判断数据库字段是空值还是空字符串这一常见易错点程序可在 Windows XP 与 Windows 10 下运行发布时只需携带 libmysql、dbxopenmysql50 和 madia 三个库即可。目前已有 826 人学习下载适合需要快速打通 Delphi 连接 MySQL 5.7 环境、减少踩坑时间的开发者参考。1. 老 Delphi 项目连 MySQL 5.7为什么总卡在 libmysql.dll 这一步接手一个维护了七八年的 Delphi 老系统数据库要从 MySQL 5.5 升到 5.7代码里用的是 dbExpress 那套TSQLConnection结果一编译运行就报Cannot load vendor library [libmysql.dll]。这不是玄学是 dbExpress 的 MySQL 驱动本身不直接跟 MySQL 通信它中间要垫一层客户端动态库。这个压缩包里就是两块拼图libmysql.dll负责跟 MySQL 服务端握手、认证、收发协议包dbxopenmysql50.dll是 dbExpress 的驱动桥接层把 dbExpress 的接口翻译成 MySQL C API 调用。少了任何一个TSQLConnection都起不来。适合谁还在维护 Delphi 7 到 Delphi 2010 这段老项目、又必须对接 MySQL 5.7 的同行。下面把我拆包、部署、排错的完整过程写清楚。2. 两个动态库各管什么dbExpress 驱动链路的拆解2.1 libmysql.dll 与 dbxopenmysql50.dll 的分工很多人以为装了 MySQL 就万事大吉其实 MySQL 安装目录下的libmysql.dll是给 C 程序用的Delphi 的 dbExpress 不认。dbExpress 的架构是分层的上层是TSQLConnection、TSQLQuery这些组件中间是 dbExpress 驱动dbxopenmysql50.dll底层才是 MySQL 客户端库libmysql.dll。dbxopenmysql50.dll这个名字里的50指的是它对接 MySQL 5.0 以后的 C API 接口5.7 的客户端库在 ABI 上基本兼容所以能配。但要注意dbxopenmysql50.dll是 32 位还是 64 位必须跟你的 Delphi 编译器目标平台一致也跟libmysql.dll的位数一致。三者位数不统一就是最常见的翻车点。2.2 版本匹配为什么 5.7 的库不能随便拿 8.0 的替MySQL 8.0 的libmysql.dll改了默认认证插件从mysql_native_password换成了caching_sha2_password而dbxopenmysql50.dll是按老认证流程写的拿 8.0 的库去连 5.7 的服务端或者反过来都会在认证阶段直接断掉。所以这个包里配的是跟 5.7 匹配的客户端库。我一般会先确认服务端的认证插件-- 在 MySQL 5.7 服务端执行确认用户用的认证方式 SELECT user, host, plugin FROM mysql.user WHERE user your_user;如果plugin显示mysql_native_password那这套库就能直接用如果显示caching_sha2_password要么改用户认证方式要么换库。参数说明user和host定位具体账号plugin字段决定握手阶段用哪套算法。这一步不做后面报的错会很有迷惑性比如Lost connection to MySQL server at reading initial communication packet看着像网络问题其实是认证不匹配。2.3 部署位置放 exe 旁边还是放系统目录dbxopenmysql50.dll必须能被 Delphi 运行时找到。dbExpress 默认会去 exe 所在目录、当前工作目录、系统PATH里找。最稳的做法是两个 dll 都放 exe 同目录不要图省事丢进C:\Windows\System32。原因有两个一是系统目录里可能已经有别的版本的libmysql.dll加载顺序不可控二是 32 位程序在 64 位系统上System32里放的是 64 位库放进去反而加载失败。我习惯在项目输出目录建一个libs子目录然后在代码里显式指定路径下面会给做法。3. 从零配通 TSQLConnection参数、路径与连接测试3.1 放置动态库并确认位数先把压缩包解压得到libmysql.dll和dbxopenmysql50.dll。用 Dependency Walker 或者dumpbin /headers确认位数# 在 VS 开发者命令行里执行看 machine 字段 dumpbin /headers libmysql.dll | findstr machine dumpbin /headers dbxopenmysql50.dll | findstr machine逻辑说明输出14C machine (x86)就是 32 位8664 machine (x64)是 64 位。两个 dll 必须一致且跟你 Delphi 项目的 Target Platforms 一致。参数说明/headers读 PE 头findstr过滤关键行。如果这里就不一致后面所有配置都是白费。3.2 配置 TSQLConnection 的关键属性在窗体上放一个TSQLConnection双击打开连接编辑器或者直接在对象观察器里设。核心属性如下属性值说明DriverNameMySQL走 dbExpress 的 MySQL 驱动LibraryNamedbxopenmysql50.dll驱动桥接层文件名VendorLiblibmysql.dll底层客户端库文件名HostName127.0.0.1服务端地址Databaseyour_db库名UserNameyour_user账号Passwordyour_pass密码Port3306默认端口LibraryName和VendorLib这两个属性是重点很多人只填了LibraryName忘了VendorLib结果驱动加载了但底层库找不到报错信息还不直接指向libmysql.dll。3.3 用代码显式指定路径并测试连接如果 dll 不在 exe 同目录可以在程序启动时改路径。下面这段放在主窗体OnCreate里procedure TMainForm.FormCreate(Sender: TObject); var LibPath: string; begin // 拼出 dll 所在目录假设放在 exe 同级的 libs 下 LibPath : ExtractFilePath(Application.ExeName) libs\; // 显式指定两个库的完整路径避免加载顺序问题 SQLConnection1.LibraryName : LibPath dbxopenmysql50.dll; SQLConnection1.VendorLib : LibPath libmysql.dll; SQLConnection1.Params.Values[HostName] : 127.0.0.1; SQLConnection1.Params.Values[Database] : your_db; SQLConnection1.Params.Values[User_Name] : your_user; SQLConnection1.Params.Values[Password] : your_pass; try SQLConnection1.Connected : True; ShowMessage(连接成功); except on E: Exception do ShowMessage(连接失败: E.Message); end; end;逻辑说明ExtractFilePath(Application.ExeName)拿到 exe 目录拼上libs\后赋给两个库属性。参数说明LibraryName是 dbExpress 驱动VendorLib是 MySQL 客户端库两个都要给全路径。Params.Values里的键名注意是User_Name而不是UserName这是 dbExpress 的历史遗留写错了会提示参数无效。测试连接时把异常捕获住把E.Message打出来比直接崩掉好排查。3.4 用 dbxopenmysql50 的注意事项dbxopenmysql50.dll对字符集比较敏感。MySQL 5.7 默认utf8mb4如果连接参数里没指定字符集中文可能乱码。可以在Params里加一行SQLConnection1.Params.Values[CharacterSet] : utf8mb4;参数说明CharacterSet告诉客户端库用哪个字符集跟服务端通信跟服务端的character_set_server对应。如果服务端是utf8这里写utf8是utf8mb4就写utf8mb4。写错不会报错但取出来的中文会是问号属于典型的静默翻车。4. 避坑与排查连接失败时先看这几处4.1 报 Cannot load vendor library现象程序启动或Connected : True时抛Cannot load vendor library [libmysql.dll]。原因libmysql.dll不在搜索路径或者位数不对或者依赖的 VC 运行库缺失。解决先把两个 dll 放 exe 同目录用dumpbin确认位数再用 Dependency Walker 看libmysql.dll是否缺MSVCR120.dll之类的依赖。缺运行库就装对应的 VC Redistributable。4.2 报 Client does not support authentication protocol现象连接时提示客户端不支持认证协议。原因服务端用户用了caching_sha2_password而 5.7 时代的客户端库只认mysql_native_password。解决在服务端把该用户改成老认证方式ALTER USER your_user% IDENTIFIED WITH mysql_native_password BY your_pass; FLUSH PRIVILEGES;参数说明IDENTIFIED WITH指定认证插件FLUSH PRIVILEGES让权限表立即生效。改完再连基本能通。4.3 中文乱码但连接正常现象能连上查询出来的中文是乱码或问号。原因连接字符集跟服务端不一致。解决在Params里显式设CharacterSet并确认服务端的character_set_server和表的字符集。三处统一成utf8mb4最稳。4.4 32 位程序在 64 位系统上加载失败现象开发机 64 位编译的 32 位程序连不上换 64 位编译又报别的错。原因系统目录里的libmysql.dll是 64 位32 位程序加载不了。解决永远把 32 位 dll 放 exe 同目录不要依赖系统目录。Delphi 项目如果还要兼容老组件就统一用 32 位编译两个 dll 也用 32 位版本。4.5 换机器后突然连不上现象本机跑得好好的拷到客户机器就报错。原因客户机器上装了别的 MySQL 客户端PATH里有另一个版本的libmysql.dll加载顺序被抢。解决用全路径指定VendorLib或者在程序启动时用SetDllDirectory把 exe 目录提到搜索最前。我一般直接在代码里写全路径省得跟环境变量斗智斗勇。5. 进阶把库路径做成可配置并验证加载结果5.1 用 ini 文件管理库路径硬编码路径在部署时很被动客户可能把程序装到任意目录。我习惯用一个dbx.ini放在 exe 同目录内容就两行[dbx] LibraryNamelibs\dbxopenmysql50.dll VendorLiblibs\libmysql.dll读取代码procedure TMainForm.LoadDbxConfig; var Ini: TIniFile; BaseDir: string; begin BaseDir : ExtractFilePath(Application.ExeName); Ini : TIniFile.Create(BaseDir dbx.ini); try // 相对路径拼成绝对路径避免工作目录变化导致找不到 SQLConnection1.LibraryName : BaseDir Ini.ReadString(dbx, LibraryName, libs\dbxopenmysql50.dll); SQLConnection1.VendorLib : BaseDir Ini.ReadString(dbx, VendorLib, libs\libmysql.dll); finally Ini.Free; end; end;逻辑说明TIniFile读配置BaseDir保证相对路径基于 exe 目录而不是当前工作目录。参数说明ReadString的第三个参数是默认值配置缺失时兜底。这样客户换目录、换库版本改 ini 就行不用重新编译。5.2 验证 dll 是否真的加载成功光看Connected为 True 还不够有时候是缓存了旧连接。可以在连接成功后打印一下实际加载的模块路径function GetLoadedModulePath(const ModuleName: string): string; var Handle: HMODULE; Buf: array[0..MAX_PATH] of Char; begin Handle : GetModuleHandle(PChar(ModuleName)); if Handle 0 then Exit(未加载); SetString(Result, Buf, GetModuleFileName(Handle, Buf, MAX_PATH)); end;调用GetLoadedModulePath(libmysql.dll)如果返回的是你期望的libs目录下的路径说明加载正确如果返回系统目录的路径说明被抢了。这个习惯帮我省过很多次「明明放了新库却还是老行为」的排查时间。5.3 一个容易忽略的细节连接池与重连dbExpress 的TSQLConnection默认会保持连接如果 MySQL 服务端设了wait_timeout空闲久了会被断开下次查询报MySQL server has gone away。可以在Params里加Compress和ConnectTimeout但更稳的是在异常处理里做一次重连procedure TMainForm.ReconnectIfNeeded; begin try if not SQLConnection1.Connected then SQLConnection1.Connected : True; except on E: Exception do // 记录日志不要直接弹框打断用户 LogError(重连失败: E.Message); end; end;参数说明Connected属性读写会触发实际的连接动作放在try里避免异常冒泡。这个逻辑放在每次查询前调用一次能挡掉大部分空闲断连的问题。从那以后我每次部署这套库都强制走一遍「确认位数 → 放同目录 → 全路径指定 → 打印加载路径」的流程再也没在客户现场因为 dll 问题返工。希望帮到你。本文还有配套的精品资源点击获取