企业官网建设流程全解析

简介：MySQL Data Access Components（MyDAC）v5.10 源文件包是一套面向 Delphi 和 C++Builder 开发者的数据库组件源码，主要解决从 Delphi 7 到 2007 版本环境下无缝访问 MySQL 数据库的需求。它完整覆盖数据读写、更新与删除等基本操作，也包含事务管理、批量处理、存储过程调用、异步执行以及完善的异常处理机制；由于是纯 Delphi/C++ 实现，应用发布时无需额外安装第三方中间件，便于集成到老项目中。

压缩包共有 1403 个文件，大小约 1.39 MB。文件构成以 Pascal 单元、包工程和 C++Builder 项目脚本为主，并包含表单定义、图标资源、帮助文档、历史变更与常见问题说明，以及签名和许可证文件，可覆盖查看源码、重新编译到打包安装的整个流程。目前已有 167 人学习，适合在旧版 Delphi/C++Builder 环境中维护 MySQL 项目的开发者参考。通过阅读源码，能掌握 MyDAC 的底层连接协议、事务处理方式和组件封装思路，并可按需修改组件行为；配套文档也有助于快速定位安装与使用中的常见问题。

1. MyDAC v5.10 源文件：老 Delphi 项目接 MySQL 的备用钥匙

接手一个还在用旧版 IDE 维护的业务系统，数据库却换成了新一代 MySQL，连接组件连不上、中文乱码、编译不过，这些症状聚在一起，最后都会指向同一个东西：MySQL Data Access Components (MyDAC) v5.10 的源文件。它不是什么新技术，而是一套成熟可编译的组件源码，能让你在旧 IDE 里继续用 TMyConnection、TMyQuery 完成增删改查，同时还能在源码层面修补旧版本对新协议、新字符集的兼容问题。这篇文章按落地顺序讲：源码包怎么装进 IDE、最小连接怎么写、参数怎么调、哪些地方最容易翻车、以及遇到问题怎么定位。适合正在维护 Delphi + MySQL 老项目的开发者，也适合想把组件封装成团队内部公共库的人。

2. 解压与编译：从源文件到 IDE 里的组件面板

2.1 先认清源码包里的关键内容

MyDAC v5.10 的源文件包解压后，目录结构并不复杂。常见结构是：Source 目录放组件单元源码和窗体文件，Demos 目录放可运行的示例工程，Docs 目录放文档，Scripts 或 Install 相关目录放安装脚本。对我这种习惯直接翻源码的人来说，Source 目录才是核心，MyAccess.pas、MyConnect.pas、MyClasses.pas 这些大单元分别承载连接管理、数据访问基类和工具类，组件的公开属性、方法几乎都定义在这几个文件里。

这里有个选择理由，也是我推荐维护老项目的人拿源文件而不是只装发行版的原因：发行版给你的是编好的 dcu 和 bpl，出了问题改不动。v5.10 这类老组件必然面对新 MySQL 的认证和字符集兼容问题，只有源码在手才能定点改、定点重编。动手前先建一个干净的源文件基线目录，不要在原解压路径上直接编译，否则以后排查问题时分不清改了什么。

还要注意一点：源码包的磁盘路径不要带中文，路径越短越好。Delphi 编译器对长路径和中文路径的容忍度一直不高，路径过长会在后续编译时冒出一些看起来毫无关联的报错。我习惯把源码放在 D:\MyDAC5 这种位置，工程引用也统一用相对路径。

2.2 把组件装进 IDE：手动编译最稳

常见做法是运行安装脚本，但我更建议手动编译，因为 v5.10 的安装脚本对 IDE 版本很敏感，脚本一旦自动识别错版本，会装错包。手动安装的顺序是这样：先把 Source 目录加进 IDE 的 Library 搜索路径，再用 IDE 打开对应版本的运行时包（后缀 .dpk，通常是 dcl 开头或带版本描述），把工程配置切成 Release，执行编译，然后切换或直接安装设计期包。

如果你确认手里的安装脚本能识别当前 IDE，也可以走脚本方式，示意如下：

:: 示意写法：用安装脚本安装，第一个参数是源码目录，第二个是 IDE 版本号 call Install.bat D:\MyDAC5\Source 10 pause

