企业官网建设流程全解析

简介：面向 Delphi 7 开发者，这份 zip 资源专门解决通过 dbExpress 连接 MySQL 5.7 时动态库缺失或不兼容的常见问题，内含可直接使用的 libmysql.dll 与 dbxopenmysql50.dll，并配有可运行验证的测试工程，省去了四处寻找可用 DLL 的周折。压缩包共 17 个文件，体积仅 1.3MB，主要文件包括 dll 动态库、sql 建表脚本、pas/dpr/dfm 源码与窗体，以及一份 dbExpress 面板 TSQLConnection 可视化配置的 docx 说明文档；其中 ddp、res、cfg 等是 IDE 辅助文件，~dfm、~dpr 等为开发时自动生成的备份，不影响使用。作者强调该方案在自身项目中亲测可用，网上常见的多数方案无法生效；资源还专门演示了数据库字段空值和空字符串的区分判断，对读取 MySQL 数据时容易混淆的场景很有帮助。程序兼容 Windows XP 和 Windows 10，发布部署时只需带上 libmysql、dbxopenmysql50 等核心动态库即可运行；目前已有 822 人学习/下载，适合 Delphi 老版本用户连接 MySQL 5.7 时参考，或作为新项目快速接入的排错样板。

1. 为什么 Delphi 连 MySQL 5.7 偏偏要这两个 DLL：先搞懂它再动手

不少刚接触 Delphi 的老开发，第一次用 dbExpress 连接 MySQL 5.7 时都会卡在一个非常尴尬的报错上——数据库开着、用户名密码没错、客户端工具连得上去，可 Delphi 的程序一跑起来就是“Cannot load vendor library”或者“Unable to load dbxopenmysql50.dll”。折腾半天才发现，程序根本不看你数据库本体的配置，它只认两个动态库：libmysql（MySQL 的客户端连接库）和dbxopenmysql50（dbExpress 的 MySQL 驱动）。这两个文件没放对位置、版本不匹配或者位数不对，连写一万行 SQL 都白搭。

这个标题看着像是个资源包的描述，实际上它指向了一条非常具体的落地路径：要在 Delphi 里用 dbExpress 稳定连上 MySQL 5.7，你绕不开这两个文件——一个负责和 MySQL 服务器说话，另一个负责让 Delphi 的 dbExpress 能听懂 MySQL 的话。这篇文章就围绕这两个库展开，从驱动选型讲到部署配置、代码关联、报错排查和验证技巧，你照着做就能在本地把这条链路打通。

2. 拆解 dbExpress 连 MySQL 5.7 的驱动结构：为什么是这两个库在干活

2.1 dbExpress 的双层驱动机制：VendorLib 和 LibraryName 不是一回事

先看 dbExpress 连数据库的整体架构。dbExpress 本身是一套跨数据库的接口层，它不直接和数据库通信，而是通过“驱动提供商”来转发。这个驱动器并不像 ODBC 或 JDBC 那样包揽一切，它被设计成双层结构：驱动动态库和厂商客户端动态库。

第一层是dbxopenmysql50.dll，它是 dbExpress 官方的 MySQL 驱动。Delphi 的 TSQLConnection 通过 DriverName 来指定用哪套驱动，比如这里用 DriverName = 'MySQL'，驱动内部通过LibraryName参数找到 dbxopenmysql50.dll，再从这个库导出 getSQLDriverMYSQL 之类的入口函数来实例化驱动对象。这一层处理的是 dbExpress 的标准接口转换、SQL 解析适配、结果集的映射等。

第二层是libmysql.dll，它是 MySQL 官方提供的客户端连接库。dbxopenmysql50 自身不实现 MySQL 网络协议，它把连接建立、握手认证、命令发送这些事全部交给 libmysql.dll。dbExpress 驱动通过 VendorLib 参数来定位这个库。也就是说，没有 libmysql.dll，驱动连不上服务器；没有 dbxopenmysql50.dll，Delphi 不会知道该加载哪个驱动。

