单层 map 可通过复合键或嵌套映射模拟多维索引，结合 mmap 实现轻量级虚拟内存数据库；复合键支持精确查找与哈希加速，嵌套 map 适合层级查询，mmap 分离索引与数据以提升大容量场景效率。
直接用单层 map 无法天然支持“多维键”，但可通过组合键（composite key）或嵌套映射结构，模拟多维索引语义，并结合内存映射（mmap）实现轻量级虚拟内存数据库。核心不是让 map 本身变多维，而是让键的设计承载多维语义，再配合内存布局优化访问效率。
用复合键（Composite Key）模拟多维索引
将多个字段拼接或打包为一个唯一键，作为 map 的 key 类型。适用于查询条件固定、维度组合明确的场景。
- 使用
std::tuple<int64_t, std::string, uint8_t>作为 key：支持按 (obj_id, category, status) 三元组精确查找，且 tuple 默认支持字典序比较，可直接用于std::map；若追求 O(1) 哈希性能，改用std::unordered_map并自定义哈希函数 - 手动拼接字符串键（如
fmt::format("{}#{}#{}", obj_id, cat, status)）：简单直观，但有构造开销和内存碎片风险；适合低频更新、高可读性调试场景 - 位封装整数键（如将 32 位 obj_id + 8 位 type + 8 位 flag 打包进
uint64_t）：零拷贝、极致紧凑，适用于嵌入式或高频实时索引，但牺牲可读性和扩展性
用嵌套 Map 构建层级索引树
把多维查询拆解为逐层跳转，每层 map 对应一个维度，形成类似 B+ 树的内存索引路径。适合维度间存在明显主次关系（如“库 → 表 → 行”）。
-
std::map<std::string, std::map<int64_t, std::vector<size_t>>> db_index;：第一层按 database_name 索引，第二层按 table_id 索引，值为对应记录在全局std::vector<Record>中的下标列表 - 插入时同步更新各层：新增一条记录，先追加到
records尾部，再分别向db_index[db][table]插入当前 size-1 下标 - 支持前缀扫描：例如遍历所有
db_index["user_db"]下的表，或查db_index["user_db"][101]的全部行——天然支持范围与模糊定位
与 mmap 联动：将索引与数据分离映射
不把整个数据库加载进内存，而是用 mmap 分别映射“索引区”和“数据区”，由 map 管理索引元数据，mmap 提供底层数据页的按需加载能力。
- 索引区（小而热）：用
std::unordered_map<Key, off_t>存储键 → 文件偏移量，该 map 完全驻留内存，构建快、访问快 - 数据区（大而冷）：通过
mmap(fd, length, PROT_READ, MAP_PRIVATE, offset)映射文件某一段；查询时先查 map 得到 offset，再触发对应 mmap 区域的页面故障（page fault），OS 自动载入所需页 - 优势：避免一次性加载 TB 级数据；支持 mmap 共享（多进程共用同一份只读数据映射）；索引变更无需刷盘，数据修改可设
MAP_SHARED同步落盘
关键注意事项
这类设计不是通用数据库替代品，而是面向特定 OLAP 或嵌入式场景的轻量方案，需主动规避常见陷阱：
- 避免 map 嵌套过深：超过 3 层嵌套（如
map<A, map<B, map<C, D>>>）会导致代码难维护、迭代器失效风险上升、缓存局部性下降 - 区分读写模式：纯查询场景可用
const std::unordered_map&引用传参；写操作必须加锁（如std::shared_mutex实现读多写少）或采用 RCU 模式 - 内存映射需对齐：
mmap的offset必须是系统页大小（通常 4KB）的整数倍，否则调用失败；建议数据结构体按alignas(4096)对齐并 padding 补齐 - 索引一致性靠业务逻辑保障：map 和 mmap 文件内容无自动同步机制，插入/删除记录后，必须显式更新 map 键值及（如需）调用
msync()刷脏页
