接到这种需求已经很多次了新项目要上线机器是现成的 CentOS/Ubuntu让我在服务器上把 MariaDB 搭起来。会点的人都觉得简单但实际操作下来坑其实不少——root 密码怎么设、远程连不上、时区不对、备份不知道怎么恢复每一个都能让人折腾到半夜。这篇文章就是把我平时在服务器上部署和维护 MariaDB 的完整过程整理出来从安装、设密码、调参、排错到备份迁移全是一条龙讲完适合刚接手服务器运维的新手也适合那些从 MySQL 迁移到 MariaDB、想少踩坑的团队参考。1. MariaDB 是什么为什么服务器上选它1.1 它和 MySQL 的关系别被“分支”劝退很多人一听到 MariaDB 是 MySQL 的分支心里就犯嘀咕分支是不是意味着不正式、不稳定、兼容性差恰恰相反。MariaDB 是 MySQL 最初的核心开发者 Michael Widenius 主导创建的项目因为担心 MySQL 被收购后走向闭源或者发展路线受限所以从 MySQL 源码里分叉出来继续维护。也就是说它是“原班人马”从头做起来的不是谁随随便便拉的复制品。从协议层面看MariaDB 保持了对 MySQL 的高度兼容。绝大多数 SQL 语法、连接协议、备份工具、客户端程序都能直接套用。MySQL 的 mysqldump 导出的数据MariaDB 能照样导入MySQL 的 JDBC 驱动、Python 驱动、PHP 的 PDO 连接串MariaDB 都能平滑接入。我做过几次从 MySQL 迁移到 MariaDB 的项目基本上就是装好 MariaDB把数据导入进去启动服务应用连的地址改一下就完事了。开发人员甚至感觉不到后端数据库换了。真正要留意的版本差异还是在细节上。比如 MySQL 8.0 之后默认认证插件改成了 caching_sha2_passwordMariaDB 至今还是 mysql_native_password 为主所以某些老项目连 MySQL 8.0 会碰到认证失败的坑连 MariaDB 反而没事。这种“落后”在某些场景下反而是优点兼容老系统的成本低得多。1.2 它的优势到底落在哪里从运维角度说MariaDB 的几个点是我比较看重的。一是默认存储引擎 InnoDB 支持事务、行级锁、崩溃恢复生产环境选它不会错二是除了 InnoDBMariaDB 还自带 Aria、MyRocks、Spider 等存储引擎某些特殊场景下真的有用比如日志表用 Aria、大数据分析用 MyRocks 列式存储三是线程池thread pool功能在 MySQL 里是商业版才有MariaDB 开源版就带了连接数一多时稳定性明显更好四是比较丰富的性能监控信息performance_schema 开着之后慢 SQL、锁等待这些都能看得比较清楚。另外还有一个现实原因MariaDB 是完全开源的没有商业闭源版本的顾虑。官方还维护着一套专门给服务器用的软件源装完就能用最近几年的版本不用忍受发行版仓库里那个十年不更新的老版本。这对服务器运维人员来说特别重要因为数据库这种基础组件版本越老安全风险和性能差距越大。1.3 适合哪些场景和人群如果你是在自己折腾一个个人博客、小型管理系统、内网工具或者给创业团队搭一套 Web 服务的基础数据层MariaDB 完全是够用的而且省心。如果你的公司有成熟的 DBA 团队、业务重度依赖 MySQL 8.0 的新特性、已经买了 MySQL 商业版的授权那不一定非要换。但反过来如果只是要一个稳定可靠、省授权费、社区资料丰富的服务器数据库MariaDB 是非常务实的选择。我见过不少项目是这么起步的一开始为了免费选了 MySQL 社区版后来发现 MySQL 社区版和商业版的功能差距越来越大于是迁到 MariaDB 保平安。这种事不是个例。2. 服务器上的安装与初始化2.1 选官方仓库别用系统自带的旧版本在 CentOS 或 Ubuntu 上安装 MariaDB最简单的命令是yum install mariadb-server或apt install mariadb-server但我不推荐这么做。原因很简单发行版自带的包版本往往落后官方好几个大版本比如 Ubuntu 20.04 自带的还是 MariaDB 10.3而官方早出到 10.11 甚至 11.x 了。老版本在性能、安全补丁、新硬件支持上都有差距尤其是如果你要在新服务器上部署用旧包等于凭空给自己找事。正确姿势是走官方仓库安装。在 CentOS/RHEL 系的机器上先去 MariaDB 官网下载仓库配置脚本执行curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash脚本执行完会生成/etc/yum.repos.d/mariadb.repo。之后直接安装dnf install -y MariaDB-server MariaDB-clientUbuntu/Debian 系也类似先安装依赖、导入 GPG 密钥再用 apt 装apt-get install -y apt-transport-https curl curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash apt update apt install -y mariadb-server为什么非要官方源而不是系统源除了版本新之外官方源还有一个好处它会把 MariaDB 用的数据目录、日志目录、配置文件路径都安排妥当服务名统一叫mariadb跟发行版自带的包在行为上有一致性后来的维护会轻松很多。我曾在某台机器上同时装过系统包和官方包结果出来两套配置服务互相抢端口折腾了半天才理清楚从那以后我都是干净系统直接上官方源。2.2 启动服务和验证版本装好之后先启动服务systemctl enable --now mariadb systemctl status mariadb看到active (running)就说明起来了。新版本的 MariaDB 在安装完以后默认数据目录已经初始化好了不需要像 MySQL 8.0 那样还要手动跑mysqld --initialize省了一步。验证一下版本号和连接mysql -uroot如果能进到MariaDB [(none)]提示符说明安装成功。也可以直接查SELECT VERSION();输出类似10.11.8-MariaDB这样的版本号就行。这时候的 root 用户状态分两种情况Debian/Ubuntu 系默认走 unix_socket 认证直接sudo mysql能进RPM 系通常 root 密码为空mysql -uroot就能进。不管哪种都得赶紧设置正规密码这就是下一节的核心内容。2.3 Windows 服务器上怎么装简单带过Windows Server 上跑 MariaDB 也很常见尤其是某些老旧项目非要部署在 Windows 环境里。去官网下 Windows 的 MSI 安装包一路下一步如果想更可控下载 ZIP 包解压后用管理员权限打开命令行执行cd C:\mariadb mkdir data mysqld --install MariaDB --datadirC:\mariadb\data net start MariaDB之后mysql -uroot也能进入。Windows 下的注意事项主要有两个一是安装目录路径不要带空格不然服务启动时各种莫名其妙的问题二是 Windows 防火墙要放行 3306 端口否则局域网都连不上这部分后面远程连接章节会讲。3. 给 root 设置密码与安全加固3.1 刚装完 root 是什么状态“给 mariadb root 设置密码”是搜索量非常高的问题说明大多数新手都卡在这一步。为什么装完 root 能用空密码或者 socket 免密进因为安装器不知道你打算设什么密码又不能拦着你所以先给一条默认进去的路。但数据库是服务器的核心组件空密码等于把门敞开这种事绝对不能带到生产环境。Debian/Ubuntu 系默认 root 走 unix_socket 认证意思是只有系统 root 用户或 sudo 用户通过本机套接字连接时才能识别为数据库 root远程连接直接拒绝。这套机制安全性其实不差但有个麻烦很多备份脚本、管理工具需要密码登录socket 认证反而成了阻碍。所以通常我会把 root 改成密码认证同时保留一套本机 socket 登录的能力也行看实际需求。RPM 系CentOS 等装完 root 是空密码不管从本机还是远程只要有空密码就能尝试登录风险更大。必须马上设置密码。3.2 三种常见的设密码方式第一种用 mysql_secure_installation 交互式脚本。这是最省事的方式mysql_secure_installation脚本会依次问是否设置 root 密码、是否删除匿名用户、是否禁止 root 远程登录、是否删除 test 测试库、是否刷新权限表。除了密码按需要设其余建议都选 Y。脚本逻辑很清晰适合第一次操作的人。第二种在 MySQL 会话里用 ALTER USER。先用上面的方式进入命令行然后执行ALTER USER rootlocalhost IDENTIFIED BY 你的强密码; FLUSH PRIVILEGES;MariaDB 默认 root 的 host 是 localhost所以这样改就能覆盖本机登录。如果某些系统里 root 还有root127.0.0.1等多个条目可以查一下SELECT user, host, plugin FROM mysql.user WHERE userroot;把需要的条目都用 ALTER USER 设置一遍。第三种用 SET PASSWORDSET PASSWORD FOR rootlocalhost PASSWORD(你的强密码);其实方式不重要关键是要理解 root 密码是存在mysql.user表里的改完要FLUSH PRIVILEGES让内存里的权限数据同步。生产环境我强烈建议用 16 位以上、混合大小写字母和数字的密码别用什么123456或者root这种给自己找麻烦的密码。3.3 安全加固的必做清单设完密码只是第一步。我每次部署都会顺手做这几件事删除匿名用户DELETE FROM mysql.user WHERE user;删除测试库DROP DATABASE IF EXISTS test;禁止 root 从远程登录。业务代码绝不能拿 root 去连数据库否则一旦应用被攻破数据库就全完了。正确做法是禁用 root 远程给每个应用建独立账号。预留一个但如果确认远程登录不需要直接执行DELETE FROM mysql.user WHERE userroot AND host localhost;刷新权限FLUSH PRIVILEGES;最后检查一遍监听地址。如果数据库只需要本机访问最好在配置文件里把 bind-address 设为 127.0.0.1这样端口不会暴露到局域网能少很多扫描攻击。另外强烈建议装一个unix_socket插件Debian 系默认就有这样即使 root 密码丢了还能通过系统 sudo 进入数据库做补救。安装命令INSTALL SONAME unix_socket;然后设置 root 走 socket 认证ALTER USER rootlocalhost IDENTIFIED VIA unix_socket;这个机制在后面“密码忘了怎么进”那一节会非常有用。4. 核心配置与性能调优4.1 配置文件在哪里读优先级是怎样的MariaDB 的配置文件和 MySQL 一样分布在多个位置。启动时它会按顺序读这些文件/etc/my.cnf/etc/mysql/my.cnf~/.my.cnf编译时指定的其他路径实际使用中CentOS 系主要改/etc/my.cnfUbuntu 系主要改/etc/mysql/mariadb.conf.d/50-server.cnf。后读的文件会覆盖先读的配置想确认当前生效的值直接执行SHOW VARIABLES LIKE innodb_buffer_pool_size;这里值得提醒的是不要在多个配置文件里重复设置同一个参数因为后读的会覆盖先读的排查时容易一头雾水。我习惯只认准一个主配置文件其他文件保持默认。4.2 几个真正影响性能的参数服务器硬件不同参数肯定不同但有一个参数是所有人最先该调的innodb_buffer_pool_size。它是 InnoDB 的缓冲池用来缓存数据和索引的几乎所有热数据读取都会经过这里。太小时数据库只能频繁到磁盘上读数据延迟马上上来太大时又可能挤占操作系统的可用内存触发 swap反而更慢。我给一个经验值物理内存 4G 的机器设 1G 或 2G8G 设 4G内存 16G 以上可以设到 50% 到 70%。公式上可以这么算总内存的一半左右给操作系统和文件系统缓存留余量。举个例子16G 内存的服务器[mysqld] innodb_buffer_pool_size 8G改完要重启服务生效。max_connections也是一个很容易踩坑的参数。默认值 151 听起来够用但一旦你有十几个服务实例、每个实例开了连接池连接数很快就能打满。常见报错是Too many connections。我的建议是不要盲目调大而是先通过监控看实际峰值。比如可以用这条 SQL 查看当前连接数SHOW STATUS LIKE Threads_connected;如果经常超过 100再考虑把max_connections调到 300 或 500。同时要给每个连接池的连接数量设上限否则后端应用一乱开连接把内存打爆也不是没可能。另外几个值得关注的参数[mysqld] skip_name_resolve ON关闭反向域名解析。这条能减少每次连接时的延迟因为服务器收到请求后会尝试把 IP 反解成域名很多内网环境根本没有反向 DNS反而每次要等超时。innodb_flush_log_at_trx_commit 1值设 1 最安全每次事务提交都刷盘但性能开销大如果业务能接受极端情况下丢失最近 1 到 2 秒的事务日志可以设 2性能会明显提升。我一般建议生产环境保持 1测试环境可以设 2。query_cache这东西在新版本里已经不建议开了。MySQL 8.0 直接移除MariaDB 还保留着但在高并发写入场景下维护缓存的代价不小。我默认关闭它靠 InnoDB 的 buffer pool 扛热数据。4.3 字符集、时区这类“看不见的坑”字符集是中文项目最容易出问题的地方。只要数据库、表、连接三层的字符集不统一就会出现乱码或数据截断。我给一个稳妥方案数据库和表统一用utf8mb4连接串也要显式指定字符集。在配置里加上[mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_ciutf8mb4是真正的四字节 UTF-8能存下所有常见字符和 emoji。老项目的utf8其实不是标准 UTF-8属于 MySQL 历史遗留问题存不了四字节字符新项目没必要再用它。时区这块更容易被忽略。默认情况下MariaDB 使用系统时区如果服务器时区是 UTC而业务在北京时间那么所有NOW()、CURRENT_TIMESTAMP()返回的都是 UTC 时间。应用层面取到的时间看起来就差了 8 小时。最简单的方式是把服务器本身的时区设对。对于 CentOS 系timedatectl set-timezone Asia/Shanghai然后在 MariaDB 里直接SET GLOBAL time_zone 08:00;长期使用的话在配置文件里加上[mysqld] default-time-zone 08:00这样重启后也不会还原。排查时可以用SELECT NOW(); SELECT global.time_zone, session.time_zone;如果看到SYSTEM和08:00不一致就得调整。别小看这个时区问题生产环境因为时间差导致统计报表错一天的案例我见过太多次了。5. 远程访问与连接故障排查5.1 让服务器可以被其他机器连上很多人设置好密码之后在自己机器上mysql -uroot -p能连但换一台机器连同一台服务器却报连接失败第一反应是密码错了其实往往是监听地址和防火墙的问题。先看监听地址。默认情况下MariaDB 只监听 127.0.0.1也就是只有本机才能连。要让局域网内其他机器能连先检查配置文件里的bind-address[mysqld] bind-address 0.0.0.0如果只想让特定网段访问也可以填服务器的内网 IP。改完重启服务systemctl restart mariadb然后检查端口是否监听ss -ltnp | grep 3306看到*:3306或具体 IP 的 3306才说明服务已经在等连接了。如果只看到127.0.0.1:3306就说明 bind-address 没生效。接着是防火墙。CentOS 上如果是 firewalldfirewall-cmd --permanent --add-port3306/tcp firewall-cmd --reloadUbuntu 上如果是 ufwufw allow 3306/tcp另外现在很多机器其实是云服务器那么云平台的安全组也要放行 3306 端口。这一步经常被漏掉因为你在服务器上查防火墙是正常的但流量在门口就被安全组挡住了。处理方法就是去云控制台给安全组加一条入站规则放行来源 IP 和端口。这种“服务器上一切正常但就是连不上”的案例十有八九都是安全组的问题。5.2 建一个允许远程登录的业务账号远程访问不是把 root 放开就完了而是要建一个最小权限的业务账号。比如给一个 Web 应用建账号只让它访问某个库的增删改查权限CREATE USER appuser10.10.8.% IDENTIFIED BY 复杂密码; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO appuser10.10.8.%; FLUSH PRIVILEGES;这里的10.10.8.%是允许登录的来源网段。%是通配符表示任意主机但生产环境不建议这么写尽量限制到应用服务器所在的网段。理解host字段的匹配逻辑很重要当你从某台机器连接时MariaDB 会根据你的 IP 找到匹配的 user 条目如果有多条匹配会选最精确的那条。我曾经见过某个账号的 host 写成了192.168.1.%应用没在这个网段连了半天都连不上。还要提醒一点改完权限后执行FLUSH PRIVILEGES是把权限表重新载入内存。虽然CREATE USER和GRANT本身已经生效不需要刷但养成这个习惯没坏处尤其是你直接改了mysql.user表的时候不刷新可能会遇到奇怪的权限问题。5.3 常见连接失败原因速查远程连接失败这个问题我处理过太多次在这里直接说结论如果是ERROR 2003 (HY000): Cant connect to MySQL server on ...多半是网络层面的问题IP 不通、端口没监听、防火墙挡了。先用ping和telnet IP 3306这种工具分段排查。如果是ERROR 1045 (28000): Access denied for user ...是认证或权限问题密码不对、host 不匹配、账号不存在。用刚才讲的 user 表查询确认。如果是ERROR 2013 (HY000): Lost connection to MySQL server during query常见原因有连接超时、max_allowed_packet太小、网络不稳定。处理办法是适当调大max_allowed_packet同时检查连接池keepalive设置。还有一个很隐蔽的问题客户端和服务端的连接协议版本不一致。比如用特别老的 MySQL 客户端去连新版 MariaDB会报Client does not support authentication protocol requested by server。解决方式是把客户端的认证插件升级或者让服务端改用 mysql_native_password。MariaDB 默认就是 mysql_native_password所以这种坑相对少但如果你是从 MySQL 8.0 那边带着旧客户端过来还是有可能碰到的。6. 备份、迁移与应急恢复6.1 逻辑备份首选 mysqldump 的用法数据库运维里最不能省的就是备份。MariaDB 自带mysqldump用起来和 MySQL 完全一样。我在正式环境里最常用的备份命令是这样mysqldump -uroot -p --single-transaction --routines --triggers --events --databases mydb mydb_$(date %F).sql参数解释一下--single-transaction是给 InnoDB 用的备份在不锁表的前提下基于事务快照导出避免影响业务--routines、--triggers、--events分别导出存储过程、触发器、事件调度器这仨经常有人漏掉等到恢复时才惊觉缺了一大块。--databases表示后面几个库要带上 CREATE DATABASE 语句这样恢复时数据库会自动建好。恢复就一条命令mysql -uroot -p mydb_2025-06-01.sql如果备份文件里不带 CREATE DATABASE就先手动建库再导入。逻辑备份的优点是可在不同版本、不同平台之间迁移缺点是数据量大时导出时间长、恢复也慢。几 GB 以内的库用它没问题几十 GB 以上就不要靠它了。6.2 大数据量用物理备份 mariadb-backup数据量一大就得换物理备份。MariaDB 官方的备份工具是mariadb-backup它是在 Percona XtraBackup 基础上演化来的原理是直接复制数据文件同时基于 InnoDB 的 redo log 做一致性处理比 mysqldump 快一个数量级。全量备份示例mariadb-backup --backup --target-dir/backup/mariadb/full --userroot --passwordxxx恢复的时候先准备备份让日志回放到一致状态mariadb-backup --prepare --target-dir/backup/mariadb/full然后停止服务把原数据目录替换掉systemctl stop mariadb mariadb-backup --copy-back --target-dir/backup/mariadb/full chown -R mysql:mysql /var/lib/mysql systemctl start mariadb不要小看那个chown步骤权限不对的话 MySQL 进程会直接起不来报错日志里全是 permission denied。物理备份恢复速度非常快几个 GB 的库基本一分钟内能恢复缺点是恢复到的目标机器最好和原机器配置相近跨大版本迁移容易出现兼容问题。6.3 主从复制的最小配置如果你有两台服务器想让一台实时同步另一台的数据最轻量的方案就是主从复制。MariaDB 的复制配置比很多人想象中简单。先在主库的配置文件里开 binlog 和服务 ID[mysqld] server-id 1 log_bin /var/log/mysql/mariadb-bin然后在主库建一个复制专用账号CREATE USER repl10.10.8.% IDENTIFIED BY 复制密码; GRANT REPLICATION SLAVE ON *.* TO repl10.10.8.%; FLUSH PRIVILEGES;查看当前日志文件位置SHOW MASTER STATUS;记下 File 和 Position 两个值。接着在从库上指定CHANGE MASTER TO MASTER_HOST主库IP, MASTER_USERrepl, MASTER_PASSWORD复制密码, MASTER_LOG_FILEmariadb-bin.000001, MASTER_LOG_POS787; START SLAVE;查看复制状态SHOW SLAVE STATUS\G重点看Slave_IO_Running: Yes和Slave_SQL_Running: Yes都是 Yes 就说明在正常同步。如果Slave_IO_Running显示 Connecting通常是网络不通或者复制账号密码不对如果Slave_SQL_Running显示 No多半是某条 SQL 在主从两端执行结果不一致需要具体看Last_SQL_Error字段。主从复制不是备份的替代品。有人以为有了主从同步就不需要备份这是非常危险的想法——如果误执行了 DELETE 或者主库数据文件损坏从库也会跟着坏掉。复制解决的是高可用和读写分离备份解决的是数据损坏和误操作两件事得同时做。6.4 密码忘了怎么进应急手法“root 密码忘了”是服务器运维里最高频的问题之一。如果你之前配置了 unix_socket 认证那最简单系统 sudo 用户直接mysql就能进然后重新设置密码。如果 root 走的是密码认证又忘了就得走应急通道。先停服务systemctl stop mariadb然后临时以跳过授权表的方式启动mysqld_safe --skip-grant-tables 这时候任何用户都能免密进入。进库之后先刷新权限表让密码相关操作能生效FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;改完把服务正常重启mysqladmin -uroot -p shutdown systemctl start mariadb这里必须强调--skip-grant-tables状态下数据库没有任何访问控制这种临时启动方式只准在你能直接控制服务器的物理或系统控制台情况下使用而且改完密码必须马上重启回正常模式。千万别开着这个模式就丢在那里不管。7. 常见问题速查表与个人经验7.1 问题速查表现象可能原因处理办法root 密码空想设置密码安装后未初始化密码用 ALTER USER 或 mysql_secure_installation本机能连远程连接超时bind-address 只有 127.0.0.1改 bind-address 并重启服务防火墙放行了还是连不上云安全组未放行 3306到云控制台安全组增加入站规则Access denied for user密码错误 / host 不匹配确认 user 条目的 host 是否覆盖来源 IPToo many connectionsmax_connections 过小调整参数并优化连接池项目中文乱码字符集不统一表和连接统一 utf8mb4NOW() 时间差了 8 小时服务器时区或数据库时区不对设置系统时区 default-time-zone无法启动服务数据目录权限不对检查 /var/lib/mysql 属主属组主从同步出现错误SQL 在两端执行不一致查看 SHOW SLAVE STATUS 的 Last_SQL_Error大量删除操作后数据丢失误操作依赖备份恢复不能靠主从救数据这张表基本覆盖了我日常运维里 80% 以上的问题。真遇到不在表里的第一步永远是去看日志。MariaDB 的日志一般写在/var/log/mysql/比如error.log启动失败、连接失败、复制中断都会在这里留下线索。很多新手一遇到问题就乱试命令其实先花两分钟看日志往往能直接找到原因。7.2 一些实操中踩过的坑最后说几个我亲身体会最深的点。第一个是“永远不要在业务高峰期调字符集”。之前有一次我给一个运营中的库改表字符集一张千万行的表 ALTER 跑了快一个小时期间表上的写操作全部阻塞业务直接报警。后来我都学乖了字符集这种全局改动放在维护窗口做或者提前在测试环境验证一遍耗时。第二个是关于连接池。Java 应用默认的连接池参数里有个maxLifetime如果比数据库的wait_timeout长就会出现连接被数据库端回收、应用却还拿它去查询的情况报错通常是 “Connection is not available, request timed out”。这不是数据库坏了是两端超时参数没对齐。处理方式是让连接池的 maxLifetime 小于数据库的 wait_timeout比如 wait_timeout 设 28800 秒连接池 maxLifetime 设 14000 秒。第三个是升级版本别跳太多。MariaDB 的主版本升级比如从 10.5 升到 10.11理论上可以直接dnf update但中间如果跨了好几个大版本某些系统表的格式可能不兼容。稳妥做法是先备份然后按主版本逐级升级每一步都验证一下数据和服务状态。我前几年图快从 10.3 直接升到 10.6结果启动时报系统表不兼容最后用备份恢复才救回来。从那以后凡是数据库升级我必先备份再说。第四个是关于 root 的远程登录。早些年为省事我确实干过让 root 能从任意 IP 登录的蠢事。后来有一次日志里看到了来自外网的暴力破解尝试才意识到这是在拿整个数据库裸奔。现在我的规则很简单root 只留 localhost业务账号给最小权限来源 IP 能写网段就不写%能写具体 IP 就不写网段。多花几分钟收权限后面能少处理很多安全事故。MariaDB 作为服务器上的核心组件其实并不复杂。把安装、设密码、调参、远程访问、备份这五件事做好它就能稳定跑很久。我在这套流程上踩过不少坑写出来的这些都是实打实验证过的方案。如果你正准备在自己服务器上部署 MariaDB照着这篇文章的流程走一遍基本能避开我当年踩过的绝大多数坑。
服务器MariaDB部署运维实战：从安装、安全配置到备份迁移
接到这种需求已经很多次了新项目要上线机器是现成的 CentOS/Ubuntu让我在服务器上把 MariaDB 搭起来。会点的人都觉得简单但实际操作下来坑其实不少——root 密码怎么设、远程连不上、时区不对、备份不知道怎么恢复每一个都能让人折腾到半夜。这篇文章就是把我平时在服务器上部署和维护 MariaDB 的完整过程整理出来从安装、设密码、调参、排错到备份迁移全是一条龙讲完适合刚接手服务器运维的新手也适合那些从 MySQL 迁移到 MariaDB、想少踩坑的团队参考。1. MariaDB 是什么为什么服务器上选它1.1 它和 MySQL 的关系别被“分支”劝退很多人一听到 MariaDB 是 MySQL 的分支心里就犯嘀咕分支是不是意味着不正式、不稳定、兼容性差恰恰相反。MariaDB 是 MySQL 最初的核心开发者 Michael Widenius 主导创建的项目因为担心 MySQL 被收购后走向闭源或者发展路线受限所以从 MySQL 源码里分叉出来继续维护。也就是说它是“原班人马”从头做起来的不是谁随随便便拉的复制品。从协议层面看MariaDB 保持了对 MySQL 的高度兼容。绝大多数 SQL 语法、连接协议、备份工具、客户端程序都能直接套用。MySQL 的 mysqldump 导出的数据MariaDB 能照样导入MySQL 的 JDBC 驱动、Python 驱动、PHP 的 PDO 连接串MariaDB 都能平滑接入。我做过几次从 MySQL 迁移到 MariaDB 的项目基本上就是装好 MariaDB把数据导入进去启动服务应用连的地址改一下就完事了。开发人员甚至感觉不到后端数据库换了。真正要留意的版本差异还是在细节上。比如 MySQL 8.0 之后默认认证插件改成了 caching_sha2_passwordMariaDB 至今还是 mysql_native_password 为主所以某些老项目连 MySQL 8.0 会碰到认证失败的坑连 MariaDB 反而没事。这种“落后”在某些场景下反而是优点兼容老系统的成本低得多。1.2 它的优势到底落在哪里从运维角度说MariaDB 的几个点是我比较看重的。一是默认存储引擎 InnoDB 支持事务、行级锁、崩溃恢复生产环境选它不会错二是除了 InnoDBMariaDB 还自带 Aria、MyRocks、Spider 等存储引擎某些特殊场景下真的有用比如日志表用 Aria、大数据分析用 MyRocks 列式存储三是线程池thread pool功能在 MySQL 里是商业版才有MariaDB 开源版就带了连接数一多时稳定性明显更好四是比较丰富的性能监控信息performance_schema 开着之后慢 SQL、锁等待这些都能看得比较清楚。另外还有一个现实原因MariaDB 是完全开源的没有商业闭源版本的顾虑。官方还维护着一套专门给服务器用的软件源装完就能用最近几年的版本不用忍受发行版仓库里那个十年不更新的老版本。这对服务器运维人员来说特别重要因为数据库这种基础组件版本越老安全风险和性能差距越大。1.3 适合哪些场景和人群如果你是在自己折腾一个个人博客、小型管理系统、内网工具或者给创业团队搭一套 Web 服务的基础数据层MariaDB 完全是够用的而且省心。如果你的公司有成熟的 DBA 团队、业务重度依赖 MySQL 8.0 的新特性、已经买了 MySQL 商业版的授权那不一定非要换。但反过来如果只是要一个稳定可靠、省授权费、社区资料丰富的服务器数据库MariaDB 是非常务实的选择。我见过不少项目是这么起步的一开始为了免费选了 MySQL 社区版后来发现 MySQL 社区版和商业版的功能差距越来越大于是迁到 MariaDB 保平安。这种事不是个例。2. 服务器上的安装与初始化2.1 选官方仓库别用系统自带的旧版本在 CentOS 或 Ubuntu 上安装 MariaDB最简单的命令是yum install mariadb-server或apt install mariadb-server但我不推荐这么做。原因很简单发行版自带的包版本往往落后官方好几个大版本比如 Ubuntu 20.04 自带的还是 MariaDB 10.3而官方早出到 10.11 甚至 11.x 了。老版本在性能、安全补丁、新硬件支持上都有差距尤其是如果你要在新服务器上部署用旧包等于凭空给自己找事。正确姿势是走官方仓库安装。在 CentOS/RHEL 系的机器上先去 MariaDB 官网下载仓库配置脚本执行curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash脚本执行完会生成/etc/yum.repos.d/mariadb.repo。之后直接安装dnf install -y MariaDB-server MariaDB-clientUbuntu/Debian 系也类似先安装依赖、导入 GPG 密钥再用 apt 装apt-get install -y apt-transport-https curl curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash apt update apt install -y mariadb-server为什么非要官方源而不是系统源除了版本新之外官方源还有一个好处它会把 MariaDB 用的数据目录、日志目录、配置文件路径都安排妥当服务名统一叫mariadb跟发行版自带的包在行为上有一致性后来的维护会轻松很多。我曾在某台机器上同时装过系统包和官方包结果出来两套配置服务互相抢端口折腾了半天才理清楚从那以后我都是干净系统直接上官方源。2.2 启动服务和验证版本装好之后先启动服务systemctl enable --now mariadb systemctl status mariadb看到active (running)就说明起来了。新版本的 MariaDB 在安装完以后默认数据目录已经初始化好了不需要像 MySQL 8.0 那样还要手动跑mysqld --initialize省了一步。验证一下版本号和连接mysql -uroot如果能进到MariaDB [(none)]提示符说明安装成功。也可以直接查SELECT VERSION();输出类似10.11.8-MariaDB这样的版本号就行。这时候的 root 用户状态分两种情况Debian/Ubuntu 系默认走 unix_socket 认证直接sudo mysql能进RPM 系通常 root 密码为空mysql -uroot就能进。不管哪种都得赶紧设置正规密码这就是下一节的核心内容。2.3 Windows 服务器上怎么装简单带过Windows Server 上跑 MariaDB 也很常见尤其是某些老旧项目非要部署在 Windows 环境里。去官网下 Windows 的 MSI 安装包一路下一步如果想更可控下载 ZIP 包解压后用管理员权限打开命令行执行cd C:\mariadb mkdir data mysqld --install MariaDB --datadirC:\mariadb\data net start MariaDB之后mysql -uroot也能进入。Windows 下的注意事项主要有两个一是安装目录路径不要带空格不然服务启动时各种莫名其妙的问题二是 Windows 防火墙要放行 3306 端口否则局域网都连不上这部分后面远程连接章节会讲。3. 给 root 设置密码与安全加固3.1 刚装完 root 是什么状态“给 mariadb root 设置密码”是搜索量非常高的问题说明大多数新手都卡在这一步。为什么装完 root 能用空密码或者 socket 免密进因为安装器不知道你打算设什么密码又不能拦着你所以先给一条默认进去的路。但数据库是服务器的核心组件空密码等于把门敞开这种事绝对不能带到生产环境。Debian/Ubuntu 系默认 root 走 unix_socket 认证意思是只有系统 root 用户或 sudo 用户通过本机套接字连接时才能识别为数据库 root远程连接直接拒绝。这套机制安全性其实不差但有个麻烦很多备份脚本、管理工具需要密码登录socket 认证反而成了阻碍。所以通常我会把 root 改成密码认证同时保留一套本机 socket 登录的能力也行看实际需求。RPM 系CentOS 等装完 root 是空密码不管从本机还是远程只要有空密码就能尝试登录风险更大。必须马上设置密码。3.2 三种常见的设密码方式第一种用 mysql_secure_installation 交互式脚本。这是最省事的方式mysql_secure_installation脚本会依次问是否设置 root 密码、是否删除匿名用户、是否禁止 root 远程登录、是否删除 test 测试库、是否刷新权限表。除了密码按需要设其余建议都选 Y。脚本逻辑很清晰适合第一次操作的人。第二种在 MySQL 会话里用 ALTER USER。先用上面的方式进入命令行然后执行ALTER USER rootlocalhost IDENTIFIED BY 你的强密码; FLUSH PRIVILEGES;MariaDB 默认 root 的 host 是 localhost所以这样改就能覆盖本机登录。如果某些系统里 root 还有root127.0.0.1等多个条目可以查一下SELECT user, host, plugin FROM mysql.user WHERE userroot;把需要的条目都用 ALTER USER 设置一遍。第三种用 SET PASSWORDSET PASSWORD FOR rootlocalhost PASSWORD(你的强密码);其实方式不重要关键是要理解 root 密码是存在mysql.user表里的改完要FLUSH PRIVILEGES让内存里的权限数据同步。生产环境我强烈建议用 16 位以上、混合大小写字母和数字的密码别用什么123456或者root这种给自己找麻烦的密码。3.3 安全加固的必做清单设完密码只是第一步。我每次部署都会顺手做这几件事删除匿名用户DELETE FROM mysql.user WHERE user;删除测试库DROP DATABASE IF EXISTS test;禁止 root 从远程登录。业务代码绝不能拿 root 去连数据库否则一旦应用被攻破数据库就全完了。正确做法是禁用 root 远程给每个应用建独立账号。预留一个但如果确认远程登录不需要直接执行DELETE FROM mysql.user WHERE userroot AND host localhost;刷新权限FLUSH PRIVILEGES;最后检查一遍监听地址。如果数据库只需要本机访问最好在配置文件里把 bind-address 设为 127.0.0.1这样端口不会暴露到局域网能少很多扫描攻击。另外强烈建议装一个unix_socket插件Debian 系默认就有这样即使 root 密码丢了还能通过系统 sudo 进入数据库做补救。安装命令INSTALL SONAME unix_socket;然后设置 root 走 socket 认证ALTER USER rootlocalhost IDENTIFIED VIA unix_socket;这个机制在后面“密码忘了怎么进”那一节会非常有用。4. 核心配置与性能调优4.1 配置文件在哪里读优先级是怎样的MariaDB 的配置文件和 MySQL 一样分布在多个位置。启动时它会按顺序读这些文件/etc/my.cnf/etc/mysql/my.cnf~/.my.cnf编译时指定的其他路径实际使用中CentOS 系主要改/etc/my.cnfUbuntu 系主要改/etc/mysql/mariadb.conf.d/50-server.cnf。后读的文件会覆盖先读的配置想确认当前生效的值直接执行SHOW VARIABLES LIKE innodb_buffer_pool_size;这里值得提醒的是不要在多个配置文件里重复设置同一个参数因为后读的会覆盖先读的排查时容易一头雾水。我习惯只认准一个主配置文件其他文件保持默认。4.2 几个真正影响性能的参数服务器硬件不同参数肯定不同但有一个参数是所有人最先该调的innodb_buffer_pool_size。它是 InnoDB 的缓冲池用来缓存数据和索引的几乎所有热数据读取都会经过这里。太小时数据库只能频繁到磁盘上读数据延迟马上上来太大时又可能挤占操作系统的可用内存触发 swap反而更慢。我给一个经验值物理内存 4G 的机器设 1G 或 2G8G 设 4G内存 16G 以上可以设到 50% 到 70%。公式上可以这么算总内存的一半左右给操作系统和文件系统缓存留余量。举个例子16G 内存的服务器[mysqld] innodb_buffer_pool_size 8G改完要重启服务生效。max_connections也是一个很容易踩坑的参数。默认值 151 听起来够用但一旦你有十几个服务实例、每个实例开了连接池连接数很快就能打满。常见报错是Too many connections。我的建议是不要盲目调大而是先通过监控看实际峰值。比如可以用这条 SQL 查看当前连接数SHOW STATUS LIKE Threads_connected;如果经常超过 100再考虑把max_connections调到 300 或 500。同时要给每个连接池的连接数量设上限否则后端应用一乱开连接把内存打爆也不是没可能。另外几个值得关注的参数[mysqld] skip_name_resolve ON关闭反向域名解析。这条能减少每次连接时的延迟因为服务器收到请求后会尝试把 IP 反解成域名很多内网环境根本没有反向 DNS反而每次要等超时。innodb_flush_log_at_trx_commit 1值设 1 最安全每次事务提交都刷盘但性能开销大如果业务能接受极端情况下丢失最近 1 到 2 秒的事务日志可以设 2性能会明显提升。我一般建议生产环境保持 1测试环境可以设 2。query_cache这东西在新版本里已经不建议开了。MySQL 8.0 直接移除MariaDB 还保留着但在高并发写入场景下维护缓存的代价不小。我默认关闭它靠 InnoDB 的 buffer pool 扛热数据。4.3 字符集、时区这类“看不见的坑”字符集是中文项目最容易出问题的地方。只要数据库、表、连接三层的字符集不统一就会出现乱码或数据截断。我给一个稳妥方案数据库和表统一用utf8mb4连接串也要显式指定字符集。在配置里加上[mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_ciutf8mb4是真正的四字节 UTF-8能存下所有常见字符和 emoji。老项目的utf8其实不是标准 UTF-8属于 MySQL 历史遗留问题存不了四字节字符新项目没必要再用它。时区这块更容易被忽略。默认情况下MariaDB 使用系统时区如果服务器时区是 UTC而业务在北京时间那么所有NOW()、CURRENT_TIMESTAMP()返回的都是 UTC 时间。应用层面取到的时间看起来就差了 8 小时。最简单的方式是把服务器本身的时区设对。对于 CentOS 系timedatectl set-timezone Asia/Shanghai然后在 MariaDB 里直接SET GLOBAL time_zone 08:00;长期使用的话在配置文件里加上[mysqld] default-time-zone 08:00这样重启后也不会还原。排查时可以用SELECT NOW(); SELECT global.time_zone, session.time_zone;如果看到SYSTEM和08:00不一致就得调整。别小看这个时区问题生产环境因为时间差导致统计报表错一天的案例我见过太多次了。5. 远程访问与连接故障排查5.1 让服务器可以被其他机器连上很多人设置好密码之后在自己机器上mysql -uroot -p能连但换一台机器连同一台服务器却报连接失败第一反应是密码错了其实往往是监听地址和防火墙的问题。先看监听地址。默认情况下MariaDB 只监听 127.0.0.1也就是只有本机才能连。要让局域网内其他机器能连先检查配置文件里的bind-address[mysqld] bind-address 0.0.0.0如果只想让特定网段访问也可以填服务器的内网 IP。改完重启服务systemctl restart mariadb然后检查端口是否监听ss -ltnp | grep 3306看到*:3306或具体 IP 的 3306才说明服务已经在等连接了。如果只看到127.0.0.1:3306就说明 bind-address 没生效。接着是防火墙。CentOS 上如果是 firewalldfirewall-cmd --permanent --add-port3306/tcp firewall-cmd --reloadUbuntu 上如果是 ufwufw allow 3306/tcp另外现在很多机器其实是云服务器那么云平台的安全组也要放行 3306 端口。这一步经常被漏掉因为你在服务器上查防火墙是正常的但流量在门口就被安全组挡住了。处理方法就是去云控制台给安全组加一条入站规则放行来源 IP 和端口。这种“服务器上一切正常但就是连不上”的案例十有八九都是安全组的问题。5.2 建一个允许远程登录的业务账号远程访问不是把 root 放开就完了而是要建一个最小权限的业务账号。比如给一个 Web 应用建账号只让它访问某个库的增删改查权限CREATE USER appuser10.10.8.% IDENTIFIED BY 复杂密码; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO appuser10.10.8.%; FLUSH PRIVILEGES;这里的10.10.8.%是允许登录的来源网段。%是通配符表示任意主机但生产环境不建议这么写尽量限制到应用服务器所在的网段。理解host字段的匹配逻辑很重要当你从某台机器连接时MariaDB 会根据你的 IP 找到匹配的 user 条目如果有多条匹配会选最精确的那条。我曾经见过某个账号的 host 写成了192.168.1.%应用没在这个网段连了半天都连不上。还要提醒一点改完权限后执行FLUSH PRIVILEGES是把权限表重新载入内存。虽然CREATE USER和GRANT本身已经生效不需要刷但养成这个习惯没坏处尤其是你直接改了mysql.user表的时候不刷新可能会遇到奇怪的权限问题。5.3 常见连接失败原因速查远程连接失败这个问题我处理过太多次在这里直接说结论如果是ERROR 2003 (HY000): Cant connect to MySQL server on ...多半是网络层面的问题IP 不通、端口没监听、防火墙挡了。先用ping和telnet IP 3306这种工具分段排查。如果是ERROR 1045 (28000): Access denied for user ...是认证或权限问题密码不对、host 不匹配、账号不存在。用刚才讲的 user 表查询确认。如果是ERROR 2013 (HY000): Lost connection to MySQL server during query常见原因有连接超时、max_allowed_packet太小、网络不稳定。处理办法是适当调大max_allowed_packet同时检查连接池keepalive设置。还有一个很隐蔽的问题客户端和服务端的连接协议版本不一致。比如用特别老的 MySQL 客户端去连新版 MariaDB会报Client does not support authentication protocol requested by server。解决方式是把客户端的认证插件升级或者让服务端改用 mysql_native_password。MariaDB 默认就是 mysql_native_password所以这种坑相对少但如果你是从 MySQL 8.0 那边带着旧客户端过来还是有可能碰到的。6. 备份、迁移与应急恢复6.1 逻辑备份首选 mysqldump 的用法数据库运维里最不能省的就是备份。MariaDB 自带mysqldump用起来和 MySQL 完全一样。我在正式环境里最常用的备份命令是这样mysqldump -uroot -p --single-transaction --routines --triggers --events --databases mydb mydb_$(date %F).sql参数解释一下--single-transaction是给 InnoDB 用的备份在不锁表的前提下基于事务快照导出避免影响业务--routines、--triggers、--events分别导出存储过程、触发器、事件调度器这仨经常有人漏掉等到恢复时才惊觉缺了一大块。--databases表示后面几个库要带上 CREATE DATABASE 语句这样恢复时数据库会自动建好。恢复就一条命令mysql -uroot -p mydb_2025-06-01.sql如果备份文件里不带 CREATE DATABASE就先手动建库再导入。逻辑备份的优点是可在不同版本、不同平台之间迁移缺点是数据量大时导出时间长、恢复也慢。几 GB 以内的库用它没问题几十 GB 以上就不要靠它了。6.2 大数据量用物理备份 mariadb-backup数据量一大就得换物理备份。MariaDB 官方的备份工具是mariadb-backup它是在 Percona XtraBackup 基础上演化来的原理是直接复制数据文件同时基于 InnoDB 的 redo log 做一致性处理比 mysqldump 快一个数量级。全量备份示例mariadb-backup --backup --target-dir/backup/mariadb/full --userroot --passwordxxx恢复的时候先准备备份让日志回放到一致状态mariadb-backup --prepare --target-dir/backup/mariadb/full然后停止服务把原数据目录替换掉systemctl stop mariadb mariadb-backup --copy-back --target-dir/backup/mariadb/full chown -R mysql:mysql /var/lib/mysql systemctl start mariadb不要小看那个chown步骤权限不对的话 MySQL 进程会直接起不来报错日志里全是 permission denied。物理备份恢复速度非常快几个 GB 的库基本一分钟内能恢复缺点是恢复到的目标机器最好和原机器配置相近跨大版本迁移容易出现兼容问题。6.3 主从复制的最小配置如果你有两台服务器想让一台实时同步另一台的数据最轻量的方案就是主从复制。MariaDB 的复制配置比很多人想象中简单。先在主库的配置文件里开 binlog 和服务 ID[mysqld] server-id 1 log_bin /var/log/mysql/mariadb-bin然后在主库建一个复制专用账号CREATE USER repl10.10.8.% IDENTIFIED BY 复制密码; GRANT REPLICATION SLAVE ON *.* TO repl10.10.8.%; FLUSH PRIVILEGES;查看当前日志文件位置SHOW MASTER STATUS;记下 File 和 Position 两个值。接着在从库上指定CHANGE MASTER TO MASTER_HOST主库IP, MASTER_USERrepl, MASTER_PASSWORD复制密码, MASTER_LOG_FILEmariadb-bin.000001, MASTER_LOG_POS787; START SLAVE;查看复制状态SHOW SLAVE STATUS\G重点看Slave_IO_Running: Yes和Slave_SQL_Running: Yes都是 Yes 就说明在正常同步。如果Slave_IO_Running显示 Connecting通常是网络不通或者复制账号密码不对如果Slave_SQL_Running显示 No多半是某条 SQL 在主从两端执行结果不一致需要具体看Last_SQL_Error字段。主从复制不是备份的替代品。有人以为有了主从同步就不需要备份这是非常危险的想法——如果误执行了 DELETE 或者主库数据文件损坏从库也会跟着坏掉。复制解决的是高可用和读写分离备份解决的是数据损坏和误操作两件事得同时做。6.4 密码忘了怎么进应急手法“root 密码忘了”是服务器运维里最高频的问题之一。如果你之前配置了 unix_socket 认证那最简单系统 sudo 用户直接mysql就能进然后重新设置密码。如果 root 走的是密码认证又忘了就得走应急通道。先停服务systemctl stop mariadb然后临时以跳过授权表的方式启动mysqld_safe --skip-grant-tables 这时候任何用户都能免密进入。进库之后先刷新权限表让密码相关操作能生效FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;改完把服务正常重启mysqladmin -uroot -p shutdown systemctl start mariadb这里必须强调--skip-grant-tables状态下数据库没有任何访问控制这种临时启动方式只准在你能直接控制服务器的物理或系统控制台情况下使用而且改完密码必须马上重启回正常模式。千万别开着这个模式就丢在那里不管。7. 常见问题速查表与个人经验7.1 问题速查表现象可能原因处理办法root 密码空想设置密码安装后未初始化密码用 ALTER USER 或 mysql_secure_installation本机能连远程连接超时bind-address 只有 127.0.0.1改 bind-address 并重启服务防火墙放行了还是连不上云安全组未放行 3306到云控制台安全组增加入站规则Access denied for user密码错误 / host 不匹配确认 user 条目的 host 是否覆盖来源 IPToo many connectionsmax_connections 过小调整参数并优化连接池项目中文乱码字符集不统一表和连接统一 utf8mb4NOW() 时间差了 8 小时服务器时区或数据库时区不对设置系统时区 default-time-zone无法启动服务数据目录权限不对检查 /var/lib/mysql 属主属组主从同步出现错误SQL 在两端执行不一致查看 SHOW SLAVE STATUS 的 Last_SQL_Error大量删除操作后数据丢失误操作依赖备份恢复不能靠主从救数据这张表基本覆盖了我日常运维里 80% 以上的问题。真遇到不在表里的第一步永远是去看日志。MariaDB 的日志一般写在/var/log/mysql/比如error.log启动失败、连接失败、复制中断都会在这里留下线索。很多新手一遇到问题就乱试命令其实先花两分钟看日志往往能直接找到原因。7.2 一些实操中踩过的坑最后说几个我亲身体会最深的点。第一个是“永远不要在业务高峰期调字符集”。之前有一次我给一个运营中的库改表字符集一张千万行的表 ALTER 跑了快一个小时期间表上的写操作全部阻塞业务直接报警。后来我都学乖了字符集这种全局改动放在维护窗口做或者提前在测试环境验证一遍耗时。第二个是关于连接池。Java 应用默认的连接池参数里有个maxLifetime如果比数据库的wait_timeout长就会出现连接被数据库端回收、应用却还拿它去查询的情况报错通常是 “Connection is not available, request timed out”。这不是数据库坏了是两端超时参数没对齐。处理方式是让连接池的 maxLifetime 小于数据库的 wait_timeout比如 wait_timeout 设 28800 秒连接池 maxLifetime 设 14000 秒。第三个是升级版本别跳太多。MariaDB 的主版本升级比如从 10.5 升到 10.11理论上可以直接dnf update但中间如果跨了好几个大版本某些系统表的格式可能不兼容。稳妥做法是先备份然后按主版本逐级升级每一步都验证一下数据和服务状态。我前几年图快从 10.3 直接升到 10.6结果启动时报系统表不兼容最后用备份恢复才救回来。从那以后凡是数据库升级我必先备份再说。第四个是关于 root 的远程登录。早些年为省事我确实干过让 root 能从任意 IP 登录的蠢事。后来有一次日志里看到了来自外网的暴力破解尝试才意识到这是在拿整个数据库裸奔。现在我的规则很简单root 只留 localhost业务账号给最小权限来源 IP 能写网段就不写%能写具体 IP 就不写网段。多花几分钟收权限后面能少处理很多安全事故。MariaDB 作为服务器上的核心组件其实并不复杂。把安装、设密码、调参、远程访问、备份这五件事做好它就能稳定跑很久。我在这套流程上踩过不少坑写出来的这些都是实打实验证过的方案。如果你正准备在自己服务器上部署 MariaDB照着这篇文章的流程走一遍基本能避开我当年踩过的绝大多数坑。