低配服务器承载小型业务，精简MySQL配置还是迁移到SQLite更合适？

低配服务器承载小型业务时，通常不应一开始就把 MySQL 换成 SQLite，也不应盲目把 MySQL 的所有参数压到最低。更稳妥的顺序是：先确认业务是否真的需要 MySQL 的并发能力，再收紧连接数、缓存和临时表内存；只有当业务天然是单机、低写入并发、可以接受文件型数据库限制时，迁移到 SQLite 才更合适。

如果现有程序已经使用 MySQL，且存在多个应用进程、后台管理、定时任务或多个客户端同时写入，优先保留 MySQL。若业务只有一个应用实例，数据文件放在本机，写入请求很少，且迁移成本可控，SQLite 可以减少数据库服务本身的内存占用和维护工作。

先确认业务必须满足的条件

选择方案前，先把“必须满足”和“以后可以增加”分开。小型业务通常必须满足以下条件：

• 数据不能因进程重启或服务器重启而随意丢失。
• 多个请求同时读取时，页面不能频繁等待数据库锁。
• 订单、库存、账务等需要保持一致性的操作必须使用事务。
• 需要有可验证的备份和回滚路径。
• 数据库调用不能因为连接数过多拖垮应用进程。

以下能力则可以后续增加：

• 更大的连接池。
• 更复杂的报表查询。
• 更高的写入并发。
• 读写分离或多实例部署。
• 更细的监控和自动化备份。

如果当前业务已经依赖这些扩展能力，SQLite 的低内存优势通常无法抵消改造和并发限制带来的代价。

先检查当前 MySQL 是否真的被配置拖慢

不要只根据服务器内存小就迁移数据库。先查看操作系统和 MySQL 的实际状态：

free -h
nproc
df -h
mysql --version

登录 MySQL 后，查看连接、缓存和临时表情况：

SHOW VARIABLES
WHERE Variable_name IN (
  'max_connections',
  'innodb_buffer_pool_size',
  'tmp_table_size',
  'max_heap_table_size',
  'table_open_cache'
);

SHOW GLOBAL STATUS
WHERE Variable_name IN (
  'Threads_connected',
  'Threads_running',
  'Max_used_connections',
  'Created_tmp_tables',
  'Created_tmp_disk_tables',
  'Innodb_buffer_pool_reads',
  'Innodb_buffer_pool_read_requests'
);

这些结果需要结合一段时间观察，不能只看一次：

• Max_used_connections 长期接近 max_connections，说明连接限制可能过低，也可能是应用没有正确复用连接。
• Threads_connected 很高但 Threads_running 很低，通常是空闲连接较多，不一定代表查询压力大。
• Created_tmp_disk_tables 持续增长，可能是排序、分组或临时表内存不足，也可能是查询本身需要优化。
• Innodb_buffer_pool_reads 与 Innodb_buffer_pool_read_requests 都是累计值，应在固定时间间隔记录两次再比较，不能拿单个数值直接判断性能。
• 服务器出现交换分区增长、进程被系统终止或频繁内存不足时，才说明当前内存分配确实需要收紧。

保留 MySQL 时的最小优化方案

先备份，再调整持久配置

配置文件路径会因发行版和安装方式不同而变化，先查看 MySQL 默认读取的配置位置：

mysqld --verbose --help 2>/dev/null | grep -A 1 "Default options"

也可以检查常见目录：

ls -l /etc/mysql/ 2>/dev/null
ls -l /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null

确定实际生效的配置文件后，先复制备份。下面的路径仅作为示例，执行时替换成实际文件：

sudo cp --preserve=mode,ownership \
  /etc/mysql/mysql.conf.d/mysqld.cnf \
  /etc/mysql/mysql.conf.d/mysqld.cnf.bak-20261002

如果备份文件不存在或权限不正确，不要继续覆盖原配置。配置调整涉及数据库重启，最好安排短暂维护时间，并提前确认应用具备重连能力。

对于应用和 MySQL 共用约 512 MB 内存的轻量环境，可以从下面这组保守值开始：

