MySQL安全加固十大硬核操作：从账号权限到备份恢复的全链路指南

接手过一台别人的 MySQL 服务器，第一件事我通常不是看配置、不是看慢日志，而是先查用户权限和监听端口。有一次查完心里真的发凉：root 空密码、3306 直接暴露在外网、业务连接用的还是 root、binlog 没开、审计日志为零。这台机器居然扛着线上业务跑了两三年。类似这种“裸奔型”服务器我见得太多了，很多团队装完 MySQL 只要能连上、能跑业务，就再也不会碰它，直到某天被拖库、被删库、被勒索，才想起安全加固这件事。

这篇文章我盘点了一份 MySQL 安全加固的十大硬核操作清单，从安装选型、账号权限、网络暴露面、传输加密、审计日志、SQL 注入防御、关键参数、备份恢复到主从安全，基本覆盖了一条完整的数据库安全链路。每一块我都会讲清楚为什么这么做、具体怎么操作、常见的坑在哪。适合三类人看：刚接手 MySQL 运维、想系统补课的同学；用 MySQL 做业务但没精力专门搞安全的后端开发；以及自己搭服务器跑个人项目的独立开发者。全程以 MySQL 8.0 为主，5.7 的关键差异我也会点出来。

1. 为什么 MySQL 一台比一台不安全：先想清楚加固逻辑

1.1 大家根深蒂固的三个安全误区

先说几个我反复在客户现场听到的误区，不把这些观念掰过来，后面所有操作你都会觉得“没必要”。

第一个误区是“内网就安全”。很多团队觉得 MySQL 只在内网跑，外面访问不到，所以密码弱一点、权限大一点无所谓。但内网不等于安全，实际上大部分数据泄露事件不是外部黑客攻进来的，而是内部人员权限过大、账号共用、误操作导致的。内网只是一道很低的篱笆，翻过去太容易了。

第二个误区是“没人会对我们这种小公司下手”。攻击者不会管你公司大小，他们用扫描工具天天在全网扫 3306 端口，只要发现空密码或者弱密码的实例，几分钟之内就能进去。我见过不少个人站长的数据库被删，留下一个勒索 README 文件，就是因为 root 密码太弱，直接被自动化脚本扫到了。

第三个误区是“安全加固会影响业务”。这其实是个伪命题。真正影响业务的往往不是安全措施本身，而是你加安全措施的时候没有做好兼容性评估。比如开了 SSL 但客户端不支持、改了认证插件但驱动没升级、权限收得过猛把业务账号搞挂了。这些是操作问题，不是方向问题。

1.2 把精力花在刀刃上：先修最致命的洞

刚接触一批 MySQL 实例的时候，我建议按下面的优先级做排查，从最致命的问题开始处理：

1. root 空密码 / 弱密码、匿名账号存在 —— 这是最要命的，基本等于把门焊死但钥匙挂在门上。
2. 3306 端口对公网开放 —— 数据库直接暴露在互联网上，扫描器十分钟内就能发现。
3. 业务账号使用 root 或 SUPER 权限 —— 一旦业务被注入，攻击者直接拿到最高权限。
4. 密码策略关闭、密码长期不换 —— 默认策略下 MySQL 允许极弱的密码。
5. 无审计、无 binlog、无备份 —— 出事之后连怎么发生的、怎么恢复都不知道。

后面十个章节就是按这个优先级展开的，你有时间就全做，没时间也至少按这个顺序把前五条先处理掉。

2. 安装源与版本管理：安全加固从下决定那刻就开始了

2.1 别再用第三方打包版和来路不明的镜像

MySQL 安全的第一步不是改配置，而是装对版本。我见过太多生产环境用的是从各种下载站拿的“绿色版”“优化版”，这些版本你根本不知道它被改过什么。更常见的是用操作系统自带源里的 MySQL 5.6、5.5，这些版本早就停止维护，安全漏洞一抓一大把。

正确做法是使用官方源或者官方 Docker 镜像。官方源安装过程不复杂，以 CentOS/RHEL 系为例，先装官方仓库：

bash复制rpm -Uvh https://dev.mysql.com/get/mysql80-community-release-el7-7.noarch.rpm
yum install mysql-community-server

