先给一个锚点。我实测一台 2 核 2G 的云主机，上面跑着 nginx、Redis 和两个 Go 服务，MariaDB 的进程 RSS 是：

mysql  14.5%  291932 KB  /usr/libexec/mariadbd

285 MB，是这台机器上最大的单个进程。而整机 available 只有 1.1 G。换句话说，你还没开始跑业务，数据库已经拿走了四分之一的可用余量。

选型的真正依据：写入量 ≈ 请求量

在动手比较之前，先想清楚 API 中转站的负载长什么样，否则比较是没有意义的。

• 读：API key 校验、用户配置、配额查询。数据量小、可缓存、频率高——三种数据库都轻松应对，不构成差异。
• 写：每次请求落一条用量/计费记录。这是全部的关键：写入速率基本等于请求速率。

所以问题可以化简成一句：你每秒有几次请求？

大多数个人自建的中转站落在第一档，很多人却直接上了 MySQL——在小机器上这笔开销是白花的。

三种数据库的内存画像

并发写入模型的差异

SQLite：如果选它，这几个 pragma 不能少

默认配置的 SQLite 在并发场景下表现很差，而这常被误当成"SQLite 不能上生产"的证据。实际要配的就几行：

PRAGMA journal_mode = WAL;      -- 读写不再互相阻塞。默认的 delete 模式才是性能灾难
PRAGMA busy_timeout = 5000;     -- 遇锁等 5 秒而不是立刻报 SQLITE_BUSY
PRAGMA synchronous = NORMAL;    -- 配合 WAL 的合理折中
PRAGMA foreign_keys = ON;       -- 默认是关的，很多人不知道
PRAGMA cache_size = -32000;     -- 负数表示 KB，这里约 32 MB

其中 busy_timeout 是最容易漏、后果最直接的一条。不配它，两个并发写会有一个立刻收到 SQLITE_BUSY 失败——表现出来就是"偶发写入失败"，而你会以为是 SQLite 不稳定，其实只是它在如实告诉你"锁被占了"，而你没让它等。

synchronous = NORMAL 的取舍要说清：配合 WAL 时它能抵御应用崩溃，但操作系统崩溃或断电可能丢掉最近几个已提交事务。对用量日志这种损失几条可接受的数据没问题；如果这张表直接用于扣款对账，就该用 FULL。

备份不能直接 cp。 WAL 模式下 -wal 文件里有还没合并进主库的数据，直接复制主文件会拿到一个不一致的快照：

# ✓ 正确
sqlite3 /path/to/app.db "VACUUM INTO '/backup/app-$(date +%F).db'"

# ❌ 错误：WAL 模式下这样拷出来的库可能缺最近的写入
cp /path/to/app.db /backup/

MySQL / MariaDB：小机器上的调优

如果已经在用 MySQL 系，285 MB 是可以压下来的：

[mysqld]
# 关掉它就能省几十 MB，个人站几乎不需要
performance_schema = OFF

innodb_buffer_pool_size = 96M
innodb_buffer_pool_instances = 1    # 池子小的时候拆成多个实例反而浪费
innodb_log_file_size = 32M

# 每个连接都要分配缓冲区，这个数不是免费的
max_connections = 30

key_buffer_size = 8M
tmp_table_size = 16M
max_heap_table_size = 16M

performance_schema = OFF 是性价比最高的一条——它默认开启，为性能诊断收集大量数据，而个人站基本用不上。代价是出问题时少了一套诊断视图，需要时再临时打开即可。

max_connections = 30 看着很小，但要算清楚：中转程序的连接池通常配 10–20，加上你偶尔用客户端连进去看数据，30 足够。这个数配成 151（默认值）不会立刻占用内存，但它决定了内存占用的上限，在没有 swap 的机器上等于把 OOM 的可能性留在了那里。

PostgreSQL：注意它是进程模型

PostgreSQL 和 MySQL 最大的运维差异在这里：每个连接是一个独立的操作系统进程，不是线程。 所以连接数对内存的影响比 MySQL 显著得多。

shared_buffers = 128MB          # 通用建议是内存的 25%，但共享机器上别照抄
max_connections = 20            # 进程模型下这个数很值钱
work_mem = 2MB                  # 注意：单次查询可能同时用掉好几份
maintenance_work_mem = 32MB
effective_cache_size = 512MB    # 这只是给优化器的提示，不实际占用

