企业官网建设流程全解析

简介：这份资源是一套基于微软基础类库（MFC）并通过ODBC接口访问MySQL数据库的C/C++工程实例，适合希望掌握Windows桌面程序连接MySQL的开发人员，也可作为相关课程设计的参考源码。压缩包内含一百一十七个文件，整体体积约一百八十一KB，其中四十九个C源文件与四十六个头文件承载核心功能，另配备工程配置、宏文件、资源脚本和说明文档，便于在Visual Studio中直接打开并检查各模块。目前已有约一百四十五人浏览学习。示例完整演示了ODBC数据源的初始化、DSN配置、通过数据类对象建立连接、执行结构化查询语句、遍历结果集以及数据记录的增删改查等操作，同时在代码中包含了常见字段读写和连接关闭的写法。阅读这套源码，可以帮助开发者快速搭建一个MFC与MySQL交互的可用骨架，减少重复调试工作，为后续功能扩展提供清晰参考。

1. MFC 桌面程序连 MySQL：这套标题组合到底在讲什么

老 MFC 项目要连 MySQL 时，你搜到的东西多半叫这种名字：MySQL.rar、MFC MySQL、ODBC 连接字符串、c_MySql。这套关键词背后其实只有一件事：在一个用 C++ 和 MFC 写的 Windows 桌面程序里，通过 ODBC 接口把 MySQL 的表读进 CRecordset，再继续用 CDatabase、CString 这套老伙计干活。它解决的是一个从没碰过 MySQL 的 MFC 工程师最尴尬的十分钟——驱动装错位数、连接串写错关键字、字符集配置不一致，连个“你好”都查不出来。这篇文章适合两类人：一类是接手老桌面程序、要把数据库从 Access 或 SQL Server 迁到 MySQL 的；另一类是想在新 MFC 程序里用 ODBC 少写底层网络代码的。下面按实际调通的顺序写，代码可以直接抄，高频坑集中在第 4 章。

2. ODBC 驱动选型：版本与 32/64 位匹配为什么先于代码

MFC 读 MySQL 有三条常见路径：MySQL 官方 C API、第三方 C++ 封装库、ODBC。标题里既然写了 ODBC，实际工程里多半也是这条路——MFC 的 CDatabase 和 CRecordset 天生是 ODBC 对象，你不需要额外引入一套连接管理代码。选 ODBC 的核心理由是兼容性：老项目从 Access 或 SQL Server 迁到 MySQL 时，界面层代码基本不动，变的只是连接串和少量 SQL 方言。代价也很明确：多一层驱动，报错信息会变得很隐晦，这也是第 4 章要集中解决的问题。

2.1 为什么走 ODBC，而不是直接调 mysql C API

写 mysql C API 不是不行，MFC 程序里mysql_init、mysql_real_connect、mysql_query一串下来也能跑，但很快会遇到三个实际麻烦。

第一个是连接生命周期。C API 的连接句柄是裸指针，MFC 对话框程序里你要自己做重连、超时、释放；而 CRecordset 在对话框和文档视图里都有现成的生命周期管理。第二个是类型转换。MySQL C API 返回的全是char*字节，你得自己把每一列转成CString、int、CTime，MFC 的 RFX 机制可以一次性解决这个问题。第三个是迁移成本。老程序原来用CDatabase::Open连 SQL Server，改连 MySQL 只换驱动名和连接串，数据访问层不用推倒重来。

所以我的选型判断是：界面层用 MFC、数据库用 MySQL 的项目，只要不是靠 MySQL 的 JSON 函数和空间索引做重型业务，ODBC 就是投入产出比最高的接法。真到了需要批量灌数、跑复杂存储过程的场景，再考虑 C API，那时候通常也不是 MFC 程序该干的活了。

2.2 Connector/ODBC 版本差异与位数匹配

这里是最容易翻车的前哨站。MySQL 官方的 ODBC 驱动分成两代：5.3 系列和 8.x 系列。5.3 是老牌驱动，稳定但有一个硬伤——它不认识 MySQL 8.0 默认的caching_sha2_password认证插件，服务端新建用户一多，老驱动连上去就报插件无法加载。8.x 驱动解决了这个问题，连接串里也支持ssl-mode这种现代参数。我的建议很直接：新项目一律用 8.x 的 Unicode 驱动；老项目升驱动时先跑一遍回归，重点看字符集和 SSL 默认行为有没有变化。