[mysqld]
innodb_buffer_pool_size = 128M
max_connections = 30
thread_cache_size = 8
table_open_cache = 512
tmp_table_size = 16M
max_heap_table_size = 16M
innodb_log_buffer_size = 8M

这些不是固定承载上限，而是用于控制内存风险的起点：

• innodb_buffer_pool_size 太小，会增加磁盘读取；太大，则可能挤压应用、系统和连接线程的内存。
• max_connections 不是越大越好。每个活跃连接都可能消耗线程栈、排序缓冲区和临时空间。应用连接池如果设置为 8，通常没有必要把 MySQL 连接数直接设为几百。
• tmp_table_size 与 max_heap_table_size 一起限制内存临时表的大小。过大时，多个并发查询可能同时申请大量内存；过小则会增加磁盘临时表。
• table_open_cache 主要减少频繁打开表的开销，轻量业务不需要设置得很高。
• innodb_log_buffer_size 对普通小型业务保持较小值即可，不应为了追求“更大缓存”而牺牲系统内存。
• 不要在 MySQL 8.0 环境中照搬旧教程配置查询缓存；该功能已不适合作为通用优化手段。

如果服务器内存约为 1 GB，且应用和其他常驻服务占用较少，可以把缓冲池起点提高到 256M 或 384M，连接数从 30 调整到 40～60，但仍应以 Max_used_connections 和实际内存曲线为依据。配置越大不等于查询一定越快。

检查配置并重启验证

如果当前版本支持，可以先验证配置文件：

sudo mysqld --validate-config

部分发行版的服务名是 mysql，也有系统使用 mysqld。先查看实际服务名：

systemctl list-unit-files --type=service | grep -E '^(mysql|mysqld)\.service'

维护窗口内重启服务：

sudo systemctl restart mysql
sudo systemctl status mysql --no-pager

如果系统显示的服务名是 mysqld，将上面的 mysql 替换为 mysqld。重启失败时，不要继续修改更多参数，先查看日志：

sudo journalctl -u mysql -n 80 --no-pager

确认服务异常的原因后，恢复之前的配置备份，再重启服务。回滚的影响是数据库会再次短暂中断，但比在未知状态下反复修改配置更安全。

重启成功后重新确认参数：

SHOW VARIABLES
WHERE Variable_name IN (
  'innodb_buffer_pool_size',
  'max_connections',
  'thread_cache_size',
  'table_open_cache',
  'tmp_table_size',
  'max_heap_table_size'
);

比改参数更重要的是减少无效数据库调用

低配环境中，查询次数和查询方式经常比单个缓存参数更影响响应时间。优先处理以下问题：

1. 列表页不要使用 SELECT *，只读取页面真正需要的列。
2. 对经常出现在 WHERE、JOIN、ORDER BY 中的字段检查索引。
3. 联合索引要根据实际过滤顺序设计，不能只给每个字段分别建立索引。
4. 分页数据量较大时，避免长期使用大偏移量，例如 LIMIT 100000, 20。
5. 多条写入尽量放在一个明确的事务中，避免每写一行就提交一次。
6. 应用连接池保持较小规模，避免每个请求都新建数据库连接。
7. 对重复读取且变化不频繁的数据，在应用层做短时间缓存，但不要因此取消数据一致性检查。

使用 EXPLAIN 查看查询是否用到合理索引：

EXPLAIN
SELECT id, title, status, created_at
FROM orders
WHERE user_id = 1001
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

如果结果中的访问类型长期是全表扫描，或者估算扫描行数远大于最终返回行数，先优化 SQL 和索引，再考虑扩大内存。EXPLAIN 只是执行计划分析，不代表已经完成真实性能验证；修改索引后仍要用接近真实的数据量和请求方式测试。

迁移到 SQLite 前必须满足的条件

SQLite 没有独立的数据库服务进程，数据主要保存在一个文件中。因此，它能减少 MySQL 服务、连接管理和部分常驻内存开销，但并不是“更快的 MySQL”。它更适合以下情况：

