简介：这份资源面向使用 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，双击打开连接编辑器，或者直接在对象观察器里设。核心属性如下：
| 属性 | 值 | 说明 |
|---|---|---|
| DriverName | MySQL | 走 dbExpress 的 MySQL 驱动 |
| LibraryName | dbxopenmysql50.dll | 驱动桥接层文件名 |
| VendorLib | libmysql.dll | 底层客户端库文件名 |
| HostName | 127.0.0.1 | 服务端地址 |
| Database | your_db | 库名 |
| UserName | your_user | 账号 |
| Password | your_pass | 密码 |
| Port | 3306 | 默认端口 |
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] LibraryName=libs\dbxopenmysql50.dll VendorLib=libs\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 问题返工。希望帮到你。
本文还有配套的精品资源，点击获取