Ubuntu/Debian 用 apt 的话，先把 MySQL 官方 APT 仓库配置上，然后 apt update、apt install mysql-server。Debian 系容易踩的坑是系统自带源里默认的 mysql-server 是 MariaDB 或旧版本，apt 安装前先确认一下包来源。

用 Docker 的话，直接拉官方镜像，千万不要图省事去 Docker Hub 上随便找个 star 高的第三方镜像：

bash复制docker pull mysql:8.0
docker run -d \
  --name mysql-prod \
  -p 127.0.0.1:3306:3306 \
  -e MYSQL_ROOT_PASSWORD='YourStrongPass!2024' \
  -v /opt/mysql-data:/var/lib/mysql \
  mysql:8.0

注意我这里 -p 用的是 127.0.0.1:3306:3306，不是 3306:3306，这个区别后面讲网络暴露面的时候会专门展开。

2.2 版本选择建议：8.0 是底线，5.7 已进入倒计时

MySQL 5.7 虽然目前存量很大，但官方已经停止 GA 版本的更新维护。如果还在 5.7，我建议尽快规划升级到 8.0。8.0 在安全方面有几个实质性的提升：默认认证插件是 caching_sha2_password，比 5.7 的 mysql_native_password 安全得多；新增了角色管理，可以更精细地控制权限；部分参数默认值更严格，比如 secure_file_priv 默认 NULL 直接禁用 LOAD DATA INFILE。

当然，升到 8.0 不是没有代价。最典型的就是旧客户端/驱动的兼容问题。比如有些 Windows 机器上的程序用的还是老版本驱动，连接 8.0 会报 authentication protocol 不支持的错。后面第 4 章我会详细说怎么处理这个兼容问题。

2.3 更新路径要固定：定期打小版本补丁

很多团队 MySQL 装完就再也不管版本了，一跑就是两三年。实际上 MySQL 的版本更新里相当一部分是安全补丁，特别是那些标记为 CVE 的漏洞，攻击者拿到 PoC 之后会很快把它武器化。建议每季度至少看一次官方 Release Notes，大版本不变的情况下，小版本跟着官方节奏走。升级之前先在测试环境过一遍，特别是跑一下你业务里常用的 SQL 语句，避免升级后查询计划变化导致性能回退。

3. 第一次启动后的必做动作：初始化脚本与基础瘦身

3.1 mysql_secure_installation 到底做了什么

MySQL 装完之后，第一步永远是执行安全初始化脚本。这个脚本很多人嫌麻烦直接跳过了，但它确实是给一台新实例打底子的最快方式：

bash复制mysql_secure_installation

执行之后它会依次问你几个问题：

• 是否安装密码校验插件（VALIDATE PASSWORD COMPONENT）。这一步建议选装，后面还可以通过参数调整校验强度。
• 是否修改 root 密码。如果安装时已经设置了强密码，可以跳过。
• 是否删除匿名用户。一定要删。匿名用户在特定配置下可以无密码登录，而且权限不可控。
• 是否禁止 root 远程登录。如果你确实需要远程管理，这一步可以先选 No，但后面我会强烈建议你改用一个专门的管理员账号，而不是直接用 root。
• 是否删除 test 数据库。test 库默认任何用户都可以访问，属于典型的不安全残留，删掉就好。
• 是否立即刷新权限表。这一步会执行 FLUSH PRIVILEGES，让前面的变更立即生效。

我遇到过一种情况，执行完脚本之后业务连不上了，排查半天发现是脚本把匿名用户删了，而业务程序用的连接串里没写用户名，直接靠匿名用户连的。这种属于业务本身就埋了雷，删了匿名用户反而帮你提前暴露了问题。所以业务连接串一定要写明确切的用户名和数据库，不要依赖匿名用户这种“隐形依赖”。

3.2 手动核对初始化结果

如果你装的是已经跑过的旧实例，没法直接跑初始化脚本，那就手动核对几个关键点。下面这几条 SQL 是巡检必查项：

sql复制-- 查看所有用户和主机
SELECT user, host, plugin, authentication_string FROM mysql.user;

-- 查找空密码用户（注意 5.7 和 8.0 密码字段表现不同）
SELECT user, host FROM mysql.user WHERE authentication_string = '';

-- 查找匿名用户
SELECT user, host FROM mysql.user WHERE user = '';