这里面最容易出问题的是版本匹配。dbxopenmysql50 这个名字虽然带有“50”字样，但它并不是只能连 MySQL 5.0，而是对应 dbExpress 驱动内部使用的“5.0 方言版本”。Delphi 7 之后的版本，dbxopenmysql50 的兼容性覆盖到 MySQL 5.7 都没有问题，关键在于 libmysql 的版本要和服务器握手协议兼容。MySQL 5.7 的 libmysql.dll 能正常连接 5.7 服务器，但你把 MySQL 8.0 的 libmysql.dll 拿过来喂给 dbxopenmysql50，很多接口行为就不一致了，典型表现是连接能建上，但查询返回结果和字符集处理开始出现各种奇怪问题。

2.2 libmysql 的选型细节：官方版和免安装版的取舍

libmysql.dll 的来源并不只有一个地方。安装 MySQL 5.7 时，安装目录下会有这个文件，比如 C:\Program Files\MySQL\MySQL Server 5.7\lib\libmysql.dll。注意它有好几个版本，32 位的在 x86 目录，64 位的在 x64 目录（实际上 64 位版本的 DLL 名常是 libmysql.dll 或 libmysql64.dll，具体看安装包）。在免安装版本的 MySQL 5.7 压缩包里，文件也在 lib 目录下。

对 Delphi 开发来说，最大的坑是应用编译的位数决定你不该用哪个 libmysql。你的 Delphi 程序如果编译成 32 位，那你要加载的 libmysql.dll 必须是 32 位版本；如果程序是 64 位，就得用 64 位版本。位数的匹配看起来很简单，但实际项目里容易翻车——有的人在开发机上直接复制了 64 位的 libmysql 到一个 32 位 Delphi 程序目录中，运行时加载失败，或者加载到了但初始化时崩溃。用 dbExpress 测试连接时这种崩还不是立刻崩，而是偶尔崩一次，非常玄学。

另外多说一个点：MySQL 5.7 的官方 libmysql 对 Windows 的运行时依赖比较多，它需要 VC++ 运行库。如果目标机器是精简版系统，缺 MSVCR120.dll 或 VCRUNTIME140.dll，你的程序加载 libmysql 时会报“找不到指定的模块”，但这个报错经常被误判为“libmysql 损坏”。

2.3 dbxopenmysql50 的版本差异：Delphi 版本不同，驱动 DLL 不通用

dbxopenmysql50.dll 的来源是 Delphi 安装目录。Delphi 7 的 bin 目录里有这个文件，Delphi 2007、Delphi XE 系列、Delphi 10.x 也都有，但不同版本 Delphi 对应的 dbxopenmysql50 不能互相乱用。因为 dbExpress 的接口版本有变化，驱动 DLL 内部实现的接口签名和 Delphi 编译器生成代码的 RTL 版本不完全一致，强行换一个路径的 dbxopenmysql50 往往导致“Bad variant type”或者直接访问违例。

一个实际常见的做法是：不使用 Delphi 自带的驱动，而是直接用 dbExpress 的驱动源码重新编译一份符合你自己 Delphi 版本的 dbxopenmysql50.dll。这个做法适合需要修改驱动行为的高级项目，但大多数情况下没这个必要。对从业者来说，老老实实从自己电脑的 Delphi 安装目录拷贝对应文件到程序目录，是最稳妥的。

还需要注意一个细节：dbxopenmysql50.dll 只是驱动主模块，如果版本对应的是一个较老的 dbExpress，驱动目录下可能还要带一个 dbxdrv.dll 或类似基础库。不过通常只要你把 bin 下的文件复制全，很少缺基础库。

3. 部署这两个动态库到项目：路径规划、配置文件和第一版连接串

3.1 把 dll 放到哪里：程序目录还是系统 PATH

部署的第一步是把 DLL 放到程序运行时能找得到的地方。Windows 加载 DLL 的顺序包括了程序所在目录、系统目录、PATH 环境变量目录等。经验做法是把libmysql.dll 和 dbxopenmysql50.dll 放在程序同一个目录下。这样做的好处是两台不同的服务器上部署时，不需要改系统 PATH，程序自带的目录优先被找到，不容易被其他目录下的同名 DLL 干扰。

