简介：本资源是Delphi与C++Builder开发者专用的MySQL数据库直连组件MyDAC v5.10源码包，面向使用Delphi 7–2007及C++Builder开发MySQL应用的中高级开发者，解决原生数据库连接性能低、依赖中间件、缺乏事务与存储过程深度支持等痛点。压缩包共1403个文件，涵盖360个Pascal单元（pas）、146个包工程（dpk/dproj）、107个窗体描述（dfm）、81个BDS项目配置（bdsproj）及配套帮助文件（hlp/cnt/html）、许可协议（rtf）与构建脚本（bat），总大小仅1.39MB，轻量但功能完备。已有167人下载学习，适合需定制化适配、二次开发或深入理解MyDAC底层通信机制的开发者。用户可直接编译运行示例工程，快速掌握事务处理、异步操作、触发器调用等核心能力，并基于源码优化连接池、扩展MySQL 5.x特性支持，真正实现零第三方依赖的纯原生数据库集成方案。

1. MyDAC v5.10 源文件不是“安装包”，而是 Delphi 开发者手里的数据库连接黑匣子钥匙

你搜到 “MyDAC v5.10 源文件”，大概率正卡在这样一个现实场景里：接手一个老 Delphi 项目，编译时报错Cannot find unit 'MyConnection'或Fatal Error: Cannot open file 'MyDataSet.pas'；或者想把旧系统从 MySQL 5.6 升级到 8.0，但原厂只给了个.bpl插件包，没源码、没文档、一改就崩；又或者你在 GitHub 上翻遍了所有叫 MyDAC 的仓库，发现全是 v9.x+ 的新版本，而你手里这份 v5.10 的 ZIP 包解压后只有.pas、.dfm、.dpk文件——它既不是 Windows 安装程序，也不是 Linux RPM，更不是 Docker 镜像。它是一套专为 Delphi/C++Builder 设计的原生 MySQL 数据访问组件源代码集合，核心价值在于：你能看见每一行 SQL 如何被封装进 TMyQuery、TMyConnection 的 VCL 层，能亲手修改字符集协商逻辑、重写 SSL 握手失败时的 fallback 策略、甚至把mysql_real_connect()的调用栈打出来看参数到底传了什么。这不是给 DBA 用的运维工具，而是给 Delphi 工程师用的“可调试、可定制、可降级兼容”的底层数据通道。如果你正在维护金融、医疗或工业控制类的老 Delphi 系统，且数据库层必须死守 MySQL 协议（而非用 ODBC 这种中间层），那么 v5.10 源文件就是你唯一能真正掌控连接行为的入口——尤其当官方早已停止对它的二进制更新，而你的客户服务器上跑着 MySQL 5.7.44 或 8.0.33 时。

2. 解压即用？不，v5.10 源文件需要三步“唤醒”：环境校准、包注册、单元引用链重建

MyDAC v5.10 不是双击安装的软件，它是一组 Delphi 源码文件，其“运行”本质是让 IDE 认出这些.pas是合法单元，并让编译器能把它们链接进你的.exe。这过程远比make install复杂，因为涉及 Delphi 版本兼容性、RTL 版本对齐、以及最关键的——BPL 包依赖树的显式声明。v5.10 发布于 2012 年左右，原生支持 Delphi 2007–2010，但实测在 Delphi 10.4 Sydney 和 11 Alexandria 上也能工作，前提是手动绕过几个 RTL 变更点。下面三步是唤醒它的最小可行路径，跳过任意一步都会导致“找不到单元”或“Linker Error: Unresolved external”。

2.1 环境校准：确认 Delphi 版本与 RTL 兼容边界

v5.10 的源码大量使用AnsiString、PAnsiChar和{$IFDEF UNICODE}条件编译，但它不支持 Delphi XE2 及之后默认开启的 Unicode RTL。直接在 Delphi 10.4 中打开.dpk会报Undeclared identifier: 'AnsiString'。解决方法不是升级 MyDAC，而是降级 RTL 兼容性：

// 在你的项目 .dpr 文件顶部，紧贴 program 声明下方插入： {$IFDEF VER230} // Delphi XE2 的 RTL 版本号 {$DEFINE DELPHI_XE2_OR_LATER} {$ENDIF} {$IFDEF DELPHI_XE2_OR_LATER} {$UNDEF UNICODE} {$IFDEF WIN32} {$DEFINE ANSISTRING_SUPPORTED} {$ENDIF} {$ENDIF}

提示：VER230是 Delphi XE2 的编译器版本常量，XE3 是VER240，10.4 是VER320。v5.10 能跑通的最高 Delphi 版本是 10.4，但必须关闭 Unicode RTL。不要尝试在 11 Alexandria（VER340）上硬扛——RawByteString和UTF8String的语义已彻底改变，强行编译会导致运行时内存越界。

