MariaDB 适合承载小型家庭服务的数据，但数据目录、字符集、账号和备份要从第一天定好。

\n
MariaDB 在 HomeLab 里很常见：很多小服务默认支持 MySQL/MariaDB，phpMyAdmin 又能提供一个临时管理入口。它方便，但也容易被随手部署成一坨：root 密码到处填、多个应用共用账号、字符集没定、备份只复制数据目录。数据库服务一旦进了长期运行清单，就要按资产来维护。

数据目录不要混在项目垃圾堆里

MariaDB 的 /var/lib/mysql 是核心数据目录，我会单独挂载到清楚的位置，例如 ./mariadb/data:/var/lib/mysql。这个目录不和缓存、日志、导出文件混放，也不放在容易被清理脚本扫到的临时目录。宿主机路径、容器路径、备份路径要写在同一份维护记录里。

数据库目录能帮助原机恢复，但它不等于万能迁移包。跨版本、跨架构或表损坏时，直接复制 data 目录不一定可靠。所以我会同时保留逻辑导出，例如 mysqldump 生成的 SQL 文件。data 目录像现场快照，SQL 导出像可迁移版本，两者用途不同。

services:
  mariadb:
    image: mariadb:11
    environment:
      MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
      TZ: Asia/Shanghai
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - ./mariadb/data:/var/lib/mysql
    networks:
      - backend

字符集初始化时就决定

中文内容、表情符号、文件名、用户昵称都可能进入数据库，所以我会在初始化阶段就设置 utf8mb4 和合适的 collation。等应用跑了一段时间再改字符集，往往牵涉表结构、连接参数和旧数据转换，风险比一开始写清楚大得多。

应用连接参数也要一致。数据库端设置了 utf8mb4，应用端连接串却没有声明，仍可能出现乱码或排序异常。遇到字符问题，我会同时看数据库变量、表字段字符集和应用连接配置，不只改其中一处。

应用账号不要共用 root

root 账号只用于初始化和必要维护，不给日常应用使用。每个应用单独数据库、单独账号、只授权它需要的库。这样一个应用配置泄露或误操作时，影响范围能被限制在自己的数据库里。家庭服务器虽然小，也不应该把所有服务都接在同一个管理员账号上。

phpMyAdmin 我只当临时工具。需要查看表或手工修复时再打开，结束后关闭或限制入口。它不适合长期暴露在普通入口上，更不应该越过账号分级直接成为“万能数据库面板”。如果确实长期保留，也要有独立认证、访问限制和日志。

我还会把应用账号授权语句保存到私有维护记录里，例如哪个账号只能访问哪个库、是否允许建表、是否允许修改结构。恢复到新机器时，账号权限能按记录重建，不需要临时给所有应用管理员权限来试错。

应用迁移时也要先看数据库迁移脚本。有些服务升级会自动改表结构，回滚镜像后旧程序未必能读新表。升级前留导出，升级后确认关键表和应用页面都正常，再把旧备份降级到长期归档。

不要省这一步。

备份要包含恢复演练

我的数据库备份至少包含三件事：定期 SQL 导出、升级前 data 目录快照、恢复演练记录。导出文件要带日期、库名和校验值；恢复演练要在临时 MariaDB 容器里完成，而不是覆盖运行库。只有能恢复出来的备份，才算真正可用。

常用检查命令包括 docker compose logs mariadb 看启动和崩溃恢复，mysqladmin ping 看服务可达，mysqldump --single-transaction 做在线导出。升级前要读镜像变更，尤其是主版本变化；升级后先跑应用启动和关键页面，再清理旧备份。

MariaDB 加 phpMyAdmin 可以很轻量，也可以因为随手配置变成长期隐患。数据目录放稳、字符集定好、应用账号分开、备份能恢复，这四件事比页面能登录更重要。数据库不是演示容器，它保存的是家庭服务真正的运行事实。