核对的时候重点看三件事：有没有空密码账号；有没有 host 是 % 的 root；有没有匿名用户。这三类账号只要还在，你的数据库就相当于窗户没关。查到之后直接用 DROP USER 干掉，不要只改 host，直接删除最干净。

4. 密码策略与认证插件：把最薄弱的门锁换成防盗门

4.1 用 validate_password 组件把弱密码挡在门外

MySQL 8.0 里密码校验是通过组件实现的，默认可能没启用。启用方式很简单：

sql复制INSTALL COMPONENT 'file://component_validate_password';

装完之后可以通过下面几个参数控制校验强度：

sql复制SET PERSIST validate_password.policy = MEDIUM;
SET PERSIST validate_password.length = 12;
SET PERSIST validate_password.mixed_case_count = 1;
SET PERSIST validate_password.number_count = 1;
SET PERSIST validate_password.special_char_count = 1;

参数含义很直白：policy 是强度等级（LOW/MEDIUM/STRONG），length 是最小长度，后面几个是最少要包含的大小写字母、数字、特殊字符数量。个人建议生产环境至少 MEDIUM + 12 位以上。用 SET PERSIST 会同时写进配置并持久化，比直接改 my.cnf 更不容易出错。

特别注意一点：validate_password 组件对新密码生效，对已有密码不生效。也就是说如果老用户本身密码很弱，你需要手动 ALTER USER 强制修改，组件不会自动帮你把存量弱密码全部清掉。

4.2 密码过期策略：让密码真正地“会过期”

再强的密码，如果三年不换，泄露面也会变大。MySQL 支持给每个用户设置密码过期策略，两个层面可以做：

全局策略：

sql复制SET PERSIST default_password_lifetime = 90;

单用户策略：

sql复制ALTER USER 'app_user'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;

我想提醒的是，密码过期这个策略在落地时一定要提前通知业务方，并且确认驱动的连接方式。有些旧驱动不支持密码过期后的交互式修改流程，密码一到期，连接直接报错，业务就断了。稳妥的做法是先在测试库开一个小范围的过期策略，验证业务程序能在密码过期后正常改密或者轮换连接串，再推到生产。

4.3 caching_sha2_password 与旧客户端兼容问题

MySQL 8.0 默认认证插件是 caching_sha2_password，这是更安全的加密方式。但很多老一点的客户端和驱动默认用的还是 mysql_native_password，连接 8.0 时会直接报错：

code复制Authentication plugin 'caching_sha2_password' cannot be loaded

或者类似“client does not support authentication protocol requested by server”的提示。遇到这种情况，两条路可以走：

第一条路，升级客户端驱动。如果你用的是 JDBC、Python 的 pymysql、.NET 的 MySqlConnector 这类生态，新版本基本都支持缓存 SHA2，这是最推荐的方案。

第二条路，把该用户的认证插件降级成 mysql_native_password：

sql复制ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'YourStrongPass!2024';

这条路能快速解决问题，但它本质上是“为了兼容性牺牲安全性”，不建议作为长期方案。mysql_native_password 已经标记为废弃，未来版本会移除。比较合理的落地方式是：能升级驱动的尽量升级，短期内无法升级的再用第二条路，同时给这些账号单独设强密码并定期巡检。

5. 账号权限最小化：业务账号只给够用的权限

5.1 为什么不能让业务账号用 root

每次看到业务程序连接串写的是 root 我都特别头大。root 意味着这个连接一旦被 SQL 注入、被拿到，攻击者可以直接执行任何操作，包括修改表结构、删除数据、加载文件、甚至往系统里写文件。而按照最小权限原则，业务账号只应该有它需要的那些权限——绝大多数场景就是增删改查。

以一个典型的订单系统为例，合理权限是：

sql复制CREATE USER 'order_app'@'10.0.%' IDENTIFIED BY 'StrongPassword!2024';
GRANT SELECT, INSERT, UPDATE, DELETE ON order_db.* TO 'order_app'@'10.0.%';

注意 MySQL 8.0 里 CREATE USER 和 GRANT 是分开的两条语句，不像 5.7 可以在 GRANT 里直接带 IDENTIFIED BY。这个差异很多人迁移到 8.0 时会踩坑。

如果业务偶尔需要执行 DDL，比如做数据归档，那就单独准备一个迁移账号，只在需要的时候临时授权，用完立即回收。不要图省事把所有权限都挂给运维账号或者 root。