2.2 包注册：用 .dpk 编译 BPL，而非直接引用 .pas

v5.10 提供多个.dpk文件（如MyDacD14.dpk对应 Delphi 2010），但它们不是拿来双击安装的。正确流程是：

1. 打开 Delphi IDE →Component → Install Packages…
2. 点击Add…→ 导航到解压目录下的Source\D14\MyDacD14.dpk（D14 表示 Delphi 2010）
3. 勾选"Install into IDE"→ 点击 OK
4. IDE 会自动编译该.dpk，生成MyDacD14.bpl和MyDacD14.dcp

关键点在于：.dpk中的requires列表必须与你的 Delphi 版本匹配。例如MyDacD14.dpk的 requires 是：

requires rtl, vcl, vclx, dbrtl, adortl, dsnap;

如果你用的是 Delphi 10.4，vclx和dsnap已被移除，必须手动删掉这两行，否则编译失败。删掉后requires应为：

requires rtl, vcl, dbrtl, adortl;

参数说明：rtl是运行时库，vcl是可视化组件库，dbrtl是数据库运行时，adortl是 ADO 支持库（MyDAC 内部用它做部分元数据操作）。少一个，IDE 就无法加载设计时组件；多一个不存在的包，编译器直接报错。

2.3 单元引用链重建：从 uses 到 Search Path 的全链路打通

即使 BPL 安装成功，你的 Form 单元仍可能报Cannot find unit 'MyConnection'。这是因为 Delphi 的单元查找顺序是：

1. 当前工程目录
2. Search Path（项目选项中设置）
3. BPL 的 DCU 目录（仅限设计时）
4. RTL/VCL 源码目录

v5.10 的.pas文件默认放在Source\D14\下，而.dpk编译时并不会自动把该路径加进 Search Path。必须手动配置：

• 右键项目 →Options → Delphi Compiler → Search Path
• 在Unit Search Path中添加：

  $(MYDAC_ROOT)\Source\D14;$(MYDAC_ROOT)\Source\Common;$(MYDAC_ROOT)\Source\Win32

  （$(MYDAC_ROOT)是你解压 MyDAC 的根目录，如C:\MyDAC_v510）

然后，在你的主窗体.pas文件中，uses子句必须显式列出 MyDAC 单元，且顺序不能错：

uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, // ↓ MyDAC 单元必须放在 VCL 单元之后，且按依赖顺序排列 ↓ MyClasses, // 基础工具类，所有 MyDAC 单元都依赖它 MyConst, // 常量定义 MyTypes, // 类型定义 MyConnection, // 核心连接类 MyDataSet, // 数据集类 MyQuery; // 查询类

逻辑说明：MyClasses定义了TMyCustomDataSet等基类，MyConnection继承自它，MyDataSet又继承自MyConnection。如果MyDataSet写在MyClasses前面，编译器根本不知道TMyCustomDataSet是什么类型，直接报错。这个顺序不是约定俗成，而是源码中interface uses的硬依赖关系决定的。

3. 编译通过 ≠ 运行正常：v5.10 连接 MySQL 5.7+/8.0 的三大握手陷阱

MyDAC v5.10 的源码里，MySQL 协议握手逻辑固化在MyConnection.pas的TMyConnection.ConnectToServer方法中。它默认按 MySQL 4.1 协议实现，而 MySQL 5.7 默认启用caching_sha2_password插件，8.0 更是强制要求 TLS 1.2+。这就导致：编译成功、BPL 加载成功、TMyConnection创建成功，但一调Open就卡死或报Access denied for user。这不是密码错了，而是协议层根本没谈拢。以下是三个必须手动修补的握手陷阱，每一条都来自真实客户的生产环境翻车记录。

3.1 密码加密算法不匹配：从mysql_native_password到caching_sha2_password的降级开关

MySQL 5.7.21+ 新建用户默认用caching_sha2_password，而 v5.10 只认识mysql_native_password。现象是：连接字符串写对了，用户名密码也对，但TMyConnection.Open抛出异常Authentication plugin 'caching_sha2_password' cannot be loaded。原因在于 v5.10 的MyConnection.pas第 2187 行：

if (ServerVersion >= '4.1.1') and (Length(Scramble) = 20) then Result := CalcPassword(Password, Scramble) else Result := OldCalcPassword(Password, Scramble);

这段代码只处理mysql_native_password的 scramble（20 字节），对caching_sha2_password的 12 字节 scramble 直接返回空密码。解决方法不是重写 SHA256 逻辑（v5.10 没这能力），而是强制服务端用老插件：