如果你的程序是客户端程序，安装包制作时要把这两个文件加进去；如果是中间件程序跑在服务器上，同样得保证当前工作目录有这些文件。不要觉得“MySQL 都装在服务器上了，肯定能找到 libmysql”——那是给 ODBC 用的路径，不是给 Delphi 用的路径，两者完全不重合。

另外一个容易掉的坑是文件名大小写。Windows 不区分大小写，但是如果你把 libmysql.dll 改名成了 LibMySQL.dll，程序基本还是能加载，但 dbxopenmysql50 内部判断有些版本会宽松也能过。问题是你在 dbx 的连接参数里如果写错了名字，比如 LibMySQL.dll 和实际文件大小写不一致，在 Windows 上没事，但将来如果项目跨平台（Delphi 出了 Linux 编译器），就可能在 Linux 上找不到文件，因为 Linux 是大小写敏感的。所以一开始就统一用标准小写命名，省去后面很多麻烦。

3.2 通过 TSQLConnection 配置驱动参数：三件套参数是关键

在 Delphi 的窗体上放一个 TSQLConnection，设置 DriverName 为 'MySQL'，然后展开 Params 属性，你会看到一堆驱动参数。核心的是以下这三个，其他参数用的默认值：

LibraryName：驱动库的路径名。可以只写文件名，比如 dbxopenmysql50.dll，程序会在当前目录和系统路径里找。也可以写绝对路径，但绝对路径不利于换机部署。所以一般只写文件名。

VendorLib：厂商客户端库路径名，同上，写 libmysql.dll 即可。

GetDriverFunc：这个函数名是驱动导出入口，绝大多数 MySQL 驱动版本填的是 getSQLDriverMYSQL。不要随意改动。

此外有几个常见参数和连接关系密切，比如：

• HostName：服务器 IP 或域名。
• Port：默认 3306。
• Database：要连接的库名。
• User_Name：建议不要写在代码里硬编码，特别是版本管理的时候很容易泄露。
• Password：同 User_Name 一个道理。

代码里要建连接之前，先把参数设好，再调用 Connected := True。如果报错，第一反应去看 LibraryName 和 VendorLib 的解析路径。可以通过一个日志输出 DBXError 相关信息辅助排查，但初学者往往是卡在 DLL 文件本身加载失败这个层面。

3.3 连接池和 TSQLConnection 的 Connected 管理

dbExpress 的连接池在服务端应用里非常有用。就算你不是做中间件，只是写单机工具，也建议打开 Pooling，但要理解它的机制。dbExpress 的连接池是以连接字符串和驱动参数为 Key 的，如果连接参数不一样，池子会创建多个条目。你在修改了连接参数之后，如果还沿用之前池子里缓存的连接，可能会出现配置不生效的假象。

常见做法是先把 Connection 的 Connected 设为 False，再修改 Params，再调用 Open 或设置 Connected 为 True。如果开了连接池，修改参数后你并不一定真的拿到新连接——因为池子里的连接未必回收了。解决方法是调用 SQLConnection.Driver.Close 或者把 TSQLConnection 直接 Free 重建，这个区别在长期运行的服务里很关键。

另外，dbExpress 的 TSQLConnection 跟 ADO 的 TADOConnection 不同，它默认不缓存元数据，所以连接建立的速度会快一些，但对字符集、事务等的配置也有更多的细节要自己控制。

3.4 部署清单：最小文件集合验证

为了做最小验证，你应该准备一份干净的部署清单来确认“文件齐了”：

• 你的编译产物 exe。
• dbxopenmysql50.dll。
• libmysql.dll。
• dbexpsda.dll 或类似 dbExpress 基础驱动支持库（按 Delphi 版本不同，名称有差异）。
• midas.dll（如果用了数据集提供器，有些应用要这个）。