5.2 最小权限不等于只给增删改查

“最小权限”要结合业务形态来理解。比如：

• 只读报表业务：只给 SELECT 权限，甚至可以按库、按表拆分。
• 有定时任务批量更新的业务：给 UPDATE、DELETE 时，尽量限制在具体库甚至具体表。
• 需要用到存储过程的业务：单独评估 EXECUTE 权限，不要让业务账号拥有 CREATE ROUTINE、ALTER ROUTINE 这类高风险权限。

另外，很多团队经常因为“某个功能突然报权限不足”就直接给业务账号授一个 ALL PRIVILEGES，这是最懒也最危险的做法。正确姿势是先定位到底需要哪条语句、哪个对象，然后精确授权。权限不够顶多让功能暂停一小会儿，总比被攻击后数据全没了好。

5.3 权限审计与回收：定期做“权限晒单”

权限管理不是授完就完了，它是需要持续维护的。建议每个季度跑一次下面这条查询，把用户对应的权限列出来过一遍：

sql复制SELECT user, host, db, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Super_priv
FROM mysql.db
WHERE db <> '';

-- 查看某用户的具体权限
SHOW GRANTS FOR 'order_app'@'10.0.%';

看到有用户拥有 SUPER、CREATE USER、PROCESS 这类高危权限，逐个确认是不是真的需要。不需要的用 REVOKE 收回来。还有一类容易被忽视的是 MySQL 8.0 的角色和动态权限，比如 BACKUP_ADMIN、SYSTEM_VARIABLES_ADMIN，这些权限管理要比 5.7 细很多，巡检时也要一并看。

我自己的经验是，最好每个业务创建一个专用账号，一个业务一个账号，哪怕两个业务连同一个库，也各用各的账号。这样出了问题才能精确追溯到是哪个业务、哪台机器上发起的连接，不然所有业务共用一个账号，出事了连从哪进来的都查不到。

6. 网络暴露面收敛：别让数据库直接面对互联网

6.1 bind-address 和 skip-networking 的双保险

MySQL 默认监听 3306，但到底监听在哪个网卡上，取决于 bind-address。检查一下你当前实例的配置：

sql复制SHOW VARIABLES LIKE 'bind_address';
SHOW VARIABLES LIKE 'skip_networking';

如果 bind_address 是 0.0.0.0 或者 ::，意味着 MySQL 监听所有网卡，包括公网。除非你明确知道自己在做什么，否则强烈建议改成只监听内网地址或本机：

ini复制[mysqld]
bind-address = 127.0.0.1

改完之后重启 MySQL，再用 ss -lntp | grep 3306 看监听地址，应该只会出现 127.0.0.1:3306。如果这台机器上还跑着其他服务需要访问 MySQL，那就 bind 到具体的内网 IP，比如 bind-address = 10.0.0.5，而不是 0.0.0.0。

skip-networking 更极端，直接禁用 TCP 监听，只允许本地 socket 连接。适合单机部署、所有业务和应用都在同一台机器上的场景。不过要注意，如果你开了 skip-networking，但后面想用本机 TCP 方式连，比如写程序用 127.0.0.1:3306 连接，就连不上了，只能用 socket。这个参数和 bind-address 是双保险，我一般建议：能本地 socket 就本地 socket，必须走网络就 bind 具体内网 IP。

6.2 Docker 映射端口是最容易忽略的重灾区

用 Docker 跑 MySQL 的场景，端口映射非常容易出问题。我见过很多例子：docker run -p 3306:3306，默认就把端口绑到了宿主机所有网卡上，等于直接把 MySQL 暴露到宿主机所在网络的所有机器上，如果这台宿主机有公网 IP，那就直接暴露到公网了。

正确的做法是显式绑定回环地址：

bash复制docker run -d \
  --name mysql-prod \
  -p 127.0.0.1:3306:3306 \
  -e MYSQL_ROOT_PASSWORD='YourStrongPass!2024' \
  mysql:8.0

这样只有宿主机本机能通过 3306 访问 MySQL，其他机器要访问的话，走应用层连接或者 SSH 隧道，而不是直接把端口暴露出来。

6.3 防火墙规则：即使配置错了也有兜底

bind-address 是应用层的限制，防火墙是网络层的限制，两层的意义不一样。bind-address 配置错了，防火墙还能兜底。建议给 MySQL 单独配防火墙规则，只允许指定来源 IP 访问 3306：