位数匹配才是真正的坑。MFC 工程如果是 Win32 平台，必须用 32 位版本的 ODBC 驱动；MySQL 服务端是 64 位没有关系，客户端驱动和服务端位数不需要一致。Windows 上检查驱动列表有个反直觉的点：C:\Windows\System32\odbcad32.exe是 64 位驱动管理器，C:\Windows\SysWOW64\odbcad32.exe才是 32 位的。System32 里的文件名听着像 32 位，实际不是。32 位 MFC 程序报“找不到驱动程序”时，先去 SysWOW64 的 odbcad32 里确认驱动是否真的存在，能省下半小时。

2.3 一条连接字符串的参数拆解

如果不想建 DSN，MFC 里可以直接用无 DSN 连接串。下面这段是我现在写 MFC 连 MySQL 时的固定模板：

DRIVER={MySQL ODBC 8.0 Unicode Driver};SERVER=127.0.0.1;PORT=3306;DATABASE=test;UID=root;PWD=123456;charset=utf8mb4;OPTION=3

各参数的作用按顺序过一遍。DRIVER 名称里带空格，必须用大括号包住；如果是 5.3 驱动，名称常见是“MySQL ODBC 5.3 Unicode Driver”，名称写错会直接报 IM002。SERVER 一定写成 IP 地址，不要写localhost，Windows 上 localhost 经常被解析成 IPv6 的::1，而 MySQL 默认只监听 IPv4 的 127.0.0.1，看连接串好像没问题就是连不上。PORT 必须和 MySQL 实际端口一致，默认 3306，但很多内网库会改到 3307 或 3308。charset=utf8mb4决定客户端拿到的字节流编码，写错的话后面中文乱码会成片出现。最后的 OPTION 是驱动的行为标志位，老教程里最常见的是OPTION=3，它对应 MySQL 客户端库几个连接标志的组合，历史兼容性很好，不理解含义时可以保留，别随手改成OPTION=0。

DSN 和无 DSN 的选择建议也放这里。DSN 适合内网固定环境，多台机器配置统一，连接串短；交付到客户现场时，客户机器不一定建了同名 DSN，无 DSN 连接串更稳。我的习惯是开发时建一个 DSN 方便测试，代码里统一走无 DSN 连接串，只在发布包里留一个配置文件让实施人员改 IP、端口和密码。

3. 在 MFC 工程里跑通第一条查询：DSN、CDatabase 与 CRecordset

这一章的前提是驱动已装好、MySQL 服务能通过命令行连上。网上很多 MySQL 安装教程只讲服务端怎么装，却忽略客户端驱动的位数匹配，所以这里先处理 DSN 配置，再写最小连接代码，最后用 CRecordset 把数据读出来。

3.1 先装驱动再建 DSN：图形化配置与命令行检查

打开“运行”，执行C:\Windows\SysWOW64\odbcad32.exe，注意 32 位 MFC 项目必须走这个入口。在“系统 DSN”标签页点“添加”，选 MySQL ODBC 8.0 Unicode Driver，填下面的参数：

• Data Source Name：填MySQLTest，这个名称后续出现在连接串里
• TCP/IP Server：填127.0.0.1
• Port：填3306
• User / Password：填真实账号
• Database：填你要连的库名

填完点 Test，显示 Connection successful 就说明驱动、网络、账号三件事都通了。之后代码里的连接串可以简写成：

DSN=MySQLTest;UID=root;PWD=123456;charset=utf8mb4

如果 Test 失败，先回到第 2 章检查位数和驱动版本，别急着改代码。命令行检查已安装驱动的方式是看 odbcad32 的“驱动程序”页，里面会出现两行 MySQL ODBC 条目，一版是 ANSI Driver，一版是 Unicode Driver。MFC 工程里建议统一选 Unicode Driver，ANSI 版本在中文 Windows 上处理多字节字符集时容易出幺蛾子。

3.2 用 CDatabase::OpenEx 打开 MySQL 连接的最小代码

DSN 配好以后，MFC 这边先验证连接本身。这段代码去掉所有业务逻辑，只有连接和异常处理：

