
> **GPL-2.0 开源 · 源码 + 预编译双通道交付**
> GitHub: <https://github.com/gjb711> · GitCode 同步: <https://gitcode.com/user/gjb711/repos>

---

## 一句话

**FASTMEM** 是一个**彻底没有表锁、读者无锁、写者按行串行化**的内存存储引擎插件,
把它装进 MySQL / MariaDB,`ENGINE=FASTMEM` 的内存表就能在高并发读写下
**碾压内置 MEMORY(heap)表**,甚至比 InnoDB 快一个数量级。

已发布**五个仓库、三条主线**,覆盖你手头几乎任何一个版本:

| 路线 | 目标服务器 | 仓库 |
|---|---|---|
| MySQL 线 | 5.7 / 8.4 LTS / 9.7 LTS | `fastmem-mysql57` · `fastmem-mysql84` · `fastmem-mysql97` |
| MariaDB 线 | 11.8 LTS(11.8.6 / 11.8.9) | `fastmem-mariadb118` |
| 上游项目 | MariaDB 12.x | `fastmem` |

---

## 为什么内存表“应该很快,却一锁到底”?

内存表数据全在内存,本该是闪电速度 —— 但内置 `MEMORY(heap)` 引擎有一个致命设计:
**任何写操作都要先拿整表锁**。

| 场景 | MEMORY 的表现 |
|---|---|
| 并发 UPDATE | 所有写串成一列,8 个线程排队 |
| 热行更新 | **整张表**被锁,冷行无辜陪跑 |
| 读与写混行 | 读者也要等这把锁,被写者阻塞 |
| AUTO_INCREMENT | 靠表锁保序,并发插入照样排队 |

于是出现荒诞一幕:**数据在内存里,性能却在硬盘下**。

**FASTMEM 把并发模型彻底重做**,让内存表找回它应有的速度。

---

## FASTMEM 三大核心

1. **零表锁** —— `store_lock()` 返回**零个** `THR_LOCK_DATA`,锁等待队列彻底不存在;
2. **无锁读者(seqlock)** —— 读者复制行镜像,靠奇/偶序号校验、撕裂即重试;
   **读者永不阻塞写者,写者也永不阻塞读者**;
3. **行级写串行化** —— 每行槽一把自旋锁 + 哈希桶锁,写者只排自己那行的队。

再加生产级细节:

- **并发安全自增**:CAS 区段预留,并发插入 id 连续、无重复、无缺口;
- **防悬垂引用**:8 字节槽号+代号引用,槽被复用即刻失效,杜绝悬垂指针;
- **零分配热路径**:固定槽 + 单次 `memcpy` 整行替换;
- **仅哈希索引**:`BTREE` 在 `CREATE` 阶段明确拒绝,不假装支持;
- 语义与 MEMORY 一致(非事务、无持久化、`max_heap_table_size` 限制行数)。

---

## 换引擎 = 改一个关键字

```sql
-- 原来
CREATE TABLE t (id INT PRIMARY KEY, v BIGINT) ENGINE=MEMORY;
-- 现在
CREATE TABLE t (id INT PRIMARY KEY, v BIGINT, KEY k_v (v)) ENGINE=FASTMEM;
```

其余全部不变:SQL、索引用法(哈希索引走 `=`/`IN`)、客户端、连接池。**零代码迁移**。

---

## 拿数据说话:同样的表,同样的负载

方法学统一:7000 行行情 K 线表 + 100 热行 + 每阶段 `SUM(close)` 零丢失校验
(丢了更新立刻现形),`8 并发 × 2000 条 UPDATE` 场景:

| 引擎 | MariaDB 11.8.9 | MySQL 8.4.10 | MySQL 9.7.0 |
|---|---|---|---|
| **FASTMEM** | **2 s** | **45 s** | **45 s** |
| MEMORY(heap) | 7 s | 61 s | 62 s |
| InnoDB | 32 s | 131 s | 129 s |

读者 0→8 递增时,FASTMEM 写者几乎不退化(无锁读直接兑现):
MariaDB 上 `1 s → 2 s`,而 MEMORY 因整表锁被读者拖到同样 2 s 起步。

**跨五个版本、18/18 零丢失校验全过** —— 说“内存表不再一锁到底”,这是实测背书。

---

## 关键差异:体系结构不同,交付也要“对版”

MySQL 与 MariaDB 的 handler API 并不相同(锁对象、错误码、索引 map 都是两套),
而 **MariaDB 插件有 ABI 闸门**:为 11.8.5 编译的插件放到 11.8.9 上会被直接拒绝
(“API version … not supported”/缺符号),MySQL 侧同理。

FASTMEM 的双通道交付就是为了治好这一点:

**① 成熟版本 —— 直接下载预编译插件**

> Release: <https://github.com/gjb711/fastmem-mariadb118/releases/tag/v1.0-mariadb118>

