Learning spatial index

Tue, 17 Mar 2026 10:00:00 +0800

空间索引是数据库系统的核心组件。传统方法（R-tree, Hilbert 曲线）在高偏态分布和动态更新场景下面临秩值簇化和长尾延迟的挑战。本文提出三阶段的学习型空间索引方案。

1. DLHM：密度感知的 Hilbert 降维映射

1.1 问题定义

给定 $d$ 维空间数据集 $\mathcal{D} = \{\mathbf{p}_1, \dots, \mathbf{p}_N\}$，其中 $\mathbf{p}_i \in \mathbb{R}^d$（地理空间场景下通常 $d = 2$）。目标是将 $\mathcal{D}$ 映射到一维有序序列 $\pi: \mathcal{D} \to [0, M-1]$，使得空间邻近性在一维序列中得以保持：

$$ \mathbb{E}_{(\mathbf{p}_i, \mathbf{p}_j) \sim \mathcal{D}}\left[|\pi(\mathbf{p}_i) - \pi(\mathbf{p}_j)| \;\middle|\; \|\mathbf{p}_i - \mathbf{p}_j\|_2 \leq \epsilon\right] \to \min $$

1.2 密度分布形式化模型

定义空间密度函数 $\rho(\mathbf{x})$ 为位置 $\mathbf{x}$ 处的局部数据密度。采用核密度估计（KDE）：

$$ \rho(\mathbf{x}) = \frac{1}{N h^d} \sum_{i=1}^{N} K\left(\frac{\|\mathbf{x} - \mathbf{p}_i\|}{h}\right) $$

其中 $K(\cdot)$ 为 Epanechnikov 核函数，$h$ 为带宽参数，按 Silverman 规则 $h = 1.06 \cdot \hat{\sigma} \cdot N^{-1/5}$ 确定。

MySQL InnoDB 核心机制：MVCC、索引、事务、锁与 SQL 优化

Fri, 27 Dec 2024 15:30:00 +0800

面试必问，生产必用。把 InnoDB 的几个核心机制串起来理一遍。

InnoDB 架构概览

InnoDB 是 MySQL 默认存储引擎，核心特性：

B+Tree 索引 — 主键索引（聚簇） + 二级索引
MVCC — 多版本并发控制，读不阻塞写
行级锁 — Record Lock / Gap Lock / Next-Key Lock
事务 — ACID，通过 undo log + redo log 保证
Buffer Pool — 内存缓冲池，缓存数据页和索引页

┌─────────────────────────────────────────┐
│ 客户端连接 │
└─────────────────┬───────────────────────┘
 ▼
┌─────────────────────────────────────────┐
│ MySQL Server 层 │
│ 连接器 → 分析器 → 优化器 → 执行器 │
└─────────────────┬───────────────────────┘
 ▼
┌─────────────────────────────────────────┐
│ InnoDB 存储引擎 │
│ ┌──────────┐ ┌──────────┐ │
│ │Buffer Pool│ │ Redo Log│ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Undo Log │ │ 锁管理 │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────┘

B+Tree 索引

为什么是 B+Tree

数据结构	特点
二叉搜索树	可能退化成链表，高度太高
红黑树	二叉，高度依然大，IO 次数多
B-Tree	多路平衡，非叶子节点也存数据
B+Tree	数据只存叶子节点，叶子形成有序链表

B+Tree 的优势：

Database on GYM