我一般会用一个文件夹专门做部署验证，把以上文件全复制进去，然后跑一个最简单的连接测试。如果最小集合能连上，那后续功能问题就不是部署问题。

4. 用 Delphi 代码跑通 MySQL 5.7 连接：最小可复现工程与参数说明

4.1 一个能直接跑的最小窗体代码

下面这段代码是基础形态，没有第三方控件，只用 dbExpress 自带组件。新建一个 Delphi 工程，在窗体上放 TSQLConnection、TSQLQuery、TSimpleDataSet（如果版本支持）或者 TDataSource 和 TDBGrid，按下述方式配置就行。直接看代码：

procedure TForm1.Button1Click(Sender: TObject); var Conn: TSQLConnection; Qry: TSQLQuery; begin Conn := TSQLConnection.Create(nil); try Conn.DriverName := 'MySQL'; Conn.LibraryName := 'dbxopenmysql50.dll'; Conn.VendorLib := 'libmysql.dll'; Conn.GetDriverFunc := 'getSQLDriverMYSQL'; Conn.Params.Values['HostName'] := '127.0.0.1'; Conn.Params.Values['Port'] := '3306'; Conn.Params.Values['Database'] := 'testdb'; Conn.Params.Values['User_Name'] := 'root'; Conn.Params.Values['Password'] := '123456'; Conn.Params.Values['BlobSize'] := '-1'; Conn.Params.Values['CharSet'] := 'utf8mb4'; Conn.Params.Values['Pooling'] := 'True'; Conn.Connected := True; Qry := TSQLQuery.Create(nil); try Qry.SQLConnection := Conn; Qry.SQL.Text := 'SELECT VERSION() AS v'; Qry.Open; ShowMessage('MySQL 版本: ' + Qry.FieldByName('v').AsString); finally Qry.Free; end; finally Conn.Free; end; end;

这段代码的逻辑是：创建连接对象后，先设置驱动定位参数，再写连接信息；把 Connected 置 True 后，系统会加载 dbxopenmysql50.dll 并顺带加载 libmysql.dll。如果加载失败会抛异常，异常信息通常会提示是找不到模块。之后执行一段查询，验证整个链条无误。

注意到这里Conn.Params.Values['BlobSize'] := '-1'，这一行很关键：blob 大小默认值在不同版本驱动里不太一样，-1 代表不限制，避免大字段查询时被截断。然后 CharSet 设置为 utf8mb4，如果你要在 MySQL 5.7 里存中文或者 emoji，字符集这里最好显式指定，不然它会沿用驱动默认的 latin1，导致中文乱码。这里面其实埋了一个大坑：dbExpress 连接 MySQL 时，驱动默认字符集不一定跟随你数据库的设置，而是跟着客户端库的默认值走，所以代码里显式指定才是可靠方案。

4.2 参数配置的另一种方式：DBX 配置文件

除了在代码里写 Params 属性，也可以用 dbxconnections.ini 或 dbx.ini 配置文件来集中管理。这种方式适合多个连接配置切换的场景，比如开发库、测试库、生产库三套配置。切换时只需要改 ini 文件里的连接名，不用重新编译程序。

以 dbxconnections.ini 为例，其内容结构大概如下：

[MySQL] DriverName=MySQL LibraryName=dbxopenmysql50.dll VendorLib=libmysql.dll GetDriverFunc=getSQLDriverMYSQL HostName=127.0.0.1 Port=3306 Database=testdb User_Name=root Password=123456 CharSet=utf8mb4 Pooling=True

在使用配置文件管理器时，你在代码里只要设置 TSQLConnection 的 ConnectionName 属性，再调用 LoadParamsFromIniFile 方法就可以把配置读进来。这种方式比代码写死更推荐，毕竟修密码和换库不需要动代码。

不过要小心一个问题：dbxconnections.ini 的路径问题。如果你在 IDE 里运行程序，它会用 Delphi 安装目录下 bin 里的 ini 文件；编译成 exe 后，它就只认程序当前目录下或操作系统标准位置的 ini 了。如果你把 ini 文件放错位置，配置加载不出来，程序会默认用驱动自带的默认参数，这会导致连接信息完全不对。

