C++

系列导航：编译器与注解 | 连接与事务 | 对象关系 | 类型安全查询 | 继承与视图 | 迁移与多库 | 性能与实践（本文） | 实战项目 引言：万人同服的存档难题 某 MMO 游戏服务器，5000 人同时在线，每 5 分钟执行一次全服存档： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // 朴素实现：逐个存档 void saveAllPlayers(odb::database& db, const std::vector<Player*>& onlinePlayers) { for (auto* player : onlinePlayers) { odb::transaction t(db.begin()); db.update(*player); t.commit(); } } // 5000 个玩家 × 每次 1 个事务 × 每事务 1 条 UPDATE // = 5000 次网络往返 + 5000 次事务提交 // 耗时：约 15~30 秒（取决于网络延迟） // 这期间游戏逻辑被阻塞，玩家感受到明显卡顿 这段代码有三个性能杀手： ...

系列导航：编译器与注解 | 连接与事务 | 对象关系 | 类型安全查询 | 继承与视图 | 迁移与多库（本文） | 性能与实践 | 实战项目 引言：游戏版本更新的数据库噩梦 游戏上线后，每次版本更新几乎都涉及数据库变更： v1.1：给 Player 加 vip_level 字段 v1.2：新增"成就系统"表 v1.3：把 gold 从 INT 改为 BIGINT（金币膨胀了） v2.0：重构道具表，拆分装备和消耗品 传统做法是手写 ALTER TABLE 脚本： 1 2 3 4 5 6 7 8 -- v1.1_add_vip.sql ALTER TABLE player ADD COLUMN vip_level INT NOT NULL DEFAULT 0; -- v1.2_achievement.sql CREATE TABLE achievement (...); -- v1.3_gold_bigint.sql ALTER TABLE player MODIFY COLUMN gold BIGINT UNSIGNED DEFAULT 0; 这套流程的问题： ...

系列导航：编译器与注解 | 连接与事务 | 对象关系 | 类型安全查询 | 继承与视图（本文） | 迁移与多库 | 性能与实践 | 实战项目 引言：道具系统的继承难题 游戏中的道具系统天然适合用继承建模： 1 2 3 4 Item（道具基类） ├── Weapon（武器） — 攻击力、攻速、暴击率 ├── Armor（防具） — 防御力、抗性、耐久度 └── Consumable（消耗品）— 恢复量、冷却时间、持续时间 在 C++ 中，这是一个干净的继承体系。但映射到关系数据库时，问题来了——关系数据库没有继承的概念。一张表怎么存不同子类的字段？ODB 提供了三种策略来解决这个问题，各有取舍。 此外，游戏运营经常需要统计数据——“全服多少人在线”、“公会战力排名”、“每日交易额”。加载完整对象再聚合太慢了，ODB 的 View（视图）让你直接获取投影和聚合结果，不产生完整对象。 1. 继承映射三策略 1.1 共同的基类定义 三种策略使用相同的 C++ 继承体系，只是 pragma 配置不同： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 // item_base.hxx — 道具基类（所有策略共用） #include <string> #include <cstdint> #include <odb/core.hxx> // 道具品质枚举 enum class ItemQuality : int { White = 1, // 白色 - 普通 Green = 2, // 绿色 - 优秀 Blue = 3, // 蓝色 - 精良 Purple = 4, // 紫色 - 史诗 Orange = 5 // 橙色 - 传说 }; 1.2 策略一：单表继承（Table Per Hierarchy） 所有子类共用一张表，通过鉴别器列（discriminator）区分类型： ...

系列导航：编译器与注解 | 连接与事务 | 对象关系 | 类型安全查询（本文） | 继承与视图 | 迁移与多库 | 性能与实践 | 实战项目 引言：手写 SQL 查询的隐患 游戏服务器中，查询无处不在——排行榜、道具筛选、好友搜索、日志审计。手写 SQL 最大的风险是编译器看不见的错误： 1 2 3 4 5 6 7 8 9 10 11 12 // ❌ 手写 SQL：字段名拼错，编译不报错，运行时才崩 auto result = mysql_query(conn, "SELECT * FROM player WHERE levle > 50 ORDER BY levle DESC"); // ^^^^ ^^^^ // 拼成了 levle，MySQL 直接报错 // 但编译器对此一无所知 // ❌ 类型错误：用字符串比较数字 auto result = mysql_query(conn, "SELECT * FROM player WHERE level > '50'"); // ^^^^ // 隐式类型转换，可能有意外行为 ODB 的查询系统从根本上解决了这个问题——字段名是 C++ 符号，类型是编译期检查的。拼错字段名？编译不通过。类型不匹配？编译不通过。 ...