-- 在 MySQL 服务器上执行（需 root 权限） ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES;

参数说明：IDENTIFIED WITH mysql_native_password显式指定认证插件，FLUSH PRIVILEGES立即生效。不要用SET PASSWORD，它在 5.7.6+ 后已被弃用。

3.2 SSL 握手失败：禁用 TLS 或注入自签名证书路径

MySQL 8.0 默认require_secure_transport=ON，v5.10 的TMyConnection.SSL属性却只支持 OpenSSL 0.9.8，而现代系统装的都是 OpenSSL 1.1.1+。现象是：连接超时，Wireshark 抓包显示 Client Hello 后无 Server Hello。原因在于MyConnection.pas的InitSSL方法调用SSL_library_init()时，新版 OpenSSL 返回SSL_ERROR_SSL。最稳方案是关闭 SSL（测试环境）或指定证书路径（生产环境）：

// 在 TMyConnection.OnConnect 事件中（或 Open 前） MyConnection.SSL := True; MyConnection.SSLMode := smRequired; MyConnection.SSLCAFile := 'C:\certs\ca.pem'; // CA 证书路径 MyConnection.SSLCertFile := 'C:\certs\client.pem'; // 客户端证书 MyConnection.SSLKeyFile := 'C:\certs\client.key'; // 客户端私钥

注意：SSLCAFile必须是 PEM 格式，且ca.pem里不能包含多余空行或 UTF-8 BOM。v5.10 的 SSL 加载器会因 BOM 报SSL_CTX_use_certificate_chain_file failed。

3.3 字符集协商崩溃：UTF8MB4 与 UTF8 的字节长度误判

MySQL 5.5.3+ 默认字符集是utf8mb4，而 v5.10 的MyConnection.pas在GetServerCharset方法中硬编码了utf8的字节长度为 3：

case CharsetID of 33: Result := 'utf8'; // MySQL 的 utf8 字符集 ID 是 33 255: Result := 'utf8mb4'; // utf8mb4 的 ID 是 255，但 v5.10 没处理！ else Result := 'latin1'; end;

结果是：当服务器返回 charset ID 255 时，Result被设为'latin1'，后续所有AnsiString转换都乱码。补丁只需两行：

case CharsetID of 33: Result := 'utf8'; 255: Result := 'utf8mb4'; // ← 新增这一行 else Result := 'latin1'; end;

血泪经验：这个 bug 导致某银行客户报表导出中文全是问号，排查三天才发现是字符集 ID 映射表漏了。v5.10 源码里所有CharsetID判断都要扫一遍，MyDataSet.pas的GetFieldData方法里也有同样问题。

4. 避坑：v5.10 源文件开发中 5 个高频翻车点及现场急救指南

MyDAC v5.10 的源码不是“开箱即用”，它是把 Delphi 工程师扔进 MySQL 协议深水区的救生圈——但救生圈本身有破洞。以下 5 条是我在 7 个遗留系统迁移项目中亲手填过的坑，每一条都附带现象、根因和一行救命命令/代码。

4.1 现象：编译通过，运行时报Access violation at address XXXX in module 'MyDacD14.bpl'

原因：v5.10 的MyDataSet.pas中TMyDataSet.InternalSetFieldData方法未检查Field.DataSize是否为 0，当字段为TEXT类型且值为空时，Move函数 memcpy 0 字节地址导致 AV。
解决：在InternalSetFieldData方法开头加防护：

if (Field.DataSize = 0) or (Value = nil) then Exit;

4.2 现象：TMyQuery.Open成功，但RecordCount返回 -1，First/Last无效

原因：MySQL 5.7+ 默认sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'，v5.10 的TMyQuery.GetRecordCount调用SELECT FOUND_ROWS()前未执行SELECT SQL_CALC_FOUND_ROWS * FROM ...，FOUND_ROWS() 返回 0。
解决：不用RecordCount，改用TMyQuery.RecordCount := TMyQuery.RecordCount（触发缓存）或手动执行：

MyQuery.Close; MyQuery.SQL.Text := 'SELECT SQL_CALC_FOUND_ROWS * FROM your_table'; MyQuery.Open; MyQuery.SQL.Text := 'SELECT FOUND_ROWS()'; MyQuery.Open; ShowMessage(MyQuery.Fields[0].AsString); // 实际行数

4.3 现象：TMyConnection连接池复用时，第二个连接报Commands out of sync

原因：v5.10 的连接池TMyConnectionPool未重置mysql_thread_safe状态，多线程下mysql_real_query调用顺序错乱。
解决：禁用连接池，改用单连接 +TMyConnection.Clone：

var NewConn: TMyConnection; NewConn := MyConnection.Clone as TMyConnection; NewConn.Open;