bash复制# firewalld 示例
firewall-cmd --permanent --zone=public --remove-port=3306/tcp
firewall-cmd --permanent --zone=internal --add-source=10.0.0.0/8
firewall-cmd --permanent --zone=internal --add-port=3306/tcp
firewall-cmd --reload

如果有多台应用服务器要连数据库，就把这些服务器的内网 IP 一个一个加进去，别用 0.0.0.0/0。这个规则一开始可能会觉得麻烦，但一旦有人扫描你的公网 IP，你才会感激这层兜底。

7. 传输层加密：内网也不是绝对安全的信道

7.1 真的需要给 MySQL 配 SSL 吗

很多人觉得“内网环境没必要上 SSL”，但内网并非绝对可信。交换机镜像、ARP 欺骗、内网被横向渗透，都能让明文流量被截获。如果你的 MySQL 客户端和服务器之间跨越多个网络设备，或者同一网络里有不可控设备，SSL/TLS 就是必须的。

MySQL 8.0 默认会在数据目录下自动生成 SSL 证书和私钥，检查一下当前是否已经开启：

sql复制SHOW VARIABLES LIKE 'have_ssl';
SHOW VARIABLES LIKE 'ssl_ca';

如果 have_ssl 是 YES（8.0 默认就是），说明 SSL 能力已经可用。但“可用”不等于“强制使用”，客户端默认走加密还是明文连接，取决于客户端参数。很多客户端不显式加 ssl-mode 的话，使用的是 MySQL 的自动协商逻辑——服务器支持 SSL 才用 SSL，不支持就回退明文。这就留下了降级风险。

7.2 强制用户走 SSL 连接

如果你想让某个用户必须使用 SSL，修改用户即可：

sql复制ALTER USER 'app_user'@'%' REQUIRE SSL;

设置之后，该用户如果尝试用明文连接，会被服务器直接拒绝。在执行之前，先确认客户端那边支持 SSL 并已经配置好，不然改完业务就断连了。

测试 SSL 是否生效，可以用带 ssl-mode 的客户端连一下：

bash复制mysql -h 192.168.1.10 -u app_user -p --ssl-mode=REQUIRED -e "STATUS;"

如果显示 SSL: Cipher in use is ...，说明连接是加密的。如果显示 SSL: Not in use，那就说明 SSL 没走起来，需要排查客户端配置或者服务器证书链。

7.3 证书过期这个隐藏雷

自己生成的 SSL 证书是有有效期的，MySQL 会自动生成的有效期通常是一年。很多环境配完 SSL 就没人管了，证书过期那天，所有 SSL 连接突然全部失败，业务直接断。所以如果你配置了 REQUIRE SSL，一定要在监控里加上证书到期检查，比如定期用 openssl 检查证书有效期：

bash复制openssl x509 -enddate -noout -in /var/lib/mysql/ca.pem

生成一个脚本，证书剩余时间小于 30 天时告警，这样不用等出事了才去查。

8. 审计与日志：出了事才知道自己缺了什么

8.1 general_log 不是实时审计首选

MySQL 自带的 general log 能记录所有执行的 SQL，但它有两个致命问题：一是它会记录所有连接、所有 SQL，包括密码哈希等敏感信息，安全性本身就很差；二是高并发下写入日志的性能开销极大，生产环境轻易不要开。我见过有人为了排查问题直接 SET GLOBAL general_log = ON，忘了关，结果半天内磁盘被写爆，数据库直接不可用。

如果只是临时排查问题，可以短时间开一下、用完后立即关掉：

sql复制SET GLOBAL general_log = 'ON';
-- 排查完事
SET GLOBAL general_log = 'OFF';

但这不适合作为日常审计方案。真正的审计应该用 audit log 插件或者慢查询日志来配合。

8.2 审计日志插件：留痕的关键

MySQL 企业版自带 audit_log 插件，可以记录连接事件、SQL 执行事件等。如果你用的是社区版，可以用 Percona 的审计日志插件（Percona Audit Log Plugin），功能类似。启用之后，配置示例：

ini复制[mysqld]
plugin-load-add=audit_log.so
audit_log_strategy=ASYNCHRONOUS
audit_log_format=JSON
audit_log_file=/var/log/mysql/audit.log