深入学习 std::flat_map 头文件：<flat_map> 命名空间：std 编译器要求：C++23 起（GCC 15+ / Clang 18+ / MSVC 19.38+） 一、设计动机：std::map 的性能痛点 1.1 红黑树的缓存问题 std::map 底层是红黑树——每个节点独立分配在堆上： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 std::map 内存布局（红黑树）： ┌──────┐ │ Node │ ← 堆上随机位置 │ k=5 │ └──┬───┘ ┌───┴───┐ ┌────▼──┐ ┌─▼─────┐ │ Node │ │ Node │ ← 另一个堆上随机位置 │ k=3 │ │ k=8 │ └───────┘ └────────┘ 每次查找跳转 O(log n) 个节点，每个节点可能在不同的缓存行 → 大量 cache miss → 对于只读查找密集的场景，性能远不如连续内存 1.2 flat_map 的解法：排序 vector 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 std::flat_map 内存布局（两个排序 vector）： Keys vector（连续内存）： ┌───┬───┬───┬───┬───┬───┬───┐ │ 1 │ 3 │ 5 │ 7 │ 9 │ 12│ 15│ ← 有序排列 └───┴───┴───┴───┴───┴───┴───┘ Values vector（连续内存）： ┌───┬───┬───┬───┬───┬───┬───┐ │ A │ B │ C │ D │ E │ F │ G │ ← 与 keys 一一对应 └───┴───┴───┴───┴───┴───┴───┘ 查找 key=7： 二分查找 keys vector → 命中索引 3 → 返回 values[3] = D 二分查找在连续内存上进行 → CPU 预取高效 → 极少 cache miss 1.3 性能对比 操作 std::map std::flat_map 原因 查找 O(log n)，多次 cache miss O(log n)，极少 cache miss 连续内存二分 vs 树节点跳转 有序遍历 O(n)，频繁指针追逐 O(n)，顺序内存访问 vector 遍历 vs 树 in-order 遍历 插入/删除 O(log n) O(n)（需移动元素） vector 中间插入需后移所有元素 内存占用 每节点 ≥ 32 bytes 开销 几乎零开销 无节点指针/颜色位 迭代器稳定性 插入/删除不影响其他 全部失效 vector reallocation 一句话总结：flat_map 用插入性能换取查找和遍历性能——适合"少写多读"的场景。 ...

系列导航：编译器与注解 | 连接与事务 | 对象关系（本文） | 类型安全查询 | 继承与视图 | 迁移与多库 | 性能与实践 | 实战项目 引言：从单表到关系网络 前两篇我们学会了单个 Player 对象的持久化。但真实的游戏系统远不止一张表： 1 2 3 4 5 6 7 Player ──── 1:1 ────▶ PlayerProfile （玩家档案：头像、签名、战斗统计） │ ├─── 1:N ────▶ InventoryItem[] （背包：拥有多个道具） │ ├─── 1:N ────▶ Equipment[] （装备栏：穿戴的装备） │ └─── M:N ────▶ Guild[] （公会：多个玩家加入多个公会） 在关系数据库中，这些关系通过外键表达。而在 C++ 中，我们习惯用指针和容器表达。ODB 的工作就是在这两种世界观之间架起桥梁。 本篇将逐步讲解 ODB 如何用智能指针和 STL 容器映射所有类型的对象关系。 1. 关系映射基础概念 1.1 数据库外键 vs C++ 指针 数据库世界 C++ 世界 ODB 桥接方式 外键列（player_id BIGINT） std::shared_ptr<Player> ODB 自动处理 load/persist JOIN 查询 解引用指针 ptr->name() 延迟或急切加载 联接表（junction table） std::vector<shared_ptr<T>> ODB 自动维护联接表 1.2 ODB 的指针类型选择 ODB 支持多种指针类型来表达对象引用： ...

