启动自托管服务器的动力，很多人始于"折腾一台机器、跑一堆服务"，但跑得越久越会意识到：几乎每个服务背后都离不开数据库——博客的文章、监控平台的状态、CI 的记录、网站的账号，全都落在一套关系型数据库里。而在自托管世界里使用最广泛、兼容最成熟、最"一个 Docker 就用"的关系库，非 MariaDB/MySQL 莫属。这篇讲清它们在自托管里的定位、装好后要做对的"存储、账号权限、时区与字符集、备份与恢复、慢查询与资源"几件事，以及作为"扛着数据的重服务"的现实边界。
一、为什么自托管绕不开 MariaDB/MySQL：它是很多服务的"默认存储"
关系型数据库（RDBMS）就是你那些"有结构、有关系的业务数据"的落点：用户、文章、任务、配置、状态历史，都能用表、外键、索引整齐建模。MariaDB 与 MySQL 一奶同胞（MariaDB 由 MySQL 的开源分支发展而来，二者兼容度高），几乎所有主流的 PHP/LAMP、WordPress、各类自托管应用都默认支持它们——这意味着"自托管某个应用"通常就意味着"搭一个 MariaDB/MySQL 给它用"。它是自托管栈里的"隐形地基"。
和前面讲过的 PostgreSQL（同为开源 RDBMS，功能更强、更适合复杂查询/高级类型）相比，MariaDB/MySQL 最大的优势是"生态与兼容"：大多数中小应用的官方安装向导默认对的就是它，插件、工具、文档最全，社区资料最多。选 PostgreSQL 还是 MariaDB/MySQL，通常不取决于"谁更高级"，而取决于"你这个应用最稳的是哪个"——很多流行应用两颗都支持，跟着应用官方推荐走最省心。理解这层，就不会陷入无谓的口水战。
二、最小落地：把数据库起来，并立刻做完基础卫生
自托管里最常见的做法是用 Docker 起一个 MariaDB/MySQL 容器，前端由应用或反代连接。部署本身不难，但有几件"装好就该立刻做"的卫生工作决定长期体验：设置强 root 密码并通过环境变量传入；把数据目录（`/var/lib/mysql`）挂到有快照/备份的磁盘；尽量不用 root 让应用连库，而是给每个应用建独立的最小权限账号。给一个 compose 示意：
# docker-compose.yml（示意：MariaDB 单实例）
services:
db:
image: mariadb:11
environment:
MARIADB_ROOT_PASSWORD: "换成一个强密码"
MARIADB_DATABASE: myapp
MARIADB_USER: myapp # 给应用用的专用账号，别用 root
MARIADB_PASSWORD: "应用专属强密码"
volumes: [ "./dbdata:/var/lib/mysql" ] # 数据挂到备份盘
ports: [ "127.0.0.1:3306:3306" ] # 别暴露到公网，只本地/私网
做对这三件能省掉大半隐患：一是"权限最小化"，每个应用各建各的库和账号（`GRANT` 只给该库该需要的权限），而不是所有人共用 root——这是很多自托管实例后患无穷的根源；二是"端口不裸公网"，数据库端口只监听本机或私网（拉了 3306 到公网等于开门等"爆库"），把对外访问收敛到应用层；三是"数据目录挂好盘"，让数据库文件落在可备份的存储上而不是系统盘。这三条在装的时候就立住，后面会顺得多。
三、时区、字符集与时间字段：别让小细节变成隐形脏数据
数据库用久了会遇到一些"说不清为什么数据怪"的问题，多半出在几个细节。一是"时区"：服务器默认时区（常是 UTC）与你的业务时区（如东八区）不一致时，时间字段会显示错位，最佳做法是让应用侧统一用 UTC 存取、展示时再转本地，或明确设好服务器时区一致性。二是"字符集"：建库/表的字符集若混用（`utf8mb3` 与 `utf8mb4` 混、或建表+连接字符集不一致）会造成中文乱码；现代实践是统一用 `utf8mb4`（支持 emoji 与全量 Unicode）。
# 建库时明确字符集与时区，避免中文乱码/时间错位
CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
# 会话/连接层面尽量保持一致，避免"存得了字，读出来乱"的时区字符集坑
自查的建议是"建库/建表起步就把字符集和时区设对"，并保持连接层一致，而不是等出问题再排查各层。把这类"小细节"当成"先把它定干净"的工程纪律，能让数据库在很长一段运行里不给你添这种最难调却最磨人的麻烦。真正出事时，你会发现它往往不是"性能问题"，而是"一开始没把时区/字符集这类地基约定好"。
四、备份与恢复：数据库是"丢了就回不来"的重资产
数据库是自托管里最"丢了即失"的数据，所以备份与恢复必须提前认真做。逻辑备份（`mysqldump`）简单可靠，适合中小库定期导出；恢复比备份更要在"恢复演练"上花时间——只备份从不测试恢复，等于把备份当心里安慰。绝佳实践是把 dump 交给备份工具（如 restic）加密归档并异地存放，并定期在测试环境跑一次完整恢复验证。
# 逻辑备份（示例，需配合系统 cron 定时 + 交给备份工具异地归档）
mysqldump --single-transaction --routines --triggers -u backup -p myapp > /srv/backup/myapp.sql
# 恢复（in 测试环境验证）：mysql -u root -p myapp < /srv/backup/myapp.sql
把数据库备份当成"业务级 SLA"来对待的几条：用 `--single-transaction` 做一致性备份、避免锁库；备份要有"时序保留"（留几份而非只留最新，避免某次备份本身坏了无后备）；最关键的是"定时恢复演练"，确保 `mysqldump` 出来的东西真能灌回去。数据库这份"看不见却最要命"的资产，只有"备份 + 起得来 + 常演练"三者齐全才算真安全。
五、慢查询与资源：数据多了以后"越来越慢"的对治
当表中数据量上涨，数据库查询会渐渐变慢，最常见的根因是"没建合适的索引"（全表扫描刷了大表）与"资源/配置不合适"。自托管规模未必需要到专业 DBA 那套，但有两件事值得掌握：一是检查慢查询，开启并查看慢查询日志/`EXPLAIN`，能定位"哪条查询在慢、有没有索引可加"；二是给数据库合理的资源（内存缓冲、合适的 `innodb_buffer_pool_size` 等）并监控磁盘与负载，别让它默默因为资源不足而越来越慢。
# 看一条慢查询是否缺索引：用 EXPLAIN 查看执行计划
EXPLAIN SELECT * FROM posts WHERE slug='hello';
# 常见优化方向：给高基数字段的查询/排序加索引；别对全表做无谓扫描
给自托管数据库的实用提醒：数据真的多到"明显变慢"再动索引与优化，别过早过度优化；在加索引前先用 `EXPLAIN` 看清它到底慢在哪。同时警惕"数据库是一条无界增长的河"——加上监控与磁盘告警，别让它默默把盘填满或在压力下把整台服务拖垮。把"备份 + 恢复 + 索引/资源治理"当成常规，数据库才能长期安稳地扛着你那堆自托管应用。
结语
MariaDB/MySQL 在许多自托管应用里是"默认存储地基"。落地要点：装好就用"最小权限账号 + 端口不裸公网 + 数据挂备份盘"立住卫生；建库/建表统一设 `utf8mb4` 与时区避免编码/时间坑；把 `mysqldump` 交给备份工具异地归档、并定期做恢复演练；数据多了再用 `EXPLAIN` 与慢查询定位、合理加索引与配资源，并加监控防盘满。认清它是"丢了即失、要长期喂养"的重资产后，它就会从"默默拖后腿的库"变成你自托管世界里稳定、可控、可回滚的数据信心。