审计日志的价值在于追溯。比如哪天有人把某张表 DROP 了，你可以通过审计日志看到是谁、从哪个 IP 用什么账号执行的这条语句。没有审计日志，遇到这种事基本上只能靠猜。

审计日志本身也是敏感数据，要限制文件的访问权限，防止攻击者进入系统后直接删日志灭迹。建议将审计日志定期同步到独立的日志系统，比如通过 Filebeat 传到 Elasticsearch 或专用日志平台，这样即使 MySQL 所在的机器被攻破，历史审计证据还在。

8.3 慢查询日志与 binlog：运维安全和数据安全的分界线

慢查询日志能帮你定位业务瓶颈，也能辅助发现异常。比如某条平常几十毫秒的慢查询突然变成几十秒，很可能是被注入了恶意的条件。建议开启慢查询，阈值设 2 秒以内：

ini复制slow_query_log = ON
long_query_time = 2
log_queries_not_using_indexes = ON

binlog 的意义更偏重数据安全。binlog 记录所有变更操作，它除了做数据恢复和主从复制，也是肇事追踪的一条线索。二进制日志注意几点：

• 用 binlog_format = ROW，日志更安全、恢复精度更高。
• 定期清理，别让 binlog 把磁盘塞满。8.0 用 binlog_expire_logs_seconds 控制保留时间，建议至少保留 7 天，有条件可以保留 30 天。
• binlog 同样要限制文件访问权限，它记录的内容可能包含敏感的 SQL 参数。

9. SQL 注入与存储过程/触发器边界：别把安全漏洞写进业务逻辑

9.1 为什么 SQL 注入在 MySQL 环境里反复出现

SQL 注入是 Web 层的问题，但最终受害的往往是数据库。很多后端开发有个误解，觉得 SQL 注入是“别人写代码的问题”，DBA 管不了。其实数据库这边的安全策略能很大程度上降低注入的危害，关键是保证数据库账号权限足够小，即使 SQL 被拼接了恶意条件，攻击者也没法做破坏性操作。

比如业务账号只有 SELECT 权限，注入后顶多能多查出一些数据；如果这个账号有 DROP、UPDATE、文件读写权限，那注入就变成了删库拖库。所以前面第 5 章的权限最小化，本质上就是 SQL 注入影响面的“截断阀”。

写 SQL 的时候，能用预处理语句就用预处理语句。以 MySQL 官方推荐的预处理方式为例：

sql复制PREPARE stmt FROM 'SELECT * FROM users WHERE username = ?';
SET @username = 'admin';
EXECUTE stmt USING @username;
DEALLOCATE PREPARE stmt;

在编程语言里，对应的是 JDBC PreparedStatement、Python 参数化查询这些，千万不要用字符串拼接的方式往 SQL 里塞用户输入。

9.2 存储过程和触发器的 definer 权限陷阱

存储过程、触发器、事件都有一个执行者身份问题，就是 DEFINER。如果定义存储过程时用的 DEFINER 是 root，那任何被授权 EXECUTE 该存储过程的用户，在调用时都会以 root 身份执行，哪怕他本身只是个低权限账号。这属于典型的权限提升漏洞，攻击者一旦拿到一个能调用该存储过程的账号，就相当于间接拿到了 root 权限。

排查方法：

sql复制SELECT routine_schema, routine_name, definer
FROM information_schema.routines
WHERE routine_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema');

同样的查询也适用于触发器：

sql复制SELECT trigger_schema, trigger_name, definer
FROM information_schema.triggers;

看到 definer 是 root 或高权限账号的，逐个评估：这个存储过程/触发器真的需要以高权限执行吗？如果不需要，重建为低权限 definer；如果确实需要，确保只有必要的业务账号有 EXECUTE 权限，并且对调用来源做限制。

另外，存储过程内部如果有动态 SQL，比如 PREPARE 拼接字符串再执行，前端输入一旦能影响拼接内容，注入风险会成倍放大。写存储过程时尽量少用动态 SQL，非用不可的情况下，对每个参数做严格校验。

9.3 SQL_MODE 的严格模式和安全性的关系

MySQL 的 sql_mode 直接影响 SQL 行为的严格程度。举个例子，如果没开启 STRICT_TRANS_TABLES，插入超长字符串会自动截断，宽松模式下这些“错误数据”会被静默写入。这种数据不仅会污染业务逻辑，还可能成为二次注入或绕过校验的跳板。建议至少开启：