CMake 原理深度解析：从脚本到可执行文件的完整旅程 CMake 不难，难的是不知道它在干什么。这篇文章的目标就是把黑盒变白盒。 写在前面 大多数人学 CMake 的路径是：搜到一份 CMakeLists.txt，改改能用就行，出了问题就再搜。结果用了好几年，遇到稍微复杂一点的场景（比如交叉编译、多配置、发布库）就卡住了。 根本原因是没有建立原理模型——不知道 CMake 执行 cmake -B build 时到底发生了什么，project()、target_link_libraries() 这些命令在内部做了什么。 这篇文章就是要填这个坑。 前置要求：用过 CMake 写过几行命令，知道"能编译就行"是什么感觉。 一、CMake 是什么？（真正的答案） 1.1 一句话定义 CMake 是一个元构建系统（Meta Build System），它不直接编译代码，而是生成其他构建系统的配置文件。 这句话很关键，很多人把 CMake 当编译器用，但它跟编译器没有任何直接关系。 1.2 构建工具链全景 一个 C++ 项目从源码到可执行文件，经历了这些工具： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 你写的代码 │ ▼ CMakeLists.txt（你告诉 CMake 项目结构是什么） │ ▼ cmake -B build（配置 + 生成） │ ├── Linux/macOS → Makefile 或 build.ninja ├── Windows → Visual Studio .sln + .vcxproj 或 build.ninja └── macOS → Xcode .xcodeproj │ ▼ cmake --build build（或直接 make / ninja / msbuild） │ ├── 编译器（gcc / clang / MSVC cl.exe） │ → .cpp → .o（目标文件） │ └── 链接器（ld / lld / link.exe） → .o + .a/.lib → 最终的可执行文件或库 类比：CMake 就像建筑师画的图纸（蓝图）。施工队（make/ninja）按图纸干活，工人（编译器）才是真正拿锤子的人。图纸本身不盖楼。 ...

现代 CMake 课程学习：从「面向目录」到「面向目标」 现代 CMake 不是新语法，是新思维。 写在前面 这篇文章适合谁？ 用过 CMake 但只会 add_executable + target_link_libraries 的人 从 Makefile / Visual Studio 工程迁移过来，想系统学 CMake 的人 看别人 CMakeLists.txt 里一堆 PUBLIC、$<BUILD_INTERFACE:...> 一头雾水的人 什么是 CMake？（30 秒版本） CMake 不是编译器，它是一个构建系统生成器。你写一份 CMakeLists.txt，CMake 帮你生成对应平台的构建文件： Linux → Makefile 或 Ninja Windows → Visual Studio .sln 或 Ninja macOS → Xcode 或 Ninja 类比：CMake 就像一个"翻译官"，你用一种语言描述"我要编译什么"，它翻译成各平台编译器能理解的指令。 为什么要学"现代" CMake？ CMake 从 2000 年诞生至今，经历了巨大变化。2014 年的 CMake 3.0 是分水岭——引入了 target-based（面向目标）设计。此后的版本持续完善这套体系。 如果你还在用 include_directories()、link_libraries() 这套"传统写法"，那你用的是 2014 年之前的思路——就像 2025 年还在写 C++98 一样。 ...

系列导航：编译器与注解 | 连接与事务（本文） | 对象关系 | 类型安全查询 | 继承与视图 | 迁移与多库 | 性能与实践 | 实战项目 引言：一次失败的道具购买 某天，游戏服务器日志里出现了一条玩家投诉： “我花了 500 金币买药水，金币扣了但背包里没有药水！” 排查代码发现问题出在这里： 1 2 3 4 5 6 7 8 9 10 11 // 错误示范：非原子操作 void buyItem(Player& player, uint64_t itemId, uint64_t price) { player.deductGold(price); updatePlayerGold(conn, player); // SQL: UPDATE player SET gold=? WHERE id=? // ← 假如这里服务器崩溃了... Item item(itemId, player.id()); insertItem(conn, item); // SQL: INSERT INTO inventory ... } 金币扣除成功提交了，但道具插入还没执行服务器就崩了。数据不一致。 这个问题的根本解法是 事务（Transaction）：要么全部成功，要么全部回滚。ODB 用 RAII 语义让事务管理变得优雅且安全——即使代码抛异常，也不会产生"半完成"状态。 1. database 工厂与连接池 1.1 创建数据库连接 ODB 中，odb::database 是所有操作的入口。对于 MySQL 后端： ...

系列导航：编译器与注解（本文） | 连接与事务 | 对象关系 | 类型安全查询 | 继承与视图 | 迁移与多库 | 性能与实践 | 实战项目 引言：游戏服务器为什么需要 ORM？ 假设你正在开发一款 MMO 游戏服务器，玩家下线时需要将角色数据存入 MySQL。最朴素的做法是： 1 2 3 4 5 6 7 8 9 10 11 12 13 // 传统方式：手动拼接 SQL void savePlayer(MYSQL* conn, const Player& p) { char sql[1024]; snprintf(sql, sizeof(sql), "REPLACE INTO player (id, name, level, exp, gold, created_at) " "VALUES (%lu, '%s', %d, %lu, %lu, '%s')", p.id, p.name.c_str(), p.level, p.exp, p.gold, p.createdAt.c_str()); mysql_query(conn, sql); // 没有类型检查、没有防注入、字段增减要同步改 SQL... } 这段代码有几个致命问题： ...