多维排序索引应为每种查询维度建独立索引，用 size_t 下标关联数据；复合排序须用 std::stable_sort 叠加工序；等值+范围查询宜用 unordered_map + 预排序 vector；避免 boost::multi_index 因性能与一致性问题。
用 std::map 或 std::set 做多维排序索引？别硬扛
直接套用标准容器做“多维排序”是常见误区。比如想按 age 升序、score 降序查，有人写 std::map<:tuple int>, T></:tuple>，但 tuple 的字典序天然要求所有字段同向比较，无法混合升/降；更糟的是，一旦要按 score 单独范围查询，std::map 就完全失效——它只支持主键的前缀匹配。
真正可行的路只有一条：为每种常用查询维度建独立索引，用指针或 ID 关联到同一份数据体。这不是偷懒，是绕过红黑树的结构限制。
- 每个索引用
std::vector+std::sort预排序，或用std::set动态维护（代价是插入 O(log n)） - 索引项不存完整对象，只存
const T*或size_t下标，避免拷贝和内存碎片 - 修改数据时，必须同步更新所有相关索引，否则立刻查出脏数据
std::stable_sort 在构建复合索引时的关键作用
当你要按优先级组合多个字段排序（比如先按 region，再按 timestamp），不能依赖多次 std::sort —— 后一次会打乱前一次的相对顺序。而 std::stable_sort 保证相等元素位置不变，正好用来“叠加工序”。
例如：先按 priority 排，再对相同 priority 的块内按 created_at 稳定排序，最终效果就是复合排序。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 务必用
std::stable_sort，不是std::sort；后者不保序，结果不可控 - 自定义比较函数里，只判“是否严格小于”，不要写
<=或逻辑或，否则破坏严格弱序 - 如果数据量超 10 万，考虑用
pdqsort替代（需引入第三方），它在部分有序场景下比std::stable_sort快 2–3 倍
用 std::unordered_map<Key, std::vector<size_t>> 实现等值+范围混合查询
纯哈希表不支持范围查询，但可以把它和预排序数组配合起来：用哈希做第一层过滤（如 status == "active"），再在对应 std::vector<size_t> 的子集上二分查时间范围。
这个模式比全量 std::set 节省内存，也比每次遍历快得多——尤其当等值条件能筛掉 90% 数据时。
- Key 类型尽量用整数或小字符串视图（
std::string_view），避免哈希计算开销 -
std::vector<size_t>必须按某字段（如updated_at）预排序，且每次插入后调用std::lower_bound找插入点，维持有序 - 注意迭代器失效：若底层数据
std::vector<T>发生 realloc，所有size_t索引依然有效，但const T*指针会 dangling
为什么不用 boost::multi_index？它在高频更新场景下容易卡住
boost::multi_index 写法简洁，但它的每个索引都是独立红黑树，每次插入/删除都要同步更新 N 棵树。实测在单次插入触发 3 个索引更新时，耗时比手写双链表+排序数组方案高 40% 以上。
更隐蔽的问题是内存局部性：boost::multi_index 把同一对象的多个索引节点散落在不同内存页，CPU 缓存命中率低；而用 size_t 索引 + 连续存储的主数据，遍历时 cache line 利用率高得多。
- 仅当查询模式极其固定、且写入频率低于 100 次/秒时，才考虑
boost::multi_index - 调试时留意
multi_index_container::modify的异常安全：若比较函数抛异常，容器可能处于不一致状态 - 编译期模板膨胀严重，大项目里会拖慢 build time，CI 构建易超时
多维索引真正的复杂点不在排序逻辑，而在索引一致性维护——任何一次忘记更新某个索引，后续所有查询都不可信。与其堆砌抽象，不如用最直白的 std::vector<size_t> 和显式更新循环，把控制权牢牢握在自己手里。