脚本里的 IDE 版本号必须和你装的编译器版本一致，版本号不对会编译出不匹配的包。手动打开 dpk 编译时，如果 IDE 弹出“找不到某某单元”，优先检查 Library 路径而不是改代码。安装成功的标志很直观：IDE 组件面板出现 MyDAC 页签，拖出 TMyConnection、TMyQuery、TMyScript 能正常放到窗体上。

这里补一句打包常识：设计期包负责把组件注册到 IDE 面板，运行期包才是程序运行时链接的代码。以 dcl 开头的通常是设计期包，没有 dcl 前缀的是运行期包。两者都需要编译，但只有设计期包需要“Install”。顺序错了会出现设计期包引不到运行期包的怪问题。

2.3 编译失败时先查三个地方

编译失败的情况里，大多数不是源码问题，是环境问题。第一条先查 Library 路径：报错找不到 MyClasses.dcu 这类问题，基本都是 Source 目录没加进搜索路径。第二条查条件编译符号：v5.10 要兼容多个编译版本，单元里用条件编译区分 API，某些版本的 VCL 方法不存在时，需要手工定义对应的编译符号，某次我帮 A 同学排查时遇到的就是 IDE 过老，官方预处理分支没覆盖到。第三条查包依赖顺序：设计期包依赖运行期包，必须先把运行期包编译安装，再编译设计期包，顺序反了会出现“无法解析包”的错误。

如果你手里的是老 IDE，不要指望 v5.10 源码能无痛喂给最新版编译器，老 IDE 配老组件通常最顺。编译通过后，建议立刻把整个 Source 目录连同 dcu 一起打包保存，作为这一版 IDE 的基线产物。以后再改源码，都从这份基线复制出去改，避免源码污染。

3. 最小可用的连接与查询代码

3.1 最小完整代码：连接、查询、释放

组件装好之后，第一件事是跑通最小连接。下面这段代码覆盖了连接、查询、释放三个环节，我一般拿它做环境验证：

var MyConn: TMyConnection; MyQuery: TMyQuery; begin MyConn := TMyConnection.Create(nil); try MyConn.Server := '127.0.0.1'; MyConn.Port := 3306; MyConn.Username := 'root'; MyConn.Password := 'your_password'; MyConn.Database := 'testdb'; MyConn.Charset := 'utf8'; MyConn.Connected := True; // 触发真正建立连接 MyQuery := TMyQuery.Create(nil); try MyQuery.Connection := MyConn; MyQuery.SQL.Text := 'SELECT id, name FROM users WHERE id > :MinId'; MyQuery.ParamByName('MinId').AsInteger := 0; MyQuery.Open; while not MyQuery.Eof do begin // 在这里通过 FieldByName('字段名') 取每一列的值 MyQuery.Next; end; finally MyQuery.Free; end; finally MyConn.Connected := False; // 先断开连接，再释放对象 MyConn.Free; end; end;

这段代码的逻辑顺序是有讲究的。连接参数必须在 Connected := True 之前全部赋值，因为一旦 Connected 置真，组件就会立刻发起 TCP 握手，后续再改 Server、Port 不会触发重连。查询对象通过 Connection 属性挂到连接上，不需要自己再去打开连接。ParamByName 是参数化赋值，比字符串拼接 SQL 安全，也避免中文和引号转义的麻烦。

释放顺序同样不能乱：先释放 Query，再断开 Connection，最后释放连接对象。如果先断开连接再释放 Query，某些版本在 Query 析构时会去访问已断开的连接，虽然多数情况下不崩溃，但会留下内存访问隐患。

3.2 从 TMyConnection 到 TMyQuery：组件连线与常见误用

一个 TMyConnection 可以挂多个 TMyQuery，这是最常见的用法。实际项目中我习惯把连接对象放在数据模块里，查询对象放在窗体或业务类里，运行时统一指定 Connection 指向。这样数据库地址、账号、密码只需要在数据模块里配一次，不用每个查询重复填。

常见误用有三种。第一种是每次查询都新建连接，查完就释放，CPU 和端口开销都很大，高并发时会把数据库连接数打满。第二种是连接还没打开，就先给 Query 的 SQL 和参数赋值，等循环里再 Open，这时如果中间有人改过 Connection 的 Database，参数会绑定到错误的库对象上。第三种是直接拼 SQL 字符串处理用户输入，遇到单引号就翻车。