4.4 现象：TMyDataSet.Locate在utf8mb4字段上永远返回 False

原因：MyDataSet.pas的CompareStrings方法用AnsiCompareStr比较 UTF8 字节流，但utf8mb4的四字节字符（如 emoji）被截断为三字节，比较必然失败。
解决：强制转为 Unicode 比较：

function CompareStrings(const S1, S2: string): Integer; begin Result := CompareText(S1, S2); // ← 用 CompareText 替代 AnsiCompareStr end;

4.5 现象：TMyQuery执行含中文的INSERT语句，数据库里存成????

原因：v5.10 的TMyQuery.Prepare方法未在mysql_stmt_prepare前调用mysql_set_character_set，预编译语句默认用 latin1。
解决：在TMyQuery.BeforeOpen事件中手动设字符集：

MyQuery.Connection.SetCharset('utf8mb4');

提示：SetCharset是TMyConnection的公开方法，调用它会执行mysql_set_character_set(conn, 'utf8mb4')，确保后续所有语句（包括预编译）都用正确字符集。

5. 源码级调试实战：用 v5.10 源文件定位 MySQL 连接超时的真实根源

当你面对一个“连接偶尔超时、重启服务就恢复”的玄学问题时，官方文档只会告诉你“调大wait_timeout”，但真实瓶颈往往藏在 MyDAC 的 socket 层。v5.10 源文件的价值，就在于让你能亲手把MyConnection.pas的ConnectToServer方法变成一个实时监控探针。下面这个技巧，我已在三个客户现场用它揪出 DNS 解析延迟、防火墙 ICMP 丢包、以及 MySQL 服务器max_connections耗尽的真实原因。

5.1 在ConnectToServer中注入毫秒级时间戳日志

打开MyConnection.pas，找到TMyConnection.ConnectToServer方法。在mysql_real_connect调用前后，插入高精度计时：

uses Winapi.Windows; // ← 确保 uses 里有这个 function GetTickCount64: Int64; external 'kernel32.dll'; procedure TMyConnection.ConnectToServer; var StartTick, EndTick: Int64; begin StartTick := GetTickCount64; // 原有的 mysql_real_connect 调用保持不变 FHandle := mysql_real_connect(FHandle, PAnsiChar(Host), PAnsiChar(UserName), PAnsiChar(Password), PAnsiChar(Database), Port, PAnsiChar(Socket), ClientFlag); EndTick := GetTickCount64; // 记录日志（用 OutputDebugString 便于 Sysinternals DbgView 捕获） if (EndTick - StartTick) > 3000 then // 超过 3 秒记为慢连接 begin OutputDebugString(PAnsiChar(Format('MyDAC Connect Slow: %d ms, Host=%s, User=%s', [EndTick - StartTick, Host, UserName]))); end; end;

逻辑说明：GetTickCount64返回毫秒级时间戳，比Now或GetTickCount更准。OutputDebugString不写文件、不占磁盘，所有 Windows 调试器（包括 DbgView）都能实时捕获。这样你就能看到：是mysql_real_connect调用本身卡住（网络层问题），还是它返回后FHandle初始化卡住（MyDAC 内部逻辑问题）。

5.2 关键参数表：v5.10 连接超时链路上的 4 个可调阀门

5.3 用 Wireshark 验证：抓包看三次握手与 SSL Client Hello

光有日志不够，必须验证是哪一层出问题。启动 Wireshark，过滤ip.addr == your.mysql.server.ip and tcp.port == 3306，然后触发一次TMyConnection.Open：

• 如果只有 SYN 包发出，无 SYN-ACK 返回→ DNS 解析失败或路由不通（检查ping your.mysql.server.ip）
• 如果有 SYN-ACK，但无后续 ACK→ 防火墙拦截（检查telnet your.mysql.server.ip 3306是否通）
• 如果有完整 TCP 握手，但无 MySQL Protocol 包→mysql_real_connect调用失败（查 MyDAC 日志中的Connect Slow时间）
• 如果有 MySQL Protocol 包，但卡在Client Hello后→ SSL 版本不匹配（v5.10 只支持 TLS 1.0，MySQL 8.0 默认 TLS 1.2）

我的习惯：每次客户报“连接不稳定”，我第一件事就是用 DbgView 挂着看MyDAC Connect Slow日志，第二件事是 Wireshark 抓包对比。90% 的问题，要么是ConnectTimeout设太小（误报超时），要么是wait_timeout<MaxIdleTime（连接池取到废连接）。v5.10 源文件给我的不是“修 bug 的能力”，而是“把黑匣子变成透明管道”的底气——我不再靠猜，而是靠证据说话。希望帮到你。

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