所以我的习惯是：程序启动时显式指定 ini 路径，比如用 ExtractFilePath(Application.ExeName) + 'dbxconnections.ini' 作为参数传给 LoadParamsFromIniFile，这样就不会被默认查找路径绕晕。

4.3 通过 TSQLMonitor 捕获 dbExpress 发出的 SQL

连接上了以后，你肯定想看 dbExpress 到底向 MySQL 发了什么 SQL。dbExpress 有官方配套的监控组件 TSQLMonitor，用法非常简单：

SQLMonitor := TSQLMonitor.Create(nil); SQLMonitor.SQLConnection := Conn; SQLMonitor.FileName := 'dbx_log.txt'; SQLMonitor.Active := True;

这个组件的意义在于：它能记录 dbExpress 驱动层接收到的命令和结果，帮你分析“是不是驱动把 SQL 解析错了”这类问题。之前遇到过一个现象——查询返回的日期字段总是偏一天，测出来其实是 dbExpress 驱动把 DATETIME 类型映射成 TDateTime 时时区处理有偏差，不去看监控日志根本定位不到。通过日志能看到实际发送到 MySQL 的 SQL 和参数，就能快速判断是不是封装的 SQL 出了问题。

有一点要说清楚：TSQLMonitor 的日志是文本型，记录量大，生产环境不建议长期开着，它会影响性能，也可能把敏感 SQL 写进日志里。一般只在开发和联调阶段启用，而且日志文件要定期清理。

4.4 错误处理和 GetLastError 的组合判断

连接失败时 Delphi 会抛出 EDatabaseError 异常。异常信息对 DLL 缺件的判断很有帮助，但它提供的信息不是结构化的，经常是这样的：

• “Cannot load vendor library” 表示 vendor 库加载不出错。
• “Cannot load dbxopenmysql50.dll” 表示驱动库加载失败。
• “Invalid variant type”之类的异常有时候也是 DLL 版本不匹配导致。

实际排错时，光靠异常信息不够。我一般会在代码里加入一个系统级的错误码检查，用 GetLastError 把错误号带出来再转换成文字，以便定位模块缺失或依赖问题。比如：

function GetLastErrorMessage: string; var ErrCode: Integer; begin ErrCode := GetLastError; Result := SysErrorMessage(ErrCode); end;

加了这一层之后，126 错误号代表“找不到指定的模块”，193 代表“不是有效的 Win32 应用程序”。后者非常典型，意思是你把 64 位的 libmysql.dll 塞给了 32 位程序，系统能读到文件但无法运行它。有了错误码，排查步骤就清晰了，不用瞎猜。

5. 运行期报错排查与避坑记录：三个高频问题的现象与分析

5.1 现象：连接失败提示 Cannot load vendor library，但 DLL 明明放在同目录

这个现象几乎每个用 dbExpress 连 MySQL 的人都会遇一次。DLL 文件放在程序目录，文件也存在，用工具查看也有导出函数，可程序就是加载不了。

原因分两类。第一类是系统找不到依赖的 C++ 运行库：libmysql.dll 是 MySQL 官方用 C++ 编写的客户端库，依赖 MSVC 运行库，目标机器缺库时，DLL 文件在但加载失败。第二类是 Windows 加载路径问题：如果你的程序不是双击创建的进程，而是由其他进程（比如 IDE 调试器）拉起来的，那么 DLL 搜索路径不完全是 exe 所在目录，环境变量 PATH 和系统目录的优先级反而更高，程序找不到就是找不到。

解决方式第一条是去 MySQL 安装目录下取一份官方自带的对应位数 libmysql.dll，替换程序目录中的文件；第二条是安装对应的 VC++ Redistributable 包；第三条是放弃依赖 PATH，在程序启动时用 SetDllDirectory 显式指定 DLL 查找目录。实际工作中我常用的做法是调用 SetDllDirectory 设置 exe 所在目录，再用 LoadLibrary 做一次预加载，确保后续的自动加载不出意外。