work_mem 有个容易踩的坑：它是每个排序/哈希操作的上限，不是每个连接的上限。一个复杂查询里有多个排序节点时会各分配一份，并发多个这样的查询，内存就会超出直觉。小机器上宁可配小，让它落盘排序。

如果应用的连接池配得比较大，考虑在前面加 pgbouncer 做连接复用——但这又是一个常驻进程，在 2G 机器上要权衡它值不值。

比选型更要紧的问题：日志表会无限长大

这是本文最想强调的一点。无论你选哪个数据库，真正会在半年后咬你的是用量日志表。

机制很简单：每个请求写一行，从不删除。按前面的换算：

• 10 req/s → 每天 86 万行 → 一年约 3.1 亿行
• 每行假设 300 字节 → 一年约 90 GB

后果不是"磁盘满了"这么简单，而是一连串的连带效应：查询变慢 → 管理后台的用量统计页面开始超时 → 备份时间越来越长 → 最后磁盘真的满了，而磁盘满会让数据库直接拒绝写入，整个中转站停摆。

所以从第一天就该有保留策略：

-- 最朴素但有效：定期删除旧数据 + 保留聚合结果
DELETE FROM logs WHERE created_at < NOW() - INTERVAL 90 DAY;

-- 删之前先把要长期保留的口径聚合出来
INSERT INTO usage_daily (day, user_id, model, requests, tokens)
SELECT DATE(created_at), user_id, model, COUNT(*), SUM(total_tokens)
FROM logs
WHERE created_at < NOW() - INTERVAL 90 DAY
GROUP BY 1, 2, 3;

两点提醒：

• 大表上的 DELETE 本身就是个事故来源。 一次删几千万行会长时间持锁、把 binlog/WAL 撑爆。要分批删（每次几千行、中间 sleep），或者用按时间分区的表直接 DROP PARTITION——后者是从一开始就该做的设计。
• SQLite 删完记得 VACUUM，否则文件大小不会回落（空间被标记为可复用但不归还给文件系统）。注意 VACUUM 需要与库等大的临时空间，磁盘快满时反而做不了——所以别等到那时候。

决策建议

最后一条实践建议：先从 SQLite 开始不是妥协。 但要知道 SQLite → MySQL 的迁移不是无痛的——SQLite 是动态类型（type affinity），日期存储没有原生类型，AUTOINCREMENT 语义也不同。如果你已经能预见到半年内会上多实例，那一开始就选 MySQL 或 PostgreSQL，省掉一次迁移。

相关阅读

• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 那台机器 285 MB 的 MariaDB 实测数据出自这里
• 大模型 API 中转的超时与重试：一次 504 可能让你双倍计费 —— 用量日志正是核对重复计费的依据
• Caddy 还是 nginx 给 API 中转做反代：证书自动化是决定性差异 —— 同一台小机器上的另一项运维取舍

这篇文章不谈"Docker 好还是不好"，只回答一个具体问题：在小内存机器上，这几百 MB 的差价花得值不值。

先看一台真实 2G 机器的内存都被谁吃了

大多数部署教程会告诉你"new-api 占用很小"，这话没错，但它回答的不是你真正要问的问题。下面是我手上一台腾讯云 2 核 2G / CentOS Stream 9 机器的实测数据，已连续运行 34 天，跑着 nginx、MariaDB、Redis 和两个自己写的 Go 服务：

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       613Mi        74Mi       7.0Mi       1.2Gi       1.1Gi
Swap:            0B          0B          0B

按进程 RSS 排出来的大户：

这里有个细节要说清楚，否则数字看着不自洽：上面各进程 RSS 加起来（约 691 MB）大于 free 报的 used（613 MB），这不是我算错了。RSS 会把进程间共享的内存页（共享库、写时复制的父子页）在每个进程里各算一遍，所以 RSS 求和天然偏高。判断"还剩多少能用"要看 available，判断"谁是大户"才看 RSS。

从这张图能得出两个结论，它们直接决定选型：

