早就该把这块内容整理了。C开发里连数据库很多人一上来就选原生库或者各种封装框架但实际上ODBC这套标准接口才是跨平台、跨数据库的真正通用方案。这篇文章就拿ODBC连接MySQL做增删改查来完整走一遍从环境配置到API拆解再到完整代码和避坑经验全是实操层面的东西适合正在做桌面端工具、或者维护老项目的C开发者参考。1. 为什么用ODBC连MySQL而不是直接用原生API1.1 从业务痛点说起去年我在做一个跨平台的桌面数据管理工具需要同时支持MySQL、SQL Server和SQLite三种数据源。一开始图省事直接用MySQL官方提供的C API开发结果代码写到一半就发现坑了换一个数据库所有数据库操作代码全部得重写函数风格完全不一样连接参数、错误处理、数据类型映射全都要适配一遍。那段时间天天在改代码效率极低。后来切换到ODBC之后情况完全变了。核心的数据操作代码只需要写一遍换数据库的时候只需要换连接字符串顶多调整一下个别SQL方言的差异。这就是ODBC最大的价值——它是微软制定的统一数据库访问标准把数据库之间的差异都隔离在驱动层。1.2 ODBC的架构设计比想象中简单ODBC的分层架构非常清晰。最上层是你的C应用程序中间是ODBC驱动程序管理器Driver Manager负责管理连接、加载驱动、转发调用最底层是各个数据库厂商提供的ODBC驱动例如MySQL官方提供的Connector/ODBC、微软的SQL Server ODBC驱动等。这个分层带来的直接好处是代码逻辑和数据库实现彻底解耦。对应用程序来说它看到的是一组统一的接口函数比如SQLAllocHandle、SQLDriverConnect、SQLExecDirect等。至于底层是MySQL还是别的数据库应用程序完全不关心也不需要关心。我把这个机制类比成USB接口设备千差万别但只要都支持USB标准插上就能用。ODBC就是数据库世界的USB标准。2. 环境搭建与驱动配置这一步踩的坑最多2.1 驱动安装与版本选择先说Windows平台。如果你的项目用的是64位程序一定要装64位的ODBC驱动否则驱动管理器会直接报找不到数据源的错误。这个错误我第一次遇到时排查了半天后来才发现是驱动位数和应用程序位数不匹配。这个细节在实际开发中非常容易踩坑但官方文档一般不会重点提醒。MySQL官方提供的ODBC驱动是Connector/ODBC版本号从5.x到8.x都有。如果你连接的MySQL服务端是8.0以上直接装最新版驱动兼容性最好。8.0版本的驱动在连接字符串中需要指定DRIVER{MySQL ODBC 8.0 Driver}5.x版本则用DRIVER{MySQL ODBC 5.3 Driver}这个名称必须精确匹配驱动管理器里注册的名字否则连接时会报找不到驱动。2.2 两种连接方式DSN与连接字符串ODBC连接MySQL有两种方式一种是先配置系统DSN在ODBC数据源管理器中把数据源名称、服务器地址、用户名密码都填好代码里只需要指定DSN名称另一种是不配置DSN直接在代码里通过连接字符串指定所有连接参数。DSN方式的好处是连接信息集中在系统配置中适合内网工具类项目代码里不暴露密码。但缺点也明显换一台机器就得重新配置DSN部署麻烦。连接字符串方式则把所有参数写在一起移植性更强。我在实际项目中更喜欢连接字符串方式因为代码里能动态拼接服务器地址和参数。常用连接字符串长这样// 方式一使用DSN SQLCHAR connStr[] DSNmysql_dsn;UIDroot;PWD123456;; // 方式二直接使用驱动连接字符串 SQLCHAR connStr[] DRIVER{MySQL ODBC 8.0 Driver}; SERVER127.0.0.1; PORT3306; DATABASEtest_db; UIDroot; PWD123456; CHARSETutf8mb4;;注意CHARSETutf8mb4这个参数务必加上。如果不指定字符集MySQL ODBC驱动默认的字符集可能不是UTF-8中文数据就会出现乱码。这个参数对中文环境的项目来说几乎是必须的。2.3 最小可用环境检查清单照着这个清单检查基本能避开大部分环境问题确认MySQL服务已启动且端口可连通。本地开发如果连不上先检查服务状态。确认ODBC驱动已正确安装位数与应用一致。可以在ODBC数据源管理器里查看。如果使用Linux安装unixODBC和mysql-connector-odbc并在odbcinst.ini配置驱动。名称必须精确匹配。测试连接时先用官方客户端工具如MySQL Workbench、命令行确认账号密码可用。在ODBC数据源管理器里配置一个临时DSN测试驱动连接如果能成功说明驱动和网络都没问题再去排查代码。Linux下的配置稍微繁琐些需要在/etc/odbcinst.ini里设置[MySQL ODBC 8.0 Driver]小节并在/etc/odbc.ini里配置数据源或者直接用连接字符串。实际开发中连接字符串的方式在Linux下更省事因为不用维护odbc.ini。3. 核心API拆解从句柄到执行的完整链路3.1 三个句柄体系用ODBC写代码首先要理解三个句柄环境句柄SQLHENV、连接句柄SQLHDBC、语句句柄SQLHSTMT。这三者是一个从全局到个体的关系。环境句柄是ODBC应用程序的根相当于整个数据库操作环境的入口点。每个进程只需要分配一个环境句柄用于管理连接句柄和全局设置。连接句柄代表一个具体的数据库连接分配在环境句柄之下一个环境可以管理多个连接。通常一个连接对应一个数据库会话。语句句柄用于执行SQL语句和管理结果集分配在连接句柄之下一个连接可以同时创建多个语句句柄用于并发执行不同语句。整个流程是先分配环境句柄再基于环境句柄分配连接句柄连接成功后基于连接句柄分配语句句柄。释放时顺序则完全相反先释放语句句柄再断开连接并释放连接句柄最后释放环境句柄。一个常见的错误是释放顺序反了有些人直接把连接断开后就去释放环境句柄这时候语句句柄还没释放轻则资源泄漏重则程序崩溃。早期做项目时遇到过不少次后来我习惯在代码里用一个包装类统一管理句柄生命周期问题才彻底解决。3.2 连接与错误处理机制连接操作的完整代码#include sql.h #include sqlext.h #include iostream int main() { SQLHENV henv SQL_NULL_HENV; SQLHDBC hdbc SQL_NULL_HDBC; SQLRETURN ret; // 1. 分配环境句柄 ret SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, henv); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr 分配环境句柄失败 std::endl; return -1; } // 2. 设置ODBC版本为3.x ret SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr 设置ODBC版本失败 std::endl; return -1; } // 3. 分配连接句柄 ret SQLAllocHandle(SQL_HANDLE_DBC, henv, hdbc); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr 分配连接句柄失败 std::endl; return -1; } // 4. 连接数据库使用连接字符串 SQLCHAR connStr[] DRIVER{MySQL ODBC 8.0 Driver}; SERVER127.0.0.1; PORT3306; DATABASEtest_db; UIDroot; PWD123456; CHARSETutf8mb4;; ret SQLDriverConnect(hdbc, NULL, connStr, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr 连接失败错误码: ret std::endl; // 此时应该调用SQLGetDiagRec获取详细错误信息 return -1; } std::cout 数据库连接成功 std::endl; // 5. 后续操作... // 6. 释放资源顺序很重要 SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); SQLFreeHandle(SQL_HANDLE_ENV, henv); return 0; }ODBC的错误处理机制值得一提几乎每个API调用都会返回一个SQLRETURN值主要看SQL_SUCCESS、SQL_SUCCESS_WITH_INFO、SQL_ERROR、SQL_NO_DATA这几种状态。真正报错时需要调用SQLGetDiagRec函数获取详细的错误信息和错误码。很多人在开发时只看返回值是不是SQL_SUCCESS忽略了SQL_SUCCESS_WITH_INFO的情况。这个状态表示函数执行成功但有额外提示信息比如连接时驱动给出了一个警告。虽然不影响主流程但强烈建议打印出来看一眼有时候能提前发现隐患比如字符集提示、连接方式降级等。3.3 SQL语句执行路径ODBC执行SQL语句有两条路径直接执行和预处理执行。直接执行适合一次性的、不需要参数注入的SQL调用SQLExecDirect一步到位SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); ret SQLExecDirect(hstmt, (SQLCHAR*)SELECT 1, SQL_NTS);预处理执行适合需要反复执行、且需要参数注入的SQL。先通过SQLPrepare让数据库编译SQL模板再通过SQLBindParameter绑定参数地址最后调用SQLExecute执行。这个方式在性能和安全上都有明显优势能防止SQL注入还能减少SQL重复编译的开销。预处理执行在后面增删改查的参数化实现中会详细演示。这里先记住一个基本原则任何包含用户输入的SQL语句都不要用SQLExecDirect直接拼接字符串而是用参数绑定方式。4. 增删改查完整实现每个操作都给出可直接复制的代码4.1 新增数据直接执行与参数绑定两种写法插入数据最简单的方式是直接用SQLExecDirect拼接SQL字符串。这种写法适合固定数据的初始化场景比如在程序启动时插入一条默认配置记录。// 方式一直接执行 void insertDirect(SQLHDBC hdbc) { SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); SQLCHAR sql[] INSERT INTO users(name, age, email) VALUES(张伟, 28, zhangweiexample.com); SQLRETURN ret SQLExecDirect(hstmt, sql, SQL_NTS); if (ret SQL_SUCCESS || ret SQL_SUCCESS_WITH_INFO) { std::cout 插入成功 std::endl; } else { std::cout 插入失败 std::endl; // 调用SQLGetDiagRec打印详细错误 } SQLFreeHandle(SQL_HANDLE_STMT, hstmt); }但这种方式在真实业务中隐患很大。如果name来自用户在界面上的输入框直接拼SQL字符串用户输入一段恶意内容就能把整条SQL改掉。所以只要参数来自外部就必须用参数绑定方式。方式二是参数化插入// 方式二参数化插入 void insertWithParams(SQLHDBC hdbc) { SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); SQLCHAR sql[] INSERT INTO users(name, age, email) VALUES(?, ?, ?); SQLRETURN ret SQLPrepare(hstmt, sql, SQL_NTS); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr SQLPrepare失败 std::endl; return; } SQLCHAR name[64] 李娜; SQLLEN nameLen SQL_NTS; SQLINTEGER age 24; SQLCHAR email[128] linaexample.com; // 绑定参数参数序号从1开始 SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 64, 0, name, 0, nameLen); SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 0, 0, age, 0, NULL); SQLBindParameter(hstmt, 3, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 128, 0, email, 0, nameLen); ret SQLExecute(hstmt); if (ret SQL_SUCCESS || ret SQL_SUCCESS_WITH_INFO) { std::cout 参数化插入成功 std::endl; } SQLFreeHandle(SQL_HANDLE_STMT, hstmt); }需要注意SQLBindParameter的参数很多第三个参数SQL_C_CHAR表示C语言侧的数据类型第五个参数SQL_VARCHAR表示数据库列的类型这两个类型映射关系要搞清楚。字符类型在C侧统一用SQL_C_CHAR数字类型用SQL_C_LONG对应C的int。4.2 删除数据注意影响行数与事务边界删除操作同样可以通过直接拼接或参数化完成。实际开发中删除往往是风险最高的操作一个条件写错就可能删掉整张表的数据。所以的参数绑定尤其重要。bool deleteUser(SQLHDBC hdbc, int userId) { SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); SQLCHAR sql[] DELETE FROM users WHERE id ?; SQLRETURN ret SQLPrepare(hstmt, sql, SQL_NTS); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { SQLFreeHandle(SQL_HANDLE_STMT, hstmt); return false; } SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 0, 0, userId, 0, NULL); ret SQLExecute(hstmt); if (ret SQL_SUCCESS || ret SQL_SUCCESS_WITH_INFO) { SQLLEN rowCount 0; SQLRowCount(hstmt, rowCount); std::cout 删除影响行数: rowCount std::endl; SQLFreeHandle(SQL_HANDLE_STMT, hstmt); return rowCount 0; } SQLFreeHandle(SQL_HANDLE_STMT, hstmt); return false; }调用SQLRowCount获取实际影响的行数是个好习惯能让你确认到底删了多少条记录。如果影响行数为0可能说明条件不匹配未必是删除失败。删除操作要注意事务边界。如果在自动提交模式下DELETE一执行就立即生效没有后悔药。所以涉及批量删除时建议把多条删除操作放在一个事务里通过SQLEndTran显式提交或回滚。这个函数用来控制事务非常关键使用方法后面单独说。4.3 更新数据修改时必须绑定正确的类型长度更新操作和插入类似基本模式是UPDATE 表名 SET 字段 ? WHERE 条件 ?。这里有一个容易忽略的点如果使用SQL_C_CHAR绑定字符串参数长度传入SQL_NTS会让驱动根据字符串自动计算长度大多数时候都没问题。但如果你把字符串提前memset成固定长度且结尾没有空字符就必须显式传入字符串长度否则驱动会把缓冲区后面的垃圾数据也当作字符串去更新。bool updateUserEmail(SQLHDBC hdbc, int userId, const char* newEmail) { SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); SQLCHAR sql[] UPDATE users SET email ? WHERE id ?; SQLRETURN ret SQLPrepare(hstmt, sql, SQL_NTS); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { SQLFreeHandle(SQL_HANDLE_STMT, hstmt); return false; } SQLCHAR email[128]; strncpy((char*)email, newEmail, 127); email[127] \0; SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 128, 0, email, 0, NULL); SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 0, 0, userId, 0, NULL); ret SQLExecute(hstmt); SQLFreeHandle(SQL_HANDLE_STMT, hstmt); return ret SQL_SUCCESS || ret SQL_SUCCESS_WITH_INFO; }更新操作还有个选择问题更新前要不要先查询一下记录是否存在直接在UPDATE语句的WHERE条件里判断就行不需要单独查询。如果影响行数为0说明记录不存在或者条件不匹配可以给用户一个明确提示。4.4 查询操作SQLBindCol与SQLFetch配合遍历结果集查询是增删改查里复杂度最高的环节因为涉及到结果集的处理。核心思路是先用SQLExecDirect或SQLExecute执行查询然后用SQLBindCol把结果集的列绑定到C语言缓冲区最后循环调用SQLFetch逐行取数据直到返回SQL_NO_DATA。void queryUsers(SQLHDBC hdbc) { SQLHSTMT hstmt; SQLAllocHandle(SQL_HANDLE_STMT, hdbc, hstmt); SQLCHAR sql[] SELECT id, name, age, email FROM users ORDER BY id; SQLRETURN ret SQLExecDirect(hstmt, sql, SQL_NTS); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { std::cerr 查询失败 std::endl; return; } // 绑定结果集列 SQLINTEGER id 0; SQLCHAR name[64] {0}; SQLINTEGER age 0; SQLCHAR email[128] {0}; SQLLEN idLen 0, nameLen 0, ageLen 0, emailLen 0; SQLBindCol(hstmt, 1, SQL_C_LONG, id, 0, idLen); SQLBindCol(hstmt, 2, SQL_C_CHAR, name, sizeof(name), nameLen); SQLBindCol(hstmt, 3, SQL_C_LONG, age, 0, ageLen); SQLBindCol(hstmt, 4, SQL_C_CHAR, email, sizeof(email), emailLen); // 逐行读取 int count 0; while (SQLFetch(hstmt) SQL_SUCCESS || SQLFetch(hstmt) SQL_SUCCESS_WITH_INFO) { std::cout ID id , 姓名 name , 年龄 age , 邮箱 email std::endl; count; } std::cout 共查询到 count 条记录 std::endl; SQLFreeHandle(SQL_HANDLE_STMT, hstmt); }关于SQLBindCol的缓冲区长度字符串类型需要指定缓冲区大小驱动会保证最多拷贝到你指定的字节数并在nameLen中返回字符串实际长度。如果实际长度超过缓冲区大小驱动会做截断nameLen的值会大于缓冲区大小此时需要通过判断nameLen sizeof(name)来识别截断情况然后决定是否扩大缓冲区重新查询。查询大字段如TEXT、BLOB类型时这个缓冲区分配合适大小的问题会更突出。我的做法是先查询一次获取SQL_DESC_DISPLAY_SIZE等元数据再动态分配缓冲区。虽然是两次查询但换来的是从容应对不确定长度的大字段。这在处理用户上传的文本内容时非常有用。4.5 事务控制SQLEndTran的正确用法默认情况下MySQL ODBC驱动处于自动提交模式每条SQL语句执行完就自动提交。但批量操作时希望能要么全部成功要么全部回滚这时需要手动控制事务。void batchOperation(SQLHDBC hdbc) { // 关掉自动提交 SQLSetConnectAttr(hdbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, 0); // 执行多条操作... // 提交事务 SQLRETURN ret SQLEndTran(SQL_HANDLE_DBC, hdbc, SQL_COMMIT); if (ret ! SQL_SUCCESS ret ! SQL_SUCCESS_WITH_INFO) { // 提交失败尝试回滚 SQLEndTran(SQL_HANDLE_DBC, hdbc, SQL_ROLLBACK); } // 恢复自动提交如果有需要 SQLSetConnectAttr(hdbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_ON, 0); }这里有一个常见的误区SQLEndTran的第一个参数应该传SQL_HANDLE_DBC但有些人错误地传了SQL_HANDLE_ENV或语句句柄这会导致事务作用范围不正确。传SQL_HANDLE_DBC表示对当前连接下的所有活动语句统一提交或回滚这才是事务的语义。5. 常见问题与排查技巧实录5.1 连接失败时的排查顺序连接失败是最常见的问题但很多情况下不是代码本身有问题而是环境配置问题。我用一个固定的排查顺序基本上能覆盖99%的情况。用MySQL命令行工具连接同一个地址端口账号看是否能连通。连不上说明服务端或网络有问题。检查驱动名称是否跟ODBC管理器中注册的完全一致。名称大小写和空格都不能有偏差。检查驱动位数和应用位数是否一致。32位应用必须用32位驱动。检查连接字符串的各项参数。特别注意端口号不能写成字符串PORT3306是个数字如果误写成了PORT3306部分驱动会报连接失败。最后再检查防火墙确认没有拦截3306端口Linux下还要确认SELinux没拦截ODBC连接。5.2 中文乱码问题的根源中文乱码的根源基本可以归结为三个环节的字符集不一致客户端编码、连接字符集、数据库表字符集。首先要确保数据库和表使用UTF-8编码推荐用utf8mb4它完全兼容UTF-8还能存emoji。其次是连接字符串带上CHARSETutf8mb4参数让ODBC驱动以UTF-8与MySQL通信。最后是C代码侧的字符串Windows下VS工程要确保源文件保存为UTF-8或者统一使用UTF-8编码。我遇到过一种情况比较隐蔽Windows下使用std::string从控制台读取中文输入读到的是GBK编码的字节流然后直接通过ODBC绑定参数传给数据库结果中文变成问号。解决办法是先把GBK字符串转成UTF-8再传给ODBC。5.3 资源释放与句柄管理ODBC的句柄资源非常宝贵每个连接和语句句柄都对应底层的内存和数据库资源。最稳妥的做法是遵循严格的释放顺序先释放语句句柄然后断开连接再释放连接句柄最后释放环境句柄。我在实际项目中见过一个崩溃场景全局环境句柄被释放后某个模块的析构函数里还在执行SQL而它持有的语句句柄已经随连接释放野指针直接导致程序崩溃。后来通过引入引用计数和统一的句柄管理模块才彻底解决这类问题。5.4 SQL语句执行异常的快速诊断当SQLExecute或SQLExecDirect返回错误时光看错误码往往不够必须调用SQLGetDiagRec获取详细错误信息void printODBCError(SQLSMALLINT handleType, SQLHANDLE handle) { SQLCHAR sqlState[6]; SQLINTEGER nativeError 0; SQLCHAR message[256]; SQLSMALLINT messageLen 0; SQLGetDiagRec(handleType, handle, 1, sqlState, nativeError, message, sizeof(message), messageLen); std::cerr SQLSTATE sqlState , NativeError nativeError , Message message std::endl; }SQLSTATE是五位标准错误码比如HY000表示通用错误HY010表示句柄使用错误。根据SQLSTATE的提示可以比较快速地定位问题方向。这句代码建议封装成工具函数在项目每个可能出错的ODBC调用之后都调用一次调试效率会高得多。6. 一些实际项目里的经验总结6.1 包装ODBC调用的三层架构裸写ODBC函数在代码量小的时候问题不大但一旦涉及几十张表的读写代码会变得非常混乱。我后来习惯将ODBC封装成三层底层是ODBC功能函数封装封装所有句柄管理和基本操作中间层是数据库访问对象提供增删改查、事务控制接口上层是业务逻辑只面对简洁的接口。这样封装下来业务代码里基本看不到SQLHANDLE和SQLBind*这些底层的调用。换一种数据库时只需要替换底层实现往上两层不需要改动。6.2 性能优化上的两点建议批量插入时逐条执行INSERT性能很差。MySQL ODBC支持SQL_ATTR_PARAMSET_SIZE批量参数绑定一次调用SQLExecute就能插入多条记录性能能提升一个数量级。实现方式是把参数缓冲区改造成二维数组多行数据的多组参数一起绑定。这个功能虽然偏冷门但在数据迁移、批量导入场景下非常实用。还有查询大结果集时尽量避免一次把几十万行数据全部拉回来。可以设置SQL_ATTR_MAX_ROWS限制驱动返回的最大行数或者使用分页查询。MySQL没有标准的LIMIT语法通过ODBC参数绑定但通过拼接LIMIT ?, ?配合SQLBindParameter绑定分页参数也是可行方案不过要注意MySQL的LIMIT表达式在预处理语句中对于部分驱动版本要求使用LIMIT ?绑定旧版本可能不支持参数化LIMIT需要根据版本灵活处理。6.3 一条写代码时的铁律只要SQL语句涉及外部输入一律使用参数绑定禁止字符串拼接。用参数绑定不仅为了防SQL注入还能省去转义引号、处理特殊字符等一堆麻烦事。这条铁律我坚持了很多年从来没有因为SQL注入出过问题。ODBC从设计初衷到如今的实际应用确实已经走过了很长的路。虽然现在也有不少更现代的数据库访问方案但在跨数据库、稳定性和老旧系统兼容性这些维度上ODBC依然是很多项目的务实之选。希望这篇文章里的思路和代码能帮你在连接MySQL进行增删改查时少走一些弯路尤其是那些光看API文档根本学不到的经验——这也是我写这篇内容最有价值的地方。