存储引擎全家桶
InnoDB / MyRocks / Aria / ColumnStore / Spider / CONNECT / S3——谁适合什么场景
MariaDB 是少数支持多存储引擎共存的数据库。同一个 server 里不同表可以用不同引擎，每张表用最适合的方式存。
总览
| 引擎 | 类型 | 事务 | 适合 |
|---|---|---|---|
| InnoDB | B+ Tree | ✅ | OLTP 默认（99% 用这个） |
| MyRocks | LSM Tree | ✅ | 写密集，存储省 |
| Aria | 类 MyISAM 增强 | ❌（崩溃恢复） | 临时表 / 系统表 |
| ColumnStore | 列存 | ❌ | OLAP / 数仓 |
| Spider | 分片代理 | 看后端 | 水平分片 |
| CONNECT | 外部数据 | ❌ | 跨库 / 跨格式查询 |
| S3 | S3 上的归档 | ❌ | 冷归档 |
| MEMORY | 内存 | ❌ | 缓存表（更应该用 Redis） |
| MyISAM | B+ Tree | ❌ | 禁用 |
InnoDB（默认）
详见 InnoDB 内部。
特点：
- 聚簇索引，主键决定物理顺序
- WAL + Buffer Pool
- MVCC 多版本并发
- 行锁
- 加密表空间
- doublewrite buffer
99% 的表应该用 InnoDB。
MyRocks
基于 RocksDB（Facebook 出品）的 LSM tree 引擎，MariaDB 自 10.2 起内置。
优势
- 存储占用比 InnoDB 小 50–70%（compression 默认开）
- 写密集场景吞吐高
- 不需要 doublewrite buffer，写放大低
劣势
- 范围扫描比 InnoDB 慢
- SELECT 单行也比 InnoDB 慢一点
- online DDL 没那么成熟
- backup 工具链不如 InnoDB
适合
- 大日志表（IoT、监控）
- 历史归档
- 需要省存储成本的写密集场景
启用
[mariadb]
plugin_load_add = ha_rocksdb
default_storage_engine = InnoDB # 默认还是 InnoDBCREATE TABLE events (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
ts DATETIME,
data JSON
) ENGINE=RocksDB;Aria
MyISAM 的"接班人"，有崩溃恢复。
- 默认用作临时表（
internal_tmp_table_storage_engine=Aria）和系统表 - 不支持事务、不支持外键
- 单文件、表锁、全表 cache
业务表别用——选 InnoDB。
ColumnStore
列式存储引擎，MariaDB 出品（fork 自 InfiniDB）。
特点
- 列式存储：同一列在磁盘上连续 → 聚合查询飞起
- 压缩 5–10×
- 大批量 INSERT 友好，单行更新性能差
- 分布式架构：一个 instance 可分布在多机
- MPP 查询引擎
适合
- OLAP（聚合、报表、BI）
- 数据仓库
- 配合 InnoDB 主表做归档
不适合
- OLTP
- 频繁单行更新
示例
CREATE TABLE orders_cs (
id BIGINT,
user_id BIGINT,
amount DECIMAL(10,2),
status VARCHAR(16),
created_at DATETIME
) ENGINE=ColumnStore;
-- 把热数据从 InnoDB 同步过来
INSERT INTO orders_cs SELECT * FROM orders WHERE created_at < NOW() - INTERVAL 90 DAY;
-- 聚合查询，比 InnoDB 快 10–100×
SELECT DATE(created_at) AS day, SUM(amount), COUNT(*)
FROM orders_cs
WHERE created_at BETWEEN '2025-01-01' AND '2025-12-31'
GROUP BY day;部署
ColumnStore 是分布式的，部署比单机 InnoDB 复杂：
# 单节点（开发）
docker pull mariadb/columnstore
docker run -d --name cs mariadb/columnstore
# 多节点：mcsAdmin assignDbroots ...或直接用 SkySQL 托管。
Spider
把多个 MariaDB 实例当成一个逻辑库，自动分片。
plugin_load_add = ha_spider-- 在协调节点上建分片表
CREATE TABLE orders (
id BIGINT,
user_id BIGINT,
-- ...
) ENGINE=Spider
COMMENT='wrapper "mysql", table "orders", srv "shard1 shard2 shard3"'
PARTITION BY HASH(user_id) (
PARTITION s1 COMMENT = 'srv "shard1"',
PARTITION s2 COMMENT = 'srv "shard2"',
PARTITION s3 COMMENT = 'srv "shard3"'
);应用看到的是普通表，Spider 自动路由到后端。
适合：水平扩展写吞吐。 坑：跨分片 JOIN 慢，事务跨分片不保证强一致。
CONNECT
连接外部数据源——CSV、XML、JSON、HTTP API、其他数据库。
-- 直接查 CSV
CREATE TABLE logs (
ts DATETIME,
level VARCHAR(8),
msg TEXT
) ENGINE=CONNECT
TABLE_TYPE=CSV
FILE_NAME='/data/logs.csv';
SELECT * FROM logs WHERE level = 'ERROR';
-- 直接查 PostgreSQL
CREATE TABLE pg_users
ENGINE=CONNECT
TABLE_TYPE=ODBC
CONNECTION='DSN=pg;...'
TABNAME='users';适合：临时跨源查询、ETL pipeline。
S3 Storage Engine
把表存到 S3，只读，做冷归档。
CREATE TABLE archive (
id BIGINT,
data JSON
) ENGINE=S3
s3_bucket='my-archive'
compression_algorithm='zstd';
INSERT INTO archive SELECT * FROM hot_data WHERE created_at < NOW() - INTERVAL 1 YEAR;存储成本极低，读时按需拉。
混合用：典型架构
+--------------------+
| Hot OLTP (InnoDB) | 30 天热数据，频繁读写
+--------+-----------+
|
| nightly ETL
v
+--------------------+
| Warm (MyRocks) | 30–365 天，省存储
+--------+-----------+
|
| yearly archive
v
+--------------------+
| Cold (S3 / ColumnStore) | 1 年以上，归档 + 聚合
+--------------------+选型 cheat sheet
- OLTP → InnoDB
- 写超多 + 存储贵 → MyRocks
- OLAP / 报表 → ColumnStore
- 分片 → Spider 或外置（Vitess 风格）
- 跨源查询 → CONNECT
- 冷归档 → S3 引擎 / ColumnStore