CDatabase db; try { db.OpenEx( _T("DRIVER={MySQL ODBC 8.0 Unicode Driver};SERVER=127.0.0.1;PORT=3306;DATABASE=test;UID=root;PWD=123456;charset=utf8mb4;OPTION=3"), CDatabase::noOdbcDialog); } catch (CDBException* e) { AfxMessageBox(e->m_strError); e->Delete(); return; }

第二个参数CDatabase::noOdbcDialog的作用是连接失败时不弹 ODBC 自带的数据源选择对话框，直接把错误抛给调用方。CDBException::m_strError里包含驱动返回的 SQLSTATE 和错误文本，第 4 章那些报错基本都是从这里看到第一手信息的。

打开成功后，连接会一直存活到CDatabase对象析构，不需要手动调 Close，但如果你要在一次操作里反复开关连接，还是显式db.Close()更省资源。另外，工程字符集如果是 UNICODE，这段连接串里的汉字参数也能正确处理，前提是连接串里已经写了charset=utf8mb4，这一点在稍后的乱码排查里会再次出现。

3.3 用 CRecordset 绑定字段并遍历结果集

连接建立了，下面就是 MFC 查 MySQL 的标准套路：写一个 CRecordset 子类，在DoFieldExchange里定好列和成员变量的绑定关系。

class CUserSet : public CRecordset { public: CUserSet(CDatabase* pDb) : CRecordset(pDb), m_id(0), m_age(0) {} virtual CString GetDefaultSQL() { return _T("SELECT id, name, age FROM t_user"); } virtual void DoFieldExchange(CFieldExchange* pFX) { pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Long(pFX, _T("id"), m_id); RFX_Text(pFX, _T("name"), m_name); RFX_Long(pFX, _T("age"), m_age); } LONG m_id; CString m_name; LONG m_age; };

注意GetDefaultSQL返回完整 SELECT 时，MFC 会原样执行；如果返回表名，MFC 会生成SELECT *并依赖表结构顺序，容易绑错列。所以我一直建议 SELECT 里把列名写全。RFX 宏的第二个参数必须和 SELECT 里的列名一致，它同时决定驱动按哪个名字取列值。

取数遍历的代码长这样：