参数化写法在 MyDAC 里是这样的：SQL 里用冒号加参数名占位，参数通过 ParamByName 赋值。注意 v5.10 对参数类型推断能力弱，字符串参数尽量显式指定 AsString，数字参数用 AsInteger 或 AsFloat，避免 MySQL 端把参数当未知类型处理。

3.3 快速验证：命令行连接与组件连接的结果对比

代码连不上时，别急着改代码，先用命令行客户端试一次：

mysql -h 127.0.0.1 -P 3306 -u root -p

命令行能连、组件不能连，问题大概率在组件侧，优先查 libmysql.dll 和认证插件；两个都不能连，问题在网络层或服务端，检查端口、防火墙和账号权限。组件能连、命令行不能连的情况比较少见，通常是账号的 host 白名单没有包含当前命令行主机的来源地址。

这个对比方法能快速切分责任范围，省去大量盲试。我在现场排查时，第一步永远是命令行先连一次，确认服务器本身没毛病，再回头检查组件配置。

4. 连接参数与字符集：性能与中文乱码的关键

4.1 连接参数：一张表讲清默认值与影响

MyDAC 连接组件的核心参数不算多，但每个都影响行为。下面是我每次配置都会过一遍的表：

其中最容易忽略的是 Direct。Direct=False 时，组件通过 libmysql.dll 与 MySQL 通信，兼容性好，但发布程序时必须带上对应版本的 DLL；Direct=True 时，组件用自己的协议实现直连，不需要 DLL，适合开发机快速验证，但老版本对新一代 MySQL 的默认认证插件支持不完整。我一般开发时开 Direct 图省事，发布前切回 False 并带上 DLL 做完整验证。

4.2 连接池：开启条件与生命周期

高并发场景下，连接池是必调项。MyDAC 里开启方式很简单：

MyConn.Pooling := True; MyConn.ConnectTimeout := 5;

注意，Pooling 开启后，调用 Close 不是真正断开连接，而是把连接放回池里。池以连接参数组合为键，只有 Server、Port、Database、Username、Password 完全一致的连接才能复用。所以不要在池连接里保存会话变量或临时表状态，下一次拿到这条连接时，状态可能不是你期望的。

连接池的生命周期由组件本身管理，程序退出时必须把 Pooling 关掉或把连接显式断开，否则服务端会出现一堆半开连接。另外，连接池只在连接频繁建立和释放的场景下有意义，如果你一个进程只有一两个连接且长期存活，开不开池差别不大。

如果你拿到的 v5.10 小版本里找不到 Pooling 属性，说明这个版本还没做池化，就用长连接复用代替。

4.3 字符集与编码：中文乱码从哪来

中文乱码绕不开一个原则：客户端字符集、连接字符集、表字段字符集三层必须一致。MyDAC 里靠 Charset 控制客户端这一层，先查服务端实际配置：

SHOW VARIABLES LIKE 'character_set%'; SHOW CREATE TABLE users;

再看具体数据是不是真的错了，用 HEX 判断：

SELECT HEX(name) FROM users WHERE id = 1;

正常的中文 UTF-8 编码会以 E4、E5、E6 等十六进制开头，如果看到 3F（问号）或乱码字节，说明写入时字符集就错了。解决方式分两步，先把客户端 Charset 设置成与表一致的编码，再把表中已有错误数据修复。代码里只需要一行：

MyConn.Charset := 'utf8';

这里注意一个老版本边界：v5.10 的字符集映射表可能不认识 utf8mb4，如果你设置 Charset 为 utf8mb4 后连接报错 Unknown character set，就把服务端默认字符集统一为 utf8，表结构里用 utf8mb4 保存四字节字符。这是老组件与新数据库之间最常见的冲突点。

5. 避坑实录：v5.10 连接新 MySQL 的五个翻车现场与解法

这五条是按出现频率和破坏力排的，每一条都是维护场景里真实踩过的坑，统一按现象、原因、解决的顺序讲清楚。

5.1 连不上：Authentication plugin 报错

现象：连接 MySQL 8 时直接失败，错误信息里有 caching_sha2_password cannot be loaded。

原因：MySQL 8 默认认证插件是 caching_sha2_password，而 v5.10 自带的协议或 libmysql.dll 不认识它。组件握手时拿不到服务端预期的认证方式，连接自然断掉。