| 资产 | 适用服务器 | 验证 |
|---|---|---|
| `ha_fastmem-mariadb118.so` | MariaDB 11.8.9 | 12/12 冒烟 PASS |
| `ha_fastmem-mariadb1186.so` | MariaDB 11.8.6 | 12/12 冒烟 PASS |

（`ha_fastmem-mysql84.so` / `ha_fastmem-mysql97.so` / `ha_fastmem-mysql57.so`
由各 MySQL 仓库 Release 提供。**MySQL 5.7 需要 Boost 1.59,8.4 内置 Boost 1.84,
9.7 内置 Boost 1.87 —— 各仓库 install.sh 已处理。**）

**② 任意版本 —— 一条命令现场编译(含 `--detect`)**

```bash
git clone https://github.com/gjb711/fastmem-mariadb118.git
cd fastmem-mariadb118
./install.sh --detect     # 自动读取本机 mariadbd 版本 → 40 秒出匹配插件
./install.sh --mariadb-version 11.8.9   # 或显式指定任意版本
```

- `--detect` 会探测本机 `mariadbd`/`mysqld`(含宝塔 `/www/server/mysql/bin/` 等
  不在 PATH 的位置),**编出来的插件必然与服务器同版**;
- GitHub 不可达时自动回退 `archive.mariadb.org`(或 MySQL 官方源码包)官方源码,
  已内置子模块,无需 git;
- 编译 40 秒 + 冒烟几分钟,**零发布成本** —— 这也是为什么不用为每个小版本发包:
  “你要哪个版本,就现场编哪个版本”。

---

## 工程可信度

- **修 bug 是家风**:MySQL 移植线早期就有 `index_next` 死代码(多行二级哈希扫描
  报错 124),三条 MySQL 线全部修复并各加**强制多行二级扫描回归**;MariaDB 上游版
  无此 bug,原样保留;
- **ABI 矩阵实测**:11.8.3→11.8.9 逐个小版本加载测试,结论是“必须同版”,于是
  交付物设计为“预编译两个 + `--detect` 覆盖全部”,而不是版本爆炸;
- 每个版本都有对应的 `DESIGN.md`(并发模型正确性论证)、`docs/BENCHMARK*.md`
  (环境+方法学+原始数据)、`standalone-test/`(免服务器单元验证)。

---

## 立刻上手

```bash
# 服务器上 30 秒(选一个):
wget -O /www/server/mysql/lib/plugin/ha_fastmem.so \
  https://github.com/gjb711/fastmem-mariadb118/releases/download/v1.0-mariadb118/ha_fastmem-mariadb1186.so
# 或现场编译(推荐,永远同版):
./install.sh --detect
```

```ini
# my.cnf / [mariadbd]
plugin-load-add=ha_fastmem
```

```sql
SHOW ENGINES;  -- FASTMEM 出现即成功
CREATE TABLE quotes (id INT PRIMARY KEY, close DECIMAL(19,4), KEY k_close(close))
  ENGINE=FASTMEM;
```

---

## 为什么开源 & 为什么值得你试

- **GPL-2.0**,源码分发,不附未知来路的二进制 —— 每个产物都来自**目标服务器
  官方源码**的现场构建,ABI 双方互相保证;
- 五个仓库互相引用、文档双语(EN / 简体中文)、一把 `install.sh` 通吃全家族;
- 想给高并发内存表提速、又不想引入复杂组件 —— FASTMEM 是**即插即用**的换芯方案。

**让“内存表很快”从一句玩笑话,变成一行 `ENGINE=FASTMEM`。**
项目主页: <https://github.com/gjb711> · 问题/PR 欢迎。

GPL-2.0 开源 · 源码 + 预编译双通道交付 GitHub: https://github.com/gjb711 · GitCode 同步: https://gitcode.com/user/gjb711/repos

MYSQL（无表锁）行锁内存表引擎FASTMEM  —— 让 MySQL/MariaDB 的内存表不再“一锁到底“

数据库

编程语言

开发工具

FASTMEM是一款MySQL/MariaDB内存存储引擎插件，彻底消除表锁，读者无锁、写者按行串行化，高并发读写性能远超内置MEMORY表，甚至比InnoDB快一个数量级。支持MySQL 5.7至9.7及MariaDB 11.8系列，提供预编译插件与源码编译双通道，零代码迁移，即插即用。

代码解释

服务器

MariaDB

GitHub

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MYSQL（无表锁）行锁内存表引擎FASTMEM  —— 让 MySQL/MariaDB 的内存表不再“一锁到底“-腾讯云开发者社区-腾讯云

MYSQL（无表锁）行锁内存表引擎FASTMEM —— 让 MySQL/MariaDB 的内存表不再“一锁到底“

MYSQL（无表锁）行锁内存表引擎FASTMEM —— 让 MySQL/MariaDB 的内存表不再“一锁到底“

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