• 应用和数据库运行在同一台服务器。
• 业务主要是读取，写入请求少且每次写入时间很短。
• 只有一个主要应用，或者多个进程之间不会产生持续写入竞争。
• 不需要多个服务器同时访问同一个数据库文件。
• 应用可以适配 SQLite 的 SQL 语法、类型和锁行为。
• 业务能够接受维护一个数据库文件，并建立文件级备份流程。

以下情况应保留 MySQL：

• 多个应用实例或多个后台任务会同时写入。
• 订单、库存、支付状态等写入连续发生，不能接受写入排队。
• 已经使用大量 MySQL 特有语法、存储过程或复杂数据库逻辑。
• 需要远程客户端直接访问数据库服务。
• 预计业务很快会从单机扩展到多进程、多节点或更高并发。
• 团队已经具备 MySQL 的备份、监控和故障处理流程，而迁移收益只是节省少量内存。

SQLite 在 WAL 模式下可以让读取和写入更好地并行，但同一时刻仍然只有一个写入者。写事务持续时间越长，其他写请求等待锁的时间越长。因此，SQLite 的关键限制不是“不能多用户读取”，而是“写入并发和写事务持续时间有限”。

SQLite 的最小部署和验证步骤

先创建备份路径和数据库副本

迁移前必须保留 MySQL 原库，并在切换前停止写入或进入维护模式。一个简单的小型业务迁移，通常采用“停止写入、导出、转换、验证、切换”的方式，而不是一开始就做双写。

MySQL 逻辑备份示例：

mkdir -p /srv/backup/mysql

mysqldump -u backup_user -p \
  --single-transaction \
  --quick \
  --triggers \
  --databases appdb \
  > /srv/backup/mysql/appdb-20261002.sql

--single-transaction 适用于主要使用 InnoDB 的库，可在不长时间锁表的情况下生成一致性备份；如果数据库中存在非事务表，仍需根据业务写入情况安排维护窗口。备份完成后先检查文件大小和末尾内容，不要只看命令是否返回成功。

创建 SQLite 文件前，确保应用暂时不会写入目标路径：

mkdir -p /srv/app/data
mkdir -p /srv/backup/sqlite

如果目标 SQLite 文件已经存在，先用 SQLite 的备份接口生成新副本，不要在业务写入期间直接复制主数据库文件：

sqlite3 /srv/app/data/app.db \
  ".backup '/srv/backup/sqlite/app-before-change.db'"

初始化 SQLite 连接参数

SQLite 的部分参数是连接级设置，应用每次建立连接时都应执行，不能只在命令行中执行一次：

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;
PRAGMA busy_timeout = 5000;

这些参数的含义如下：

• WAL 可以改善读取与写入同时发生时的体验，但会产生 -wal 和 -shm 文件。
• synchronous=NORMAL 在 WAL 模式下通常能减少同步开销，但如果业务更重视断电时最近事务的保留，应使用 FULL，并接受更高的写入开销。
• foreign_keys=ON 必须在每个连接上设置，否则外键约束可能没有按预期生效。
• busy_timeout=5000 表示遇到锁时最多等待约 5 秒，单位是毫秒。它只能缓解短暂竞争，不能解决持续写入冲突。

备份 WAL 模式的数据库时，优先使用 SQLite 的备份接口，或调用应用驱动提供的备份 API。不要只复制主 .db 文件后就认为备份完整，尤其是在数据库仍有活动写入时。

迁移时不要直接导入 MySQL SQL 文件

MySQL 导出的建表语句通常包含反引号、AUTO_INCREMENT、UNSIGNED、ENUM、日期函数或 MySQL 特有的 UPSERT 语法，不能直接交给 SQLite 执行。迁移应分为结构转换和数据复制两部分。

常见类型可以按下面的思路处理：

迁移脚本应使用参数化插入，并按批次提交。例如每批处理几百到几千行，具体大小取决于单行数据量和内存。不要把所有数据一次性读入应用内存，也不要每行单独提交。

迁移完成后，至少比较以下内容：