ini复制sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

开启严格模式后，之前能跑的数据插入行为可能会报错，这也是需要先在测试环境验证的。不少团队升级数据库或者迁库之后发现业务报错，有相当一部分就是 sql_mode 变严格导致的。

10. 关键参数加固：一份可以直接抄的 my.cnf 模板

10.1 安全相关参数逐项说明

下面这份 my.cnf 模板我整理了不少项目，覆盖了常见的安全关注点。你可以根据自己的资源配置增删，但每一项我都标了含义和为什么：

ini复制[mysqld]
# 基本运行身份
user = mysql

# 监听地址，按需改为内网 IP
bind-address = 127.0.0.1
port = 3306

# 禁用 LOCAL INFILE，防止通过 SQL 读取客户端文件
local_infile = 0

# 限制 FILE 权限的读写目录，NULL 表示禁用
secure_file_priv = /var/lib/mysql-files

# 禁用符号链接，避免文件系统层面的越权
skip_symbolic_links = ON

# 连接安全
max_connections = 500
max_connect_errors = 1000
connect_timeout = 10
wait_timeout = 3600
interactive_timeout = 3600

# 严格模式
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

# 慢查询日志
slow_query_log = ON
long_query_time = 2
log_queries_not_using_indexes = ON

# binlog 与复制
server-id = 1
log_bin = mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 2592000

逐项解释几个容易忽略的点：

local_infile=0 是很多人忽略的。如果开启 local_infile，攻击者可以通过 LOAD DATA LOCAL INFILE 诱导服务器读取客户端本地的文件，比如 /etc/passwd、应用源码，这是不需要 FILE 权限就能做到的攻击手法，一定要关掉。

secure_file_priv 限制 SELECT ... INTO OUTFILE 的写入目录。默认 NULL 禁止文件写入，如果你依赖这个功能导出数据，就指定到一个专门的目录，不要给空字符串（空字符串表示不限制）。

skip_symbolic_links 防止 MySQL 支持符号链接导致的数据目录越权访问，这个参数 MySQL 8.0 已废弃，但 5.7 如果还有在用，务必加上。

10.2 改完配置后必须做的事和容易踩的坑

改完 my.cnf 之后，重启之前先做配置检查：

bash复制mysqld --validate-config

然后重启服务：

bash复制systemctl restart mysqld

重启后一定第一时间检查 MySQL 是否正常起来，别在配置里写了错参数导致起不来。检查方式包括看进程、看端口、看错误日志：

bash复制systemctl status mysqld
ss -lntp | grep 3306
tail -n 50 /var/log/mysql/error.log

另一个常见坑是：MySQL 8.0 的很多参数更推荐用 SET PERSIST 动态修改，直接改 my.cnf 之后如果没有正确重启，配置不会生效。反过来，如果你用了 SET PERSIST，修改会写入 mysqld-auto.cnf，这个文件同样重要，别把它删了，否则重启后已持久化的配置会丢失。我们团队曾经因为清理临时文件时误删了 mysqld-auto.cnf，重启后不少安全参数直接被重置成默认值，还好发现及时，不然又是一次裸奔事故。

11. 备份、恢复与主从安全：加固的最后一道防线

11.1 备份永远是安全加固里不可省的一环

前面讲了各种防止入侵的手段，但说实话，没有谁敢保证自己的数据库绝对不会被攻破。被攻破之后能不能恢复，取决于你的备份和恢复策略。很多公司完全没有备份或者备份了从未测试过恢复，结果真出事的时候发现备份文件是坏的，那还不如不备份，起码不会产生虚假的安全感。

逻辑备份用 mysqldump 是最常见的方式：

bash复制mysqldump \
  --single-transaction \
  --routines \
  --events \
  --triggers \
  --set-gtid-purged=OFF \
  -u backup_user -p \
  --all-databases > full_backup_$(date +%F).sql

物理备份推荐 Percona XtraBackup，它在备份 InnoDB 数据时更快，对业务影响也更小。无论用哪种方式，备份文件都应该加密存放，可以考虑用 gpg 或者直接加密到对象存储。

11.2 备份的加密和恢复演练比备份本身更关键

