基于YOLOv12的农业AI视觉杂草检测系统实践
2026/10/27 3:02:14
简介：本资源是一套面向Delphi中高级开发者的技术实践包，聚焦于绕过OLE DB、直接调用MySQL原生客户端库（mysql.dll）实现数据库连接与操作的核心方案。适用于需提升数据库访问性能、定制化封装或适配轻量级部署场景的Windows平台Delphi项目开发。压缩包共53个文件，含32个HTML字符集说明页（覆盖cp1251、latin1、koi8r等20余种编码）、6个PAS单元文件（含关键mysql.pas接口封装与线程安全封装UThread.pas）、4个DPR主程序（分别适配经典Demo、2009版及Stmt/Thread专项示例），以及配套DFM界面、RES资源和INC平台定义文件，整体仅87KB，结构紧凑、即取即用。已有432人学习下载，读者可直接获得多版本兼容的Delphi+MySQL直连完整工程、字符集处理范例、预编译语句与多线程安全调用实操代码，以及清晰的readme集成指引与MySQL官方许可说明。
1. Delphi 直连 MySQL：绕过 OLE DB 的 .dll 方案，为什么老项目还在用它？
某高校实验室维护一套运行了 12 年的设备监控系统，Delphi 7 编写，后端数据库从 Access 迁移到 MySQL 5.7。迁移时发现：用 ADO + OLE DB 驱动连接 MySQL，频繁出现“字段类型不匹配”“大文本截断”“中文乱码无法恢复”三连翻车；换成 dbExpress 又卡在 Linux 服务器部署时的.so 兼容性上。最后他们退回一个被很多人忽略的路径——直接调用libmysql.dll封装的原生 C API，自己写 thin wrapper。这不是复古情怀，而是实测下来唯一能稳定支撑 200+ 并发写入、毫秒级响应、且不依赖 Windows 系统组件的方案。它适合你吗？如果你正面对 Delphi 5–10.4、MySQL 5.1–8.0、要求零外部注册表依赖、拒绝 COM/OLE 层抽象开销、又不想重写整套数据访问层——那这份基于mysql.dll的直连方案，就是你该拆开看的黑匣子。它不时髦，但够硬；不自动，但可控。
2. 原理与选型：为什么是 libmysql.dll，而不是 dbExpress、Zeos 或 UniDAC？
2.1 Delphi 数据访问栈的三层现实分野
Delphi 的数据库连接能力常被误认为“只有 ADO/dbExpress 两种”。实际工程中存在明确的三层分野：
- 高层抽象层（ADO、FireDAC、UniDAC）：封装完整，开箱即用，但引入 COM、BDE 兼容层或私有协议栈，对 MySQL 特性支持滞后（如 JSON 字段、空间索引、认证插件
caching_sha2_password）； - 中间适配层（dbExpress、ZeosDBO）：跨平台好，但 dbExpress 的
dbxmys32.dll在 Delphi 10.2+ 后默认禁用 SSL，Zeos 则需手动编译不同 MySQL 版本的.so/.dylib； - 底层原生层（
libmysql.dll/libmysqlclient.so）：无封装损耗，完全控制连接生命周期、字符集协商、错误码映射、内存分配策略，但需自行处理线程安全、连接池、SQL 注入防护等“轮子”。
提示：本方案选择第三层，不是因为“更高级”，而是因为——当你的 Delphi 应用必须跑在 Windows Server 2003（无 .NET Framework）、或嵌入式工控机（无管理员权限安装 OLE 组件）、或需要精确控制
wait_timeout触发时的重连逻辑——只有直调mysql_real_connect()才能拿到那个返回值。
2.2 libmysql.dll 的版本兼容性血泪经验
MySQL 官方自 5.7 起停止发布 Windows 二进制libmysql.dll，但社区仍维护着三个关键分支：
| DLL 来源 | 支持 MySQL 版本 | Delphi 兼容性 | 关键限制 |
|---|---|---|---|
MySQL 5.1 官方libmySQL.dll | ≤ 5.1 | Delphi 5–2007 | 不支持utf8mb4，mysql_set_character_set()无效 |
MariaDB 10.3libmariadb.dll | MariaDB 10.2+ / MySQL 5.5+ | Delphi 7–11 | 默认启用PIPE协议，Windows 下需显式关闭 |
| MySQL Connector/C 6.1.11 | MySQL 5.6–5.7 | Delphi 2009+ | mysql_options()不支持MYSQL_OPT_SSL_MODE，SSL 必须用mysql_ssl_set() |
我一般会强制选用MariaDB 10.3 的libmariadb.dll：它向后兼容 MySQL 协议，提供mysql_optionsv()支持可变参数，且mysql_ping()返回值修复了旧版“假死连接不报错”的玄学问题。下载地址统一走 MariaDB 官网的mariadb-connector-c-3.1.11-winx64.zip，解压后取bin/libmariadb.dll——别用libmariadb.dll同目录下的libmariadb.dll.lib，Delphi 不认这种 MSVC 导入库。
2.3 Delphi 端的最小可行封装结构
不推荐全量翻译mysql.h（共 1200+ 行宏定义）。我们只封装 7 个核心函数，构成闭环：
type PMYSQL = Pointer; PMYSQL_RES = Pointer; PMYSQL_ROW = ^PAnsiChar; function mysql_init(mysql: PMYSQL): PMYSQL; stdcall; external 'libmariadb.dll' name 'mysql_init'; function mysql_real_connect(mysql: PMYSQL; host, user, passwd, db: PAnsiChar; port: Word; unix_socket: PAnsiChar; clientflag: LongWord): PMYSQL; stdcall; external 'libmariadb.dll' name 'mysql_real_connect'; function mysql_query(mysql: PMYSQL; query: PAnsiChar): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_query'; function mysql_store_result(mysql: PMYSQL): PMYSQL_RES; stdcall; external 'libmariadb.dll' name 'mysql_store_result'; function mysql_fetch_row(result: PMYSQL_RES): PMYSQL_ROW; stdcall; external 'libmariadb.dll' name 'mysql_fetch_row'; function mysql_num_fields(result: PMYSQL_RES): Word; stdcall; external 'libmariadb.dll' name 'mysql_num_fields'; function mysql_free_result(result: PMYSQL_RES): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_free_result';注意：所有字符串参数必须为PAnsiChar，而非PWideChar。MySQL C API 不接受 UTF-16，Delphi 2009+ 的string默认是 Unicode，必须用AnsiString(UTF8Encode(...))转换，否则mysql_real_connect()直接返回 nil。
3. 实战：从零封装 TMySQLConnection 类，支持连接池与自动重连
3.1 连接对象的核心状态机设计
TMySQLConnection不是简单包装PMYSQL，而是一个带状态机的资源控制器：
csDisconnected：未初始化，FHandle = nil；csConnecting：调用mysql_init()后，mysql_real_connect()未返回；csConnected：连接成功，但未校验mysql_ping()；csValidated：通过mysql_ping()且mysql_get_server_info()可读；csBroken：mysql_ping()失败，进入自动重连队列。
状态切换不是靠布尔标记，而是靠FState: TConnectionState枚举 +FLastPingTime: Int64时间戳。这样当多线程并发调用ExecuteQuery()时，能避免重复重连——只有第一个线程触发csBroken → csConnecting，其余线程阻塞等待其结果。
3.2 自动重连逻辑：三次指数退避 + 连接验证
重连不是简单while not Connected do Connect。真实场景中，网络抖动可能持续 200ms，但wait_timeout默认是 28800 秒，所以重连必须带超时和退避：
function TMySQLConnection.Reconnect: Boolean; var i: Integer; BackoffMs: Integer; begin Result := False; for i := 0 to 2 do // 最多重试3次 begin if i > 0 then begin BackoffMs := Round(100 * Power(2, i)); // 100ms, 200ms, 400ms Sleep(BackoffMs); end; if InternalConnect then // 封装了 mysql_real_connect + 字符集设置 begin if mysql_ping(FHandle) = 0 then // ping 成功才认为有效 begin FState := csValidated; Result := True; Exit; end; end; end; end;关键点：InternalConnect内必须调用mysql_options(FHandle, MYSQL_SET_CHARSET_NAME, 'utf8mb4')，否则即使连接成功，SELECT @@character_set_client仍是latin1，中文插入直接变问号。
3.3 连接池实现：线程局部存储（TLS）规避锁竞争
传统连接池用TObjectList<TMySQLConnection>+TCriticalSection，但在 50+ 线程高并发下，Enter/Leave成为瓶颈。改用 Windows TLS：
const TLS_CONNECTION_INDEX: DWORD = TLS_OUT_OF_INDEXES; function GetThreadConnection: TMySQLConnection; begin Result := TMySQLConnection(TlsGetValue(TLS_CONNECTION_INDEX)); if not Assigned(Result) then begin Result := TMySQLConnection.Create; Result.Connect('127.0.0.1', 'root', 'pass', 'test'); TlsSetValue(TLS_CONNECTION_INDEX, Result); end; end;首次调用GetThreadConnection时创建专属连接，线程退出时由TMySQLConnection.Destroy自动释放。实测比全局池快 3.2 倍（TPS 从 1800→5700），且彻底消除锁等待。
4. 避坑：五个让 Delphi 开发者深夜重启 IDE 的典型问题
4.1 现象：mysql_real_connect()返回 nil，但mysql_error()为空字符串
原因：mysql_init()返回的PMYSQL指针未传入mysql_real_connect()，或传入了已释放的指针。常见于把mysql_init(nil)结果赋给局部变量，函数返回后变量销毁，FHandle指向野地址。
解决：必须用mysql_init(nil)初始化，并将返回值持久保存在类成员中。验证方法：if not Assigned(FHandle) then raise Exception.Create('mysql_init failed');
4.2 现象：执行INSERT INTO t1 (name) VALUES ('张三')后查出??
原因：未在连接后执行mysql_set_character_set(FHandle, 'utf8mb4')，或执行顺序错误（必须在mysql_real_connect()之后、任何 SQL 之前）。
解决：在InternalConnect函数末尾强制添加：
if mysql_set_character_set(FHandle, 'utf8mb4') <> 0 then raise Exception.Create(Format('Set charset utf8mb4 failed: %s', [mysql_error(FHandle)]));4.3 现象：多线程下mysql_query()随机崩溃，堆栈指向my_malloc
原因：libmariadb.dll默认使用 Windows CRT 的malloc，但 Delphi 2009+ 使用自己的内存管理器（FastMM），两者混用导致堆损坏。
解决：在程序启动时调用mysql_library_init()并传入自定义分配器（需重编译 DLL），或更简单——禁止多线程共享同一PMYSQL句柄。每个线程用独立连接，或用 TLS 池。
4.4 现象：mysql_fetch_row()返回nil，但mysql_num_rows()显示有 10 行
原因：调用了mysql_use_result()而非mysql_store_result()。前者是流式读取，mysql_fetch_row()必须连续调用直到返回 nil；后者是缓存全部结果到内存，可随机访问。
解决：一律用mysql_store_result()。若处理超大结果集（>100MB），再考虑mysql_use_result()+ 分块读取，但需手动管理网络缓冲区。
4.5 现象：程序退出时Finalize报Access Violation，堆栈在mysql_close()
原因：mysql_close()被调用两次——一次在TMySQLConnection.Destroy，另一次在mysql_library_end()。
解决：永远不要调用mysql_library_end()。MySQL C API 文档明确说明：“It is not necessary to call mysql_library_end() at the end of a program that uses MySQL client library.” Delphi 的 DLL 引用计数机制会自动卸载。
5. 进阶技巧：用预处理语句（Prepared Statement）防注入 + 批量插入提速 8 倍
5.1 为什么不用Format()拼 SQL？
某跨平台系统曾用Format('INSERT INTO log (msg) VALUES (%s)', [QuotedStr(Msg)])，结果用户输入'); DROP TABLE log; --直接清空日志表。QuotedStr仅处理单引号，对\0、\b、十六进制编码等无效。预处理语句才是 MySQL 原生防注入方案——SQL 结构与参数物理分离，服务端根本不解析参数内容。
5.2 Delphi 封装MYSQL_STMT的最小接口
type PMYSQL_STMT = Pointer; PMYSQL_BIND = Pointer; function mysql_stmt_init(mysql: PMYSQL): PMYSQL_STMT; stdcall; external 'libmariadb.dll' name 'mysql_stmt_init'; function mysql_stmt_prepare(stmt: PMYSQL_STMT; query: PAnsiChar; length: LongWord): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_stmt_prepare'; function mysql_stmt_bind_param(stmt: PMYSQL_STMT; bind: PMYSQL_BIND): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_stmt_bind_param'; function mysql_stmt_execute(stmt: PMYSQL_STMT): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_stmt_execute'; function mysql_stmt_close(stmt: PMYSQL_STMT): LongInt; stdcall; external 'libmariadb.dll' name 'mysql_stmt_close';注意：mysql_stmt_bind_param()的bind参数需按字段顺序构造TMysqlBind数组，每个元素指定buffer_type（如MYSQL_TYPE_STRING）、buffer（指向AnsiString首字节）、buffer_length（字符串长度）。
5.3 批量插入实战：一次mysql_stmt_execute()插入 1000 行
传统循环插入 1000 行耗时 2.3 秒；用预处理 + 参数绑定 +mysql_stmt_send_long_data()分块发送，降至 0.28 秒：
// 1. 准备语句 Stmt := mysql_stmt_init(FHandle); mysql_stmt_prepare(Stmt, 'INSERT INTO sensor_data (ts, value, device_id) VALUES (?, ?, ?)', 52); // 2. 绑定三个参数 FillChar(Bind, SizeOf(Bind), 0); Bind[0].buffer_type := MYSQL_TYPE_LONGLONG; // ts: int64 Bind[0].buffer := @FTime; Bind[1].buffer_type := MYSQL_TYPE_DOUBLE; // value: double Bind[1].buffer := @FValue; Bind[2].buffer_type := MYSQL_TYPE_LONG; // device_id: int32 Bind[2].buffer := @FDeviceID; mysql_stmt_bind_param(Stmt, @Bind); // 3. 循环执行（无需重准备） for i := 0 to 999 do begin FTime := NowToMySqlTimestamp(); FValue := ReadSensor(); FDeviceID := 123; mysql_stmt_execute(Stmt); // 每次只传参数，不传 SQL end;关键优化点：mysql_stmt_prepare()只执行一次，后续mysql_stmt_execute()仅传输二进制参数，网络开销降低 92%。实测在千兆内网，批量插入吞吐达 12,000 行/秒。
5.4 预处理语句的生命周期管理陷阱
MYSQL_STMT对象必须与PMYSQL句柄同生命周期。常见错误：
- 在
TMySQLConnection中声明FStmt: PMYSQL_STMT，但Destroy时只调用mysql_stmt_close(FStmt)，忘记FStmt := nil； - 下次
Prepare()时FStmt非 nil，mysql_stmt_init()返回新句柄覆盖旧值，导致内存泄漏； - 更糟的是，
mysql_stmt_close()后继续mysql_stmt_execute()，触发 AV。
我的固定写法：
procedure TMySQLConnection.Prepare(const SQL: string); begin if Assigned(FStmt) then mysql_stmt_close(FStmt); FStmt := mysql_stmt_init(FHandle); if not Assigned(FStmt) then RaiseMySQLError; if mysql_stmt_prepare(FStmt, PAnsiChar(AnsiString(UTF8Encode(SQL))), Length(AnsiString(UTF8Encode(SQL)))) <> 0 then RaiseMySQLError; end;从那以后我每次写mysql_*调用，都强制在函数入口加Assert(Assigned(FHandle))，在出口加Assert(Assigned(FStmt) or (FStmt = nil))——这行断言帮我拦截了 73% 的句柄误用问题。希望帮到你。
本文还有配套的精品资源，点击获取