简介面向MFC开发者的MySQL数据库连接示例工程解决在VC6.0下通过ODBC驱动访问MySQL、完成界面数据增删改查的实际问题适合有一定C基础、准备做桌面数据库应用的读者。压缩包共38个文件以头文件、CPP源码、DSW/DSP工程文件、OBJ/PDB调试产物、EXE运行程序、RC界面资源和ReadMe说明为主整体仅3.54MB保留了可编译运行的DatabaseTest完整工程目前已有1663人学习或下载。工程覆盖ODBC系统DSN配置、CDatabase建立连接、CRecordset执行查询与遍历结果集并展示ExecuteSQL更新数据、CDBException异常捕获及事务的BeginTrans、CommitTrans、RollbackTrans处理方式。通过源码和界面定义还能理解MFC对话框中数据库操作的调用位置与工程组织方式便于把连接逻辑、参数化查询与性能优化思路迁移到自己的项目。同时包含关闭连接释放资源、预编译语句与参数化查询等性能要点文件里也保留了当时的调试记录与可执行程序适合边跑边看。 接到一个半旧不旧的MFC程序功能本身倒不复杂但客户提了个新需求把每次检测的数据落库方便以后查询和统计。我当时的第一反应是这年头还有人新写MFC界面但需求就是需求程序老归老功能照样得往上加。真正让我纠结的不是界面改造而是MFC这个老框架到底怎么跟MySQL顺畅地连起来——网上资料不少但版本不对、配置步骤缺斤少两照着做很容易卡在半路。这篇文章就是我踩完坑之后的完整记录从选型、环境配置、核心代码到中文乱码和部署一条线走下来适合正在做MFC项目又需要接MySQL的开发者参考。1. 选型为什么我选了C API而不是ODBC或Connector/C当时摆在我面前的有三条路MFC自带的ODBC方案、MySQL官方的Connector/C、以及最原始的MySQL C API。我先把三条路都看了一遍才决定用C API。1.1 ODBC方案的隐性成本MFC里确实封装了CDatabase和CRecordset用起来像操作Access一样舒服但前提是你得在客户机器上装好MySQL ODBC驱动而且驱动的位数、版本都要跟程序对上。更要命的是ODBC驱动层封装太多一旦出现中文乱码或者类型映射不对排查路径会被拉得很长。我自己以前被ODBC的驱动版本坑过所以对这个方案天然有顾虑。如果你是在企业内部用IT环境统一ODBC可以凑合但要是做独立软件发布把驱动作为依赖项太累了。1.2 Connector/C的版本适配问题Connector/C是官方面向对象的封装概念上更现代但老MFC工程普遍是VS2010到VS2015这个区间Connector/C的版本迭代又很快ABI兼容性和标准库版本经常会有小摩擦。我见过不少人在编译阶段就被一堆模板错误劝退。另外官方Connector/C的库组织方式对老工程师不太友好头文件和库文件位置换来换去网上教程跟实际目录经常对不上。1.3 C API最笨也最可控的路最后我选了MySQL C API本质就是直接调libmysql.dll里导出的一组C函数mysql_init、mysql_real_connect、mysql_query、mysql_store_result、mysql_fetch_row统统是原生函数没有中间层。好处非常直接依赖少发布时程序目录放一个libmysql.dll就能跑出了问题可排查每一层都是自己写的代码错误信息能直接定位到API调用MFC里调用C函数没有任何历史包袱不挑编译器版本只要头文件和lib对得上就能编过。很多人觉得C API太底层、不体面但做桌面端数据库连接稳才是第一位。C API就像自己下厨菜怎么做心里有数ODBC和Connector/C虽然像半成品调料包但保质期和口味未必对得上你的锅。2. 环境准备最容易翻车的MySQL开发库与工程配置我在这阶段浪费了整整一个下午原因就一句话MySQL的安装包默认不装开发组件。如果你只是装了MySQL Server然后打开VS写代码会发现根本找不到mysql.h这个头文件。2.1 安装MySQL时一定要勾选开发组件用MySQL Installer安装时在“Choose a Setup Type”页面不能只选Server only必须选“Custom”或者“Full”然后在功能列表里找到“MySQL C Development Components”之类跟开发库相关的项把它勾上。这一步不做后面整个工程都是空中楼阁。如果你用的是免安装的ZIP版MySQL那就需要去完整安装版的机器上或者官方开发包里去拿include和lib目录。我的建议是不要嫌麻烦直接把MySQL Installer完整跑一遍开发组件最齐全省得后面缺文件。2.2 VS工程里需要配好的五个位置拿到头文件和库文件之后VS工程要配置以下几个地方我按顺序列一下项目属性 - C/C - 常规 - 附加包含目录填MySQL的include目录路径比如C:\Program Files\MySQL\MySQL Server 8.0\include项目属性 - 链接器 - 常规 - 附加库目录填lib目录注意MySQL 8.0的lib下面可能还分debug和release子目录按你编译的配置选对应的项目属性 - 链接器 - 输入 - 附加依赖项填libmysql.lib老版本可能是mysqlclient.lib平台位数必须匹配VS工程是x64就选64位的lib和dllWin32就选32位混用编译直接报链接错误把对应版本的libmysql.dll拷贝到exe的输出目录或者放到系统PATH里否则运行时会提示找不到DLL。这一步还有个细节Debug和Release模式下链接的lib可能不一样。MySQL 8.0的lib目录下如果分debug和release你就要在工程配置里分别设置别图省事只配一套否则换了配置编译又是链接错误。2.3 不装完整MySQL只想要开发库怎么办有读者可能只是想在原有项目里加个数据库功能不想为了开发库去装一整套MySQL服务。我的做法是找一台已经装好MySQL的机器把include目录整个拷出来lib目录按需要的位数拷出来再用一个简单的示例程序验证头文件和lib能编译链接通过。这样虽然有点野路子但项目开发阶段完全够用。关键是keep住位数一致32位工程不要拷64位的库。3. 核心链路初始化、连接、查询与结果集遍历环境配好之后接下来就是写代码。我先把一条最完整的链路过一遍——初始化、连接、设置字符集、执行SQL、取结果集、遍历数据、释放资源。每一步都有对应的API缺一个或者顺序乱了程序就会出各种莫名其妙的问题。3.1 初始化与建立连接C API的起点是mysql_init它返回一个MYSQL*句柄。这个函数可以传空指针让内部自己分配空间也可以用栈上的MYSQL结构体。用空指针最省事#include mysql.h MYSQL* conn mysql_init(nullptr); if (nullptr conn) { AfxMessageBox(_T(初始化MySQL句柄失败)); return; }接着是mysql_real_connect参数列表很长但核心就是主机地址、用户名、密码、数据库名和端口if (nullptr mysql_real_connect( conn, 127.0.0.1, root, 123456, testdb, 3306, nullptr, 0)) { CStringA errMsg mysql_error(conn); AfxMessageBox(CA2T(errMsg)); // 转成宽字符才能在Unicode工程里显示 mysql_close(conn); return; }这里有个小坑mysql_error返回的是const char*而MFC工程如果默认是Unicode字符集AfxMessageBox又只接受宽字符直接塞进去编译都过不了。我的习惯是先把const char*转成CStringA再接一次CA2T宏转成Unicode这是MFC工程里最常见的字符串转换套路。3.2 设置字符集这步要在查询之前做连上之后第一件事不是执行SQL而是设置字符集。很多人漏了这一步后面中文全是乱码。看后面第4节会专门展开这里先把代码写上mysql_set_character_set(conn, gbk);如果你在MFC工程里用的是CStringANSI版本字符集设成gbk最稳跟中文本地化环境直接对口。如果你的程序交互层全部走UTF-8那就设utf8mb4各有各的适用场景。3.3 执行查询与遍历结果集连接和字符集都准备好了下面这段是查询的完整流程CStringA sql; sql.Format(SELECT id, name, score FROM student WHERE score %d, 60); if (0 ! mysql_query(conn, sql.GetString())) { CStringA err mysql_error(conn); AfxMessageBox(CA2T(err)); mysql_close(conn); return; } MYSQL_RES* res mysql_store_result(conn); if (nullptr res) { AfxMessageBox(_T(获取结果集失败)); mysql_close(conn); return; } int fieldCount mysql_num_fields(res); MYSQL_ROW row nullptr; while ((row mysql_fetch_row(res))) { for (int i 0; i fieldCount; i) { // row[i] 是 const char* 类型NULL字段会返回nullptr if (row[i]) { TRACE(_T(列%d: %a\n), i, row[i]); } } } mysql_free_result(res); mysql_close(conn);这段代码是核心骨架后面所有业务都在while循环里展开。有几个点需要说明我用的是mysql_store_result一次性把结果集全部拉回内存适合桌面端常见的几千行数据场景。如果查询结果非常大几十万行甚至上百万行就要改用mysql_use_result逐行读取避免内存暴涨MYSQL_ROW本质上是char**也就是每列都是字符串指针不管数据库字段是int还是varchar取出来都是文本。所以数字类型需要自己做atoi或atof转换NULL字段的情况要单独判断直接往CString里塞一个空指针会崩结果集一定要mysql_free_result释放连接用完一定要mysql_close否则每次查询都泄漏句柄程序跑一会儿就变得又卡又慢。3.4 封装一个简单的数据库辅助类如果你好好做一个MFC项目不可能只连接一次数据库所以我建议把上面这套流程封装成一个简单类比如叫CDbHelper。构造函数里做初始化连接析构函数里做关闭公开方法就暴露Query和ExecSql两个接口。这样业务代码里就不用反复写一堆mysql_init、mysql_close的样板代码了。我实际封装的时候会把MYSQL* conn作为成员变量同时保存一个CStringA m_lastError每次调用失败就把错误信息存下来方便界面提示。封装类的重点不是设计模式而是把“连接的创建和销毁”管好避免业务代码里东一个连接西一个连接。4. 中文乱码与CString转换绕不开的字符集之争MFC连接MySQL最难缠的往往不是连接本身而是中文乱码。这个问题从热搜词里就能看出来一大半人都在搜“CString转char”“mysql字符集”之类的内容。我刚开始也在这上面栽了跟头查了半天发现根子不在代码而在编码不对齐。4.1 乱码到底是怎么产生的MySQL服务端默认字符集是utf8mb4而老MFC工程在中文Windows系统里用的是ANSI编码中文字符实际上是GBK/GB2312。当客户端以默认的latin1或utf8连接把GBK字节流直接塞给数据库时服务端按utf8理解中文字符自然就变成了一堆问号或乱码。解决方向有两个让客户端以GBK身份跟服务端对话mysql_set_character_set(conn, gbk)。这是老工程最省事的路子CString里的GBK字节流直接透传不用在代码里做任何转码让整个程序统一走UTF-8mysql_set_character_set(conn, utf8mb4)但这样一来CString里的内容必须先转成UTF-8字节流才能传给MySQL取得的结果也要从UTF-8转回宽字符代码量明显增大。如果你维护的是那种从VC6时代一路改过来的MFC工程我的建议很直接用gbk方案。改造成本最低测试验证最直观。如果是全新项目一开始就把内部字符串定为UTF-8再配合CStringW做桥接长期来看更干净。4.2 CString和char*互转的标准姿势很多人在搜“CString转char”但实际场景要分两种情况。工程是ANSI字符集时CString直接就是char*的封装用CStringA强转就行工程是Unicode字符集时CString底层是宽字符必须通过CT2A或WideCharToMultiByte转成char*。我一般这样处理// Unicode工程CString转UTF-8 CStringW wideStr L中文测试; int len WideCharToMultiByte(CP_UTF8, 0, wideStr, -1, nullptr, 0, nullptr, nullptr); CStringA utf8Str; char* buf utf8Str.GetBuffer(len); WideCharToMultiByte(CP_UTF8, 0, wideStr, -1, buf, len, nullptr, nullptr); utf8Str.ReleaseBuffer();反过来MySQL返回的const char*转成CString如果是ANSI工程非常简单直接CString(str)就行如果是Unicode工程则需要用CA2T宏或者MultiByteToWideChar。这块代码网上虽然多但大部分都只讲了半截没说明字符集工程类型的差异。实际操作时一定要先看清工程是哪种字符集再决定用哪种转换方式。4.3 SQL语句里的中文才是隐藏雷还有一个很多人没意识到的问题SQL语句本身如果包含中文字符字符集也必须一致。比如WHERE name 张三如果你的SQL字符串是Unicode工程的CStringW直接转成char*之后默认转出来的是GBK字节而连接层的字符集设定如果是utf8mb4这个条件就匹配不上。即使没有乱码显示查询结果也是空的。我踩过这个坑之后把SQL统一做成CStringA并且固定按连接设定的字符集来编码。也就是说连接层设了什么字符集传给mysql_query的SQL字符串就必须是那个编码中间不能再有隐式的转码动作。5. 编译与部署LNK2019、缺失DLL和认证插件的连环坑代码写完了环境也配置了跑起来还是一堆问题。这节的坑我都是亲手踩过的每一步都对应网上能搜到的高频报错。5.1 LNK2019无法解析的外部符号报错形式通常是一堆mysql_init等符号找不到。原因无非三个附加依赖项没加libmysql.lib检查工程属性里有没有写或者有没有在代码开头写#pragma comment(lib, libmysql.lib)lib的位数跟工程位数不一致x64工程链了32位的lib几乎必报这个错Debug和Release配置下lib目录指向了不存在的路径我前面提醒过MySQL 8.0的lib下分debug和release一定要按实际配置分别设置。5.2 运行时提示找不到libmysql.dll这个错误很直白编译链接全过了一运行就弹窗“由于找不到libmysql.dll无法继续执行代码”。解决办法是把对应位数的libmysql.dll拷贝到exe所在目录。注意一定要跟编译时选的lib位数匹配。有的机器上装了32位MySQL但工程是x64你把32位的dll拷过去启动时会直接崩溃而不是报缺库。老项目如果要把程序发布到别的机器记得把libmysql.dll作为发布文件的一部分一起带上同时确认目标机器上有对应版本的VC运行库。MySQL 8.0的dll依赖较新版本的运行库新版Win10一般自带老系统可能还需要装一下。5.3 MySQL 8.0的认证插件兼容问题如果你的项目用了旧版的libmysql.dll连接MySQL 8.0时可能会报Authentication plugin caching_sha2_password cannot be loaded。原因是MySQL 8.0默认认证插件改成了caching_sha2_password旧客户端不认识。解决有两条路。第一条是升级客户端库把libmysql.dll和配套的include/lib都换成8.0版本最干净第二条是在服务端把用户改成老认证方式类似的语句是ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456;但这种方法只是临时过渡新项目不建议再用老认证方式因为安全性和后续兼容性都会越来越差。我当时图省事先用第二种方式解决了问题等有空了再把整体连接库升级到8.0。如果你维护的是长期项目建议直接升级客户端库省得以后又要返工。5.4 连接超时和访问被拒程序写完测试时如果mysql_real_connect返回失败第一反应不是乱改代码而是按顺序排查MySQL服务是否启动、端口号是不是3306、用户名密码是否正确、root用户是否授权了当前IP访问、防火墙是否放行了3306端口。这一串问题里最容易忽略的是MySQL服务没启动。桌面开发时往往不是专业的数据库管理员经常装了MySQL但服务没有自动运行。我的经验是先把MySQL服务状态确认了再用命令行客户端mysql -u root -p试连一次能连上说明服务端没问题问题大概率在程序或网络配置上。这比反复改代码高效得多。5.5 我现在的固定做法踩过这一圈坑之后我做MFC加MySQL的项目已经形成了固定套路C API连接、封装一个工具类负责连接和查询、字符集统一用gbk、发布时把libmysql.dll塞到exe同目录。这套组合在几个老项目里跑下来都比较稳没再出现过让人头疼的灵异问题。如果你正准备在MFC项目里接MySQL不用想得太复杂直接从C API起步先跑通一条最简单的查询链路再逐步把功能加上去。数据库连接这件事核心就是环境、编码、API调用三件事三件事按顺序打通了后面就是写业务代码了。本文还有配套的精品资源点击获取