备份文件如果明文存放，攻击者拿到备份文件就等于拿到了整个数据库。所以备份完成之后要加密，并且加访问控制。这里给一个用 openssl 加密的简单示例：

bash复制openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in full_backup_$(date +%F).sql \
  -out full_backup_$(date +%F).sql.enc \
  -pass file:/etc/mysql-backup-key

密钥文件要单独管理，权限收紧到只有备份用户和管理员能读。

恢复演练同样重要。每个季度找一台闲置机器，用最近的备份做一次完整恢复，确认备份文件能正常拉起来、数据是最新的、业务关键表的数据条数对得上。这个过程很枯燥，但它是最后一条命脉。我见过太多环境，等真要恢复的时候才突然发现备份目录在某些机器上被同步任务删掉了。

11.3 主从架构里的账号与复制安全

如果你用了主从复制，复制账号也要遵守最小权限原则。复制账号只需要 REPLICATION SLAVE 权限，不要给其他任何额外权限：

sql复制CREATE USER 'repl'@'10.0.%' IDENTIFIED BY 'ReplStrongPass!2024';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.%';

从库上可以考虑开启 read_only：

ini复制[mysqld]
read_only = ON

这样即使从库被攻破，攻击者想直接写数据也写不进去，只能读。不过要注意，read_only 是给普通用户生效的，拥有 SUPER 权限的账号还是能写。所以不要把管理员账号批量分发给开发和业务人员。

安全加固中还有一点容易被忽视：搭主从时 CHANGE MASTER TO 的密码会以明文形式出现在 binlog 之外的 master.info 或复制配置里，注意这个文件的权限，不要被普通用户可读。复制链路本身最好也走 SSL，具体配置可以参考第 7 章的 SSL 方案。

12. 加固之后的巡检与我的几条实战体会

12.1 把安全巡检变成例行仪式

做完前面十项操作之后，真正让安全落地的是持续巡检。我习惯把安全巡检固化成一个脚本，定期跑一遍 MySQL 实例，检查下面这些点：

• 是否存在空密码用户、匿名用户、非本地 root 用户。
• 是否存在权限过大的用户（比如拥有 SUPER、CREATE USER、FILE 权限的账号数量是否异常增长）。
• 端口监听地址是否符合预期，有没有新增的映射端口。
• SSL 是否开启，是否所有关键用户都 REQUIRE SSL。
• 密码过期策略和复杂度参数是否生效。
• binlog、慢查询日志、审计日志是否正常开启，日志是否在按预期轮转。
• 备份任务是否成功执行，备份文件是否加密，磁盘剩余空间是否充足。

巡检不是做完一次就完了，建议至少每月跑一遍。我见过很多环境，安全加固做完了，三个月后新来的同事图省事，把所有用户都改成 root 权限，安全水位一夜回到解放前。

12.2 有些坑我是真的一步一步踩过来的

最后分享几条全是实战经验的体会。

第一，安全加固最大的阻力通常不是技术，而是业务侧的“不能动”。所以做任何安全操作之前，先跟业务确认清楚有哪些客户端在连、用的什么账号、什么驱动、有没有老版本连接串。宁可多花一天摸底，也不要贸然改配置导致业务断了再回滚。

第二，数据库安全这件事不是 DBA 一个人的责任。应用开发、运维、甚至产品都要有一定的安全意识。最典型的例子是 SQL 注入，光靠数据库端收紧权限是救不了的，后端代码必须用参数化查询，这个责任在开发。

第三，多用 MySQL 9.0/8.0 的自动能力，少用人工操作。比如用 SET PERSIST 持续化参数，用角色管理替代在多个账号上重复授权，用 INFORMATION_SCHEMA 表做权限审计。人工操作多一个环节就多一分出错风险，自动化永远比人肉可靠。

第四，真被入侵的时候，第一时间不是去删数据，而是先断网隔离、保留现场。把数据库进程停掉，把数据目录完整复制一份做取证，然后才进入恢复流程。没有保留现场就急着恢复，只会让攻击者如何进来的这个最关键问题永远查不清楚。

MySQL 的安全加固没有“做完”的时候，攻防双方都在进化，我们能做的就是把基础打牢、把水位守住、把风险敞口持续收敛。上面这十个方向，每一条都值得专门拉出来深入做，但先从这十步开始，已经能挡住绝大多数常规攻击了。