解决办法：先用 GetLastError 拿错误码，若为 126，补运行库或显式 SetDllDirectory；若为 193，换匹配位数的 DLL。

5.2 现象：连接成功但中文乱码，INSERT 的内容到库里变问号

这个现象非常容易误判。开发环境连接一切正常，部署到客户机器上就中文乱码了，很多人第一反应是“MySQL 字符集没配对”。实际查数据库发现，MySQL 服务端的表结构都已经是 utf8mb4，配置文件也设置了 character_set_server=utf8mb4，但乱码依旧存在。

原因在于 dbExpress 驱动初始化连接时，它发送给 MySQL 的初始 SET NAMES 语句是按驱动自己的 CharSet 参数来的。你代码里没有显式设置 CharSet，驱动默认用 latin1，这个默认值不随数据库服务端配置改变。解决方式是在连接参数里增加Conn.Params.Values['CharSet'] := 'utf8mb4'，这是最直接的解法。

还有一个额外隐患：如果使用 dbExpress 驱动自带的 CharSet 映射，旧版本驱动对 utf8mb4 的支持并不完整，某些版本只认识 utf8。这种情况下你要么换更新版本的 dbxopenmysql50，要么在连接后手动执行一次 SET NAMES utf8mb4。后者虽然“脏”一点但稳定，适合不想折腾驱动版本的项目。

5.3 现象：程序能连 MySQL，但事务提交后数据丢失

在 MySQL 5.7 中，如果使用 MyISAM 表，事务是不支持的；但这个问题通常发生在 InnoDB 表上。dbExpress 的 TSQLTransaction 在提交时是否真的发起了 COMMIT，取决于驱动的 Transaction Isolation 设置和自动提交行为的配合。如果你没有显式调用 TSQLTransaction.StartTransaction，而是依赖驱动默认自动提交，一切正常；但是当你调用了 StartTransaction 而没有正确 Commit 或 Rollback，连接又复用时事务状态会被重置，导致数据丢失。

另一个常见原因是驱动参数中的UseQuoteChar或BlobSize配置异常，影响了 SQL 文本的解析，导致 INSERT 语句被截断或字段映射错位。事务丢数据的排查思路是先关掉连接池，用单条连接跑一遍完整的事务操作，看是否还丢；如果不丢，问题就出在池子复用连接时的事务状态清理。

解决方案是在每次连接取出后检查Conn.InTransaction属性，如果为 True 且与当前逻辑不符，先 Rollback 再 StartTransaction。dbExpress 的连接池比较原始，不会自动帮你清理未完成事务，这一点和 ADO 的连接池行为不一样。

5.4 现象：换了一台机器，程序突然找不到驱动

部署路径问题。开发机上可能是 Delphi IDE 帮你把 bin 路径加到了系统 PATH，所以开发程序能加载 DLL。部署到新机器上，PATH 里没有 Delphi 的 bin 目录，文件名如果没放在 exe 的当前目录下，就必然加载失败。

解决方式就是按 3.1 节的部署清单，把所有 DLL 放 exe 目录。另外，还有一种情况是杀毒软件拦截了 DLL 加载，比如 dbxopenmysql50.dll 没签名，某些安全策略会直接禁止加载，报错也是找不到模块。遇到这种，单独给目录加白名单或者用工具看事件日志，经常会发现加载尝试被拦截了。

6. 进阶验证与调试技巧：确认驱动和库的真实版本与加载状态

6.1 用 LoadLibrary 预检测两个库能否加载，避免黑匣子挫败感

dbExpress 报错信息通常不够直观，特别是你分不清是哪个库出问题时，直接做一步预检测能省很多时间。在程序启动或调试期，先用 Windows API 把库加载一遍，只加载不调用，用返回值判断：

function TestLibraryLoad(const ALibName: string): Boolean; var H: HMODULE; begin H := LoadLibrary(PChar(ALibName)); Result := H <> 0; if H <> 0 then FreeLibrary(H); end;

这个函数在测试连接前调用：