CUserSet rs(&db); rs.Open(CRecordset::forwardOnly, NULL, CRecordset::readOnly); while (!rs.IsEOF()) { CString strLine; strLine.Format(_T("id=%d name=%s age=%d"), rs.m_id, rs.m_name, rs.m_age); // 这里把 strLine 塞进 CListCtrl 或日志 rs.MoveNext(); } rs.Close();

Open的第一个参数forwardOnly是只进游标，性能最好，不会像 snapshot 那样把整个结果集先拉到本地；第三个参数readOnly让驱动跳过可更新游标的额外开销。查出来只展示的场景，这两组参数就够了。

4. MySQL 8.0 下 ODBC 连接失败：认证、SSL 与驱动的五个高频坑

ODBC 连接报错是 MFC 连 MySQL 路上最劝退的部分，因为大多数字符串不直观，搜索引擎里还混着大量 SQL Server ODBC 的 SSL 报错。下面五个坑，每个都按“现象 → 原因 → 解决”的顺序写，我这些年调过的项目基本都被它们轮番折磨过。

4.1 现象：连接报 SSL 证书链错误，或客户端无法建立连接

错误文本会以[08001]开头，里面有SSL connection error或certificate verify failed这类字样，紧跟的驱动名是[MySQL][ODBC 8.0(w) Driver]。很多人第一次见这个就以为是 MySQL 服务端的问题，其实驱动正常在工作，只是它默认对服务端发来的 TLS 证书做校验，而内网 MySQL 自签的证书链不被 Windows 证书库信任。

解决方式是在连接串里显式关闭 SSL 校验：

DRIVER={MySQL ODBC 8.0 Unicode Driver};SERVER=127.0.0.1;PORT=3306;DATABASE=test;UID=root;PWD=123456;charset=utf8mb4;OPTION=3;ssl-mode=disabled

如果你是用 DSN 配置的，在 DSN 配置页里找到 SSL 相关选项，把TLS/SSL设为 Disabled，效果一样。注意 MySQL ODBC 8.0 的ssl-mode拼法和 JDBC 里的useSSL、sslmode不是一回事，别拿搜到的 JDBC 参数直接套。

4.2 现象：报错 Authentication plugin 'caching_sha2_password' cannot be loaded

这个报错几乎只出现在“MySQL 8.0 服务端 + Connector/ODBC 5.3 驱动”的组合里。MySQL 8.0 新建用户默认使用caching_sha2_password认证插件，5.3 驱动只认识老的mysql_native_password，于是拒绝认证。

解决有两条路。第一条是升级驱动，换成 8.x 的 Unicode Driver，这是我最推荐的做法，不用动数据库账号。第二条是改账号插件，执行下面的 SQL：

ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES;

改完以后，老驱动能连了，但认证强度降了一档。内网测试环境无所谓，生产环境优先升级驱动。

4.3 现象：驱动管理器报 IM002，找不到 MySQL ODBC 驱动

程序的报错是[IM002] [Microsoft][ODBC 驱动程序管理器] 未发现数据源名称并且没有指定默认驱动程序，代码一行没改，装完驱动就是连不上。这就是位数不匹配的典型症状：MFC 程序是 Win32 编译，系统里装的是 64 位 MySQL ODBC 驱动，两边对不上，驱动管理器自然说“没这东西”。

解决方式先确认工程平台，Win32 工程就装 32 位驱动；然后打开C:\Windows\SysWOW64\odbcad32.exe，在“驱动程序”页确实能看到 MySQL 条目，再去跑程序。64 位驱动管理器里能看到不代表 32 位程序能用，这是真的玄学。

4.4 现象：中文全是问号，或 CString 显示乱码

连接成功、数据也查出来了，就是中文变成???或一串乱码。这种问题通常不是连接串一个地方造成的，而是三处编码没对齐：MySQL 服务端的character_set_server、表字段的字符集、连接串里声明的charset。

最稳的排查顺序是：先看连接串里有没有charset=utf8mb4，没有就加上；再确认表字段是utf8mb4；最后检查 my.ini 里[mysqld]段有没有character-set-server=utf8mb4，改完要重启 MySQL。三个地方对齐后，MFC 的 CString 按宽字符显示就不会乱。还有一个小坑：工程如果是多字节字符集编译，RFX_Text 取出的字符串会按当前代码页转换，中文 Windows 上大概率正常，但一旦换到其他区域设置的机器上又乱，所以我建议 MFC 工程直接切 UNICODE。

4.5 现象：10061 连接被拒，MySQL 服务却明明开着

报错是Can't connect to MySQL server on '127.0.0.1' (10061)，服务确实在跑，系统服务列表里 MySQL 状态也是“正在运行”。这个坑的隐蔽点不在服务，而在网络层。

先用命令行验证一次：

netstat -ano | findstr 3306 mysql -h127.0.0.1 -P3306 -uroot -p

netstat能看到0.0.0.0:3306或127.0.0.1:3306才说明端口在监听；如果只监听了::或某个特定 IP，连接串就要改对应地址。命令行能连、程序连不上，那就是 Windows 防火墙拦了 3306，把入站规则放开，或者把程序加到白名单。最后再看一眼连接串 PORT 是否真的一致，我见过有人 my.ini 里改成 3307，连接串还写 3306，手动查了半小时。

5. 数据映射与增删改：CRecordset 的边界在哪里

MFC 的 RFX 机制把 MySQL 列映射成 C++ 成员变量，这套机制本身很好用，但它的边界很清楚：基础类型没问题，复杂类型和可更新游标就有脾气。这一章把映射关系、更新限制、大数据量三个问题说透。

5.1 MySQL 列类型与 RFX 宏的映射表

我常用的映射关系如下，按 MySQL 列类型展开：

RFX_Text 的默认最大长度是 255 字节，如果 VARCHAR 列实际存了几百上千字，绑定后会被截断。处理方式是给 RFX_Text 传第四个参数，比如RFX_Text(pFX, _T("remark"), m_remark, 2048)，把上限抬到实际需要的大小。

5.2 可更新结果集的限制：什么时候必须换 ExecuteSQL

很多初学者以为 CRecordset 能查就能改，于是调AddNew、Update想去更新一行，结果驱动要么报错，要么没有任何效果。原因是可更新游标对 SELECT 有硬性要求：单表查询、结果包含主键、不能有聚合函数、不能 GROUP BY，有些驱动版本连 ORDER BY 都不支持。

我的做法是在 MFC 工程里只用 CRecordset 做查询，所有 UPDATE、INSERT、DELETE 走CDatabase::ExecuteSQL：

CString strSQL; strSQL.Format(_T("UPDATE t_user SET name='%s' WHERE id=%d"), strName, nId); db.ExecuteSQL(strSQL);

这里要注意单引号问题：strName里如果带了单引号，SQL 语句会被截断甚至报语法错误，常见处理是把单引号替换成两个连续单引号：

CString nameEscaped = strName; nameEscaped.Replace(_T("'"), _T("''")); strSQL.Format(_T("UPDATE t_user SET name='%s' WHERE id=%d"), nameEscaped, nId);

如果你连拼 SQL 都嫌麻烦，就回到第 6 章的参数化方案，让驱动处理转义，这比手工替换更不容易出错。

5.3 大批量取数翻车与分页方案

CRecordset 默认的 snapshot 模式会把整个结果集拉到本地，看起来是“打开结果集”，实际服务端数据在 Open 那一下已经全部搬了一遍。表里二十万行时，界面会卡住十几秒，这是最典型的翻车场景。

改成forwardOnly只是治标，用户滚动翻页时还是会一页一页往后拖，真正的分页方案是在 SQL 层做：

SELECT id, name, age FROM t_user ORDER BY id LIMIT 1000 OFFSET 0;

这个写法在数据量小的时候很直观，但 OFFSET 分页到百万行以后越来越慢，因为 MySQL 要把前 N 行全部扫过再丢弃。更工程化的方式是游标分页，用上一页最后一行的主键作为条件：

SELECT id, name, age FROM t_user WHERE id > ? ORDER BY id LIMIT 1000;

下一页的?传当前页最后一条记录的 id 值，这样即使数据量涨到千万级，每页开销也基本恒定。这个?参数正好用下一章的 CRecordset 参数化封装来传，两边组合起来就是一套完整的翻页方案。

6. 把常用查询封装成带参数的 CRecordset 子类

与其在代码里用strSQL.Format拼查询条件，不如让 CRecordset 自己管理参数。MFC 的 CRecordset 支持 ODBC 参数绑定，做法是把 SQL 里的字面值替换成?，然后在DoFieldExchange里用 param 段绑定成员变量。

6.1 带参查询的最小封装

class CUserSet : public CRecordset { public: CUserSet(CDatabase* pDb) : CRecordset(pDb), m_id(0), m_minAge(0), m_city(_T("")) { m_nParams = 2; // 参数个数，必须写 } virtual CString GetDefaultSQL() { return _T("SELECT id, name, age FROM t_user WHERE age >= ? AND city = ?"); } virtual void DoFieldExchange(CFieldExchange* pFX) { pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Long(pFX, _T("id"), m_id); RFX_Text(pFX, _T("name"), m_name); RFX_Long(pFX, _T("age"), m_age); pFX->SetFieldType(CFieldExchange::param); RFX_Long(pFX, _T("minAge"), m_minAge); RFX_Text(pFX, _T("city"), m_city); } LONG m_id; CString m_name; LONG m_age; LONG m_minAge; CString m_city; };

调用方式是在 Open 前给参数成员赋值：

CUserSet rs(&db); rs.m_minAge = 18; rs.m_city = _T("上海"); rs.Open(CRecordset::forwardOnly);

两个细节值得单独拿出来说。第一，m_nParams必须设置为 2，不设的话 MFC 认为没有参数，驱动不会执行绑定，SQL 里的问号会被当成字面值导致语法错误。第二，参数绑定的顺序必须和 SQL 里?出现的顺序一致，age >= ?对应第一次 param 绑定，city = ?对应第二次，顺序反了不会报错，但值就传错了。

验证封装是否生效也很简单。打开 MySQL 的 general_log，看日志里实际执行的 SQL 是带字面值的WHERE age >= 18 AND city = '上海'，还是带占位符的WHERE age >= ? AND city = ?，后者才算走了参数化。这比任何断点调试都直观。

我在一个公告系统里就是靠这个封装把几十个写死在代码里的 SQL 条件收敛到三个子类里的。后来的习惯是：一切带用户输入的查询，先问自己走没走参数；一切要翻页的查询，先问自己数据量涨上去没有。前一个问题是正确性，后一个问题是活不活得久。希望帮到你。

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