解决：把该账号的认证方式临时改回 mysql_native_password，适合测试环境快速打通：

ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '改成现场新口令'; FLUSH PRIVILEGES;

这个方案只解决连接问题，生产环境不建议把服务器降级迁就老组件，更稳妥的方向是升级组件版本或换新版客户端库。

5.2 发布机报错：找不到 libmysql.dll

现象：开发机上程序运行正常，拷到新机器后双击启动，弹窗提示无法加载 libmysql.dll 或找不到指定模块。

原因：程序用了 Direct=False 模式，但发布目录里没带客户端库；或者带了 DLL，但 DLL 位数与 exe 位数不一致。

解决：把与 exe 位数一致的 libmysql.dll 放到 exe 同目录，重新部署。如果你希望减少这类部署依赖，把连接组件的 Direct 属性设为 True，程序就不依赖这个 DLL 了，但要先验证当前 MySQL 版本和认证方式能被组件直连协议支持。

5.3 中文写入后变成问号

现象：英文数据一切正常，中文写入数据库后变成 ?，或者读出来乱码。

原因：三层字符集不一致。最常见的是 MyDAC 的 Charset 没设置，默认 latin1 把 UTF-8 字节流按单字节处理；另一种是表字段是 utf8mb4，连接却是 utf8。

解决：先把连接 Charset 改成 utf8，再确认表的 charset 与连接一致，最后用 HEX 函数验证修复结果。记住排查顺序：先服务端、再连接、最后看应用代码，不要一上来就改程序。

5.4 安装包后 IDE 启动失败或组件页签消失

现象：组件包安装时没有报错，但重启 IDE 后启动失败，或者组件面板里找不到 MyDAC 页签。

原因：安装的包与 IDE 位数不匹配，或者同一个组件装了两个不同版本的包，IDE 加载时发生冲突。

解决：先卸载已安装的包，清掉 IDE 缓存里对应的 bpl 注册项，再按当前 IDE 的位数重新编译安装。v5.10 时代的包大多是 32 位，如果你的 IDE 是 64 位且源码包里没有对应版本的设计期包，就不要强行安装，改用 32 位 IDE 或升级组件。

5.5 源码编译通过但运行行为怪异：旧 DCU 残留

现象：源码明明改了，重新编译也成功，但运行时行为还是老样子，像没改过一样。

原因：Source 目录里残留了旧编译产物 dcu，编译器发现 dcu 存在就直接链接了，根本没重新编译这个单元。

解决：清理残留再重编。Windows 下可以先删掉所有旧产物：

del /s /q D:\MyDAC5\Source\*.dcu

然后重新编译运行期包和设计期包。更稳妥的做法是把“干净源码 + 已编译基线产物”整体冻结一份，后续改动都从冻结目录复制出去做，从流程上杜绝残留。

6. 调试技巧：让 MyDAC 的黑匣子摊开给你看

6.1 给查询统一加一层执行日志

MyDAC 组件本身有事件可以用，但现场排查时我更习惯在业务层包一个薄封装，这样每条 SQL 的执行时间和语句内容都能落到日志文件：

procedure TMyDBHelper.ExecSQL(const ASQL: string); var StartTick: Cardinal; begin StartTick := GetTickCount; FQuery.SQL.Text := ASQL; FQuery.ExecSQL; LogToFile(Format('[%dms] %s', [GetTickCount - StartTick, ASQL])); end;

这段代码的思路很直接：执行前记录时间点，执行后把耗时和 SQL 一起写入日志。慢查询、卡死、报错前最后一条 SQL，都能从这里快速定位。如果组件版本支持 Trace 事件，也值得挂上，能看到连接握手和数据包收发过程，日志里会多出底层协议层的信息，适合判断问题是在连接层还是 SQL 层。

6.2 用错误码快速分段

只记日志还不够，我会把 MySQL 错误码也写进日志。下面几个错误码最常用：

错误码能把问题直接切到具体层，省去反复试配置的时间。我现在拿到这类源文件，第一件事不是拖组件，而是先把源文件目录、IDE 版本、字符集配置写进项目备忘，再编译一份基线包存好，之后所有改动都在这份基线上做。老项目不可怕，可怕的是把组件当黑匣子。希望帮到你。

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