if not TestLibraryLoad('dbxopenmysql50.dll') then raise Exception.Create('驱动加载失败: ' + SysErrorMessage(GetLastError)); if not TestLibraryLoad('libmysql.dll') then raise Exception.Create('客户端库加载失败: ' + SysErrorMessage(GetLastError));

这段预检测的好处是：报错更早，定位更准，能明确告诉你是谁被加载失败，而不是让 dbExpress 在连接时才抛一个模糊异常。实际开发中我还遇到过一种情况：两个库都能加载，但驱动就是连不上，这个时候再去看驱动内部导出函数是否齐全。

你可以进一步用 GetProcAddress 检查 dbxopenmysql50.dll 的导出函数名：

function CheckDriverEntry: Boolean; var H: HMODULE; begin H := LoadLibrary('dbxopenmysql50.dll'); Result := GetProcAddress(H, 'getSQLDriverMYSQL') <> nil; FreeLibrary(H); end;

如果这里返回 False，说明文件被替换成了别的版本或文件损坏。驱动 DLL 的导出函数不对，加载再成功也没用。

6.2 检查 DLL 位数和版本，靠工具而不是靠猜

网络上下载的 libmysql.dll 五花八门，光看文件名完全判断不了位数。可以用一个简单的办法验证：用文本编辑器打开 DLL，在头部 PE 标志位置看 64 还是 32。更简单的做法是在命令行用 PowerShell 读取 PE 头，或者直接用 Process Explorer 加载后看位数。每条项目里养成验收习惯：拿到 DLL 先确认位数，再投入使用。

版本信息也可以从 DLL 文件属性页里看“产品版本”，这能帮你识别是不是从 MySQL 8.0 复制过来的。MySQL 8.0 的 libmysql.dll 在协议上仍然向下兼容，但有一些默认行为变了，比如认证插件缓存方式不同，dbxopenmysql50 老版本不一定适配。如果有条件，最好直接用 MySQL 5.7 安装目录自带的文件，而不是去 8.0 里捡现成的。

6.3 用连接日志验证 mysql5.7 的握手过程

TSQLMonitor 只能看到驱动层发出的 SQL，看不到底层协议的握手日志。真要验证到握手这层，我一般用网络抓包工具，看 TCP 3306 端口的通信。数据库在本地的话，用回环抓包工具捕获连接初始握手和数据包。但这个方式太底层，日常排查中用到的不多，更多是作为“验证驱动有没有真的在跟 MySQL 5.7 说话”的依据。

另外有个轻量验证法：在 MySQL 5.7 服务端开 general log，然后把 Delphi 程序连上来跑一个查询。日志里能看到连接来源 IP、用户、数据库以及实际执行的 SQL。这条路径能确认连接确实到达了服务器，同时能看到驱动实际发过来的字符集设置。如果日志里显示连接后 MySQL 收到的初始 SET NAMES 不是 utf8mb4，就知道编辑参数时漏了什么。

6.4 给连接逻辑留诊断开关，方便远程联调部署

最后说一个长期受益的习惯：在连接配置里做一个诊断开关。比如程序读配置时，留一个ShowDLLLog=True的选项，当连接失败时直接把 Loading DLL 的状态、目录列表、错误码输出到界面或日志文件。这样客户机器上出问题时，不需要远程接管系统，只需让客户跑一次程序把日志发回来，就能定位 80% 的部署问题。

我在做这套方案的连接组件封装时，内部会维护一个简单的加载记录：尝试加载了哪个库、路径是怎么解析的、系统错误码是什么、最终加载结果如何。这个记录对小项目来说可能显得多余，但如果你同时维护多个客户端项目，它绝对是救命稻草——因为 DLL 部署问题在客户机器上发生的频率，远比你想象的高。每次发布新版本前，我都会做一次干净目录部署测试：拷贝 exe、两个 DLL 和一个 ini 文件，到一台没装过 Delphi 的虚拟机上验证连接。这个习惯坚持下来，被客户吐槽“连不上数据库”的次数就少了很多。希望帮到你。

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