1. 系统底噪比应用大得多。 journald 200 MB、两个云厂商 agent 合计 120 MB、rsyslogd 60 MB —— 这些你一行代码没写就已经存在了。
2. 可用余量只有 1.1 G，且没有 swap。 这意味着任何一次内存尖峰都直接触发 OOM killer，没有降级缓冲。

裸二进制方案的实际构成

new-api 是 Go 编译的单体，部署形态非常简单：

systemd
├── new-api            单二进制，Go 运行时
├── mariadbd           本机数据库
└── caddy / nginx      反向代理 + TLS

一个够用的 systemd unit：

[Unit]
Description=new-api
After=network-online.target mariadb.service
Wants=network-online.target

[Service]
Type=simple
User=newapi
WorkingDirectory=/opt/new-api
ExecStart=/opt/new-api/new-api --port 3000 --log-dir /var/log/new-api
Restart=always
RestartSec=5

# 小内存机器上值得加的两道保险
MemoryMax=512M
OOMPolicy=continue

[Install]
WantedBy=multi-user.target

MemoryMax 这行是小内存机器的关键：给应用设一个上限，让它在自己超标时被 cgroup 限制住，而不是把整机推向 OOM、让内核随机挑一个进程杀——被杀的往往是内存占用最大的 MariaDB，那就是数据库直接下线。

代价要讲清楚，裸二进制不是没有成本的：

• 升级是手动的：下载新二进制、systemctl stop、替换文件、systemctl start，回滚要自己留旧版本
• 没有进程隔离，应用和宿主机共享一切
• 依赖宿主机的 glibc 版本，跨发行版迁移可能编译不兼容（Go 静态编译能规避大部分，但 CGO 开启时不行）
• 数据库、缓存的版本管理全靠宿主机包管理器

Docker 方案多出来的常驻开销

把这 120–220 MB 放回前面那张图里看：可用内存 1126 MB，Docker 一上来先拿走两成，剩下的才是留给 new-api、Postgres 和 Redis 的。在 4G 机器上这笔账无所谓；在 2G 机器上它就是压垮骆驼的那根稻草。

Docker 换来的东西也是真的，别因为省内存就否定它：

• 升级是 docker compose pull && docker compose up -d，回滚是改个 tag
• 环境完全一致，本地能跑线上就能跑
• 数据库、Redis 的版本与宿主机解耦，不用跟发行版的包管理器较劲
• 多实例、多环境并存很容易

决策建议

两个几乎所有人都忽略的内存大户

journald 默认没有上限

前面实测里 systemd-journald 占了 200 MB，这不是异常，是默认行为——它会一直增长到磁盘配额上限。小内存机器上值得直接压掉：

# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=200M
RuntimeMaxUse=50M

改完 systemctl restart systemd-journald。如果你的服务日志已经写到文件并由 logrotate 管，journald 里那份基本是重复的。

云厂商 agent

实测里 YDService（主机安全）加 barad_agent（监控）合计约 120 MB。这些是装系统镜像时预置的，你未必需要全部。要不要关取决于你的取舍：关掉监控 agent 会失去云控制台的监控图表，关掉安全 agent 会失去入侵检测告警。在 2G 机器上这 120 MB 确实值钱，但别为了省内存把安全能力一起关掉——如果你的机器上有数据库对外暴露，那点内存远不如告警重要。

无 swap 是这类机器的隐藏地雷

前面实测数据里 Swap: 0B。云主机默认不带 swap，而 2G 机器最需要它——不是为了性能，是为了在内存尖峰时有个降级路径,而不是直接被 OOM killer 杀掉。

# 加 1G swapfile
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# 小内存机器上把 swappiness 调低，只在真的紧张时才用
sysctl -w vm.swappiness=10

代价是数据库一旦被换出磁盘，性能会明显下降。但"慢"永远好过"被杀"。

相关阅读

部署完成后，反向代理的配置有两个坑几乎人人会踩，我单独写了：

• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 流式输出变成一次性返回，问题通常不在应用
• API 中转站的限流为什么不能信 X-Forwarded-For —— 这个头客户端能自己塞，按它限流等于没限

而本文里那个占 285 MB 的 MariaDB，本身也是个可以重新选的决定：

• 给 API 中转站选数据库：SQLite / MySQL / PostgreSQL 在小机器上的取舍 —— 换成 SQLite 能把这 285 MB 整个省掉，代价是写并发上限