-- MySQL 和 SQLite 中分别执行
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;
SELECT MIN(id), MAX(id) FROM orders;

对于金额、数量等关键字段，再比较总和：

SELECT COUNT(*), SUM(amount_cents)
FROM orders
WHERE status = 'paid';

如果 MySQL 中使用的是小数金额，迁移后不能简单依赖二进制浮点数比较，应在应用中按统一的小数规则或最小货币单位核对。

SQLite 侧完成导入后执行：

PRAGMA foreign_keys = ON;
PRAGMA integrity_check;
PRAGMA quick_check;

返回 ok 只能说明数据库结构和页面检查通过，不能证明业务语义已经正确。还需要登录、下单、修改状态、查询列表、后台筛选等真实业务流程测试。

迁移失败时，最简单的回滚方式是在新数据产生前，把应用数据库连接重新指向 MySQL，保留 SQLite 文件供分析，不要立即删除。若切换后已经有新写入，则回滚前必须处理这段时间产生的数据，否则可能出现数据倒退或重复。

两种方案的同口径比较

从资源角度看，SQLite 往往更轻；从并发、兼容性和后续扩展角度看，精简后的 MySQL 更稳。不能只用“数据库进程占用多少内存”这一项决定方案，还要把迁移开发、测试、备份和故障回滚成本计算进去。

出现这些表现时，分别如何处理

MySQL 仍然适合，但需要继续优化

如果页面大多数时间正常，只有少数查询慢，优先检查执行计划和索引。若连接数不高但内存不足，继续收紧单连接临时内存，并确认应用是否存在连接泄漏。

如果 Created_tmp_disk_tables 增长很快，先检查排序和分组查询是否读取了过多列；不要直接把 tmp_table_size 调到很大。若 Threads_running 长时间较高，查看是否有未提交事务、全表扫描或锁等待。

如果服务器开始使用交换空间、MySQL 被系统终止，或者数据库和应用争抢内存，应先降低连接并发、减少缓冲池，再根据观察结果增加可用资源。单纯迁移到 SQLite 不一定解决问题，因为低效查询和大量无效调用仍然存在。

SQLite 开始出现并发瓶颈

常见表现包括：

• database is locked 或频繁超时。
• 写入请求排队，页面延迟随着后台任务增加。
• 某个事务打开时间过长，导致其他写入无法继续。
• WAL 文件持续增长，检查点长期无法顺利完成。
• 多个进程同时修改相同数据时出现大量重试。

处理顺序应是先缩短事务，避免在事务中执行网络请求、文件处理或复杂计算；再确认每个连接都设置了 busy_timeout，并检查是否存在未关闭的事务。不要简单地把等待时间从 5 秒改成几分钟，因为这只会把锁竞争转化为更长的请求堆积。

当业务出现持续写入、多个应用进程同时修改数据、后台任务和用户请求互相影响时，就达到迁回或保留 MySQL 的触发条件。此时 MySQL 的服务开销，通常已经低于 SQLite 锁竞争带来的改造和排障成本。

最终选择标准

可以按下面的条件做决定：

• 已有 MySQL、业务代码改动少、存在并发写入：保留 MySQL，先调整缓冲池、连接数、临时表限制和查询调用。
• 单机应用、低写入并发、数据量不大、希望减少服务维护：可以评估 SQLite，但必须完成 SQL 兼容性改造、备份和回滚测试。
• 只是因为服务器内存紧张而考虑迁移：先检查连接泄漏、慢查询、索引和单连接内存，配置优化的风险通常低于数据库迁移。
• 已经出现 SQLite 锁等待或写入排队：不要继续依赖调大超时时间，应重新评估 MySQL。
• 业务包含订单、库存或其他连续写操作，且未来会增加后台任务：优先保留 MySQL，为后续并发留出余量。

因此，低配服务器上的默认路径是“先精简 MySQL，再根据业务模型决定是否迁移”，而不是直接把 MySQL 替换为 SQLite。只有当业务确实符合单机、低写入并发、文件型存储和可控迁移这几个条件时，SQLite 的轻量优势才足以覆盖迁移成本。