小型服务器数据库选型与优化

小型服务器数据库选型与优化

以2C2G（2核2GB内存）的小型VPS为例。

1. 结论

针对 2GB 内存环境，且需要兼容 MySQL 数据/代码的场景，推荐优先级如下：

优先级 方案名称 适用场景 关键优势 备注
No.1 (首选) MariaDB 10.x 通用/老项目迁移 完全兼容 MySQL 协议；比 MySQL 8.0 更省内存；性能更优。 推荐方案。无需修改代码，直接替换。
No.2 MySQL 5.7 必须用官方版时 经典稳定，内存占用适中。 需手动优化配置防止崩溃，且从2023年起已结束生命周期。
No.3 SQLite 极简/单机应用 0 内存占用，无需服务进程。 适合无并发压力的个人项目，迁移需转换数据格式。
禁止 MySQL 8.0 - 默认配置极吃内存，2G 环境极易内存溢出。 除非极其精细地调优，否则不建议使用。

2. 系统级优化：虚拟内存 (Swap)

详见 LinuxSwap。

3. 安装与部署

3.1 关于面板环境

由于服务器使用了面板管理（如宝塔），切勿直接通过命令行安装数据库以及安装Docker类型的数据库

一是面板可能无法识别管理 Docker 内/本机直接安装 的数据库服务， 二是不用Docker，数据库进程可以直接跑在系统上，少了一层 Docker 的虚拟化和网络转发开销。

选择普通安装版本(软件商店名：MySQL是一种关系数据库管理系统!(支持MySQL(5.x/8.x/9.x)/alisql/greatsql/mariadb))。

3.2 关于安装方式

  • 登录 面板后台 (如宝塔)。
  • 进入 软件商店。
  • 选择 MariaDB (推荐) 或 MySQL 5.7 。
  • 至于编译安装和极速安装，建议选择 极速安装，因为编译安装会占用大量内存和 CPU 资源，且编译时间较长，容易导致服务器卡顿甚至服务中断。同时编译安装虽然可以自定义一些编译选项，但对于大多数用户来说，默认的极速安装已经足够使用，且更稳定可靠，提升的性能在 2GB 内存的服务器上并不明显。
  • 按照提示完成安装。

3.3 关于内存优化方案

  1. 安装完成后，可以在管理界面选择1-2G内存的优化方案。
  2. 根据管理界面的性能状态调整配置参数，如连接数、缓存大小等。

4. 数据库设置

4.1 数据库密码

数据库本身是没有密码的，只有“用户”才有密码。

特性 Root 密码 (万能锁) 单独数据库用户密码 (单间锁)
它是谁的密码？ 超级管理员 root 普通用户 (如 web_user)
能操作谁？ 所有数据库 (A库, B库, C库…) 仅限指定的那个数据库 (A库)
安全性 极高风险。如果泄露，影响所有数据。 安全。如果泄露，只影响这一个库。
设置里填哪个？ 必须填 Root 密码。 不需要填，进系统以后再创建。
  1. 先用 root 密码登录进数据库（或者通过宝塔界面）。
  2. 创建一个叫 xxx 的新用户，设置一个新密码。
  3. 然后使用这个新用户和密码，连接要用的那个程序连接。

附录

MariaDB 与 MySQL 对比

在 Client-Server（客户端-服务器） 架构的数据库中，MariaDB 是目前 MySQL 最主流、最轻量且开源精神最纯粹 的“完全兼容”替代品。它是 MySQL 之父 Michael Widenius 在 MySQL 被 Oracle 收购后，为了防止其闭源而创立的分支。虽然说是“完全兼容”，但随着 MySQL 8.0 和 MariaDB 10.x/11.x 的各自发展，两者在某些高级特性上已经出现了分叉。

以下是详细的对比分析和表格。

核心对比总结表

特性维度 MySQL (Oracle) MariaDB (开源社区) 谁更胜一筹？
开发者/维护者 Oracle 公司 MariaDB 基金会 (开源社区驱动) MariaDB (更开放，响应更快)
开源协议 GPL + 商业闭源部分 GPL (完全开源) MariaDB (无商业锁定风险)
线程池 (Thread Pool) 仅企业版 (收费) 提供 所有版本内置，默认可用 MariaDB (高并发下性能关键)
存储引擎 主要依赖 InnoDB, MyISAM InnoDB + Aria, MyRocks, Spider, ColumnStore 等 MariaDB (引擎更丰富，Aria 优化了临时表)
内存占用 (轻量级) 8.0 版本后内存占用显著增加 相对更低，优化了连接开销 MariaDB (更适合中小内存服务器)
JSON 支持 原生 JSON 数据类型 (二进制存储) JSON 作为 TEXT 的别名，通过函数解析 MySQL (原生支持更好)
复制 (Replication) GTID (Oracle 独有实现) GTID (与 MySQL 不兼容的实现), Galera Cluster 平手 (但互不兼容)
更新频率 较慢，以稳定性为主 较快，新特性合入迅速 MariaDB (功能迭代快)

为什么说 MariaDB 是更好的选择？

1. 真正的“轻量”与高性能
  • 内存管理： MySQL 8.0 为了在大规模企业级硬件上运行，增加了很多默认的内存开销。相比之下，MariaDB 在默认配置下对内存更友好，在 512MB - 4GB 内存的 VPS 上，MariaDB 的运行往往比 MySQL 8.0 更流畅。
  • 查询优化器： MariaDB 的查询优化器与 MySQL 已经分道扬镳。在很多复杂的 Join 查询和子查询场景下，MariaDB 的优化策略通常比 MySQL 更智能，执行速度更快。
  • 线程池技术： 这是最大的区别之一。MySQL 社区版使用“一个连接一个线程”的模型，高并发下上下文切换开销巨大，Oracle 把高效的“线程池”功能锁在了收费的企业版里。而 MariaDB 免费内置了线程池，这使得它在高并发场景下的吞吐量远超 MySQL 社区版。
2. 存储引擎的黑科技

MariaDB 引入了一个名为 Aria 的引擎（以前叫 Maria）。

  • 在 MySQL 中，内部临时表通常使用 MyISAM 或 Memory 引擎，容易崩溃或受限于内存。
  • MariaDB 使用 Aria 作为默认的内部临时表引擎，它支持崩溃恢复且缓存机制更高效，这让复杂的 GROUP BY 或 DISTINCT 查询在 MariaDB 上往往更快。

迁移注意事项

虽然 MariaDB 即插即用替换，但在以下场景需注意：

  • 二进制文件不兼容： 不能直接把 MySQL 8.0 的 data 目录复制给 MariaDB 用，必须通过 mysqldump 导出导入。
  • JSON 处理： 如果业务极度依赖 MySQL 8.0 的原生二进制 JSON 字段及其特定的索引优化，迁移到 MariaDB 可能需要调整，因为 MariaDB 将 JSON 视为文本处理（虽然提供了完全兼容的 JSON 函数集，但底层实现不同）。
  • GTID 复制： 两者的全局事务 ID（GTID）实现机制完全不同。如果在做主从复制，不能混用 MySQL 主和 MariaDB 从。