检查并修改 MySQL 默认端口避免冲突
MySQL 默认监听
3306端口，若服务器已运行其他 MySQL 实例、MariaDB 或某些数据库代理（如 ProxySQL），就会发生端口占用，启动失败时常见错误是：
Can't start server: Bind on TCP/IP port: Address already in use。
实操建议：
先用sudo lsof -i :3306或
sudo netstat -tuln | grep :3306查看谁占用了该端口 确认无误后，在配置文件
/etc/mysql/my.cnf（或
/etc/my.cnf）的
[mysqld]段下添加：
port = 3307（或其他未被占用的端口） 注意：修改端口后，所有客户端连接（包括命令行
mysql -P 3307、应用连接字符串）都必须显式指定新端口，否则会连不上 重启服务前务必执行
sudo mysqld --initialize-insecure --user=mysql（仅首次初始化）或直接
sudo systemctl restart mysql
限制 MySQL 监听地址增强网络隔离
默认配置中
bind-address可能为
127.0.0.1（仅本地）或
0.0.0.0（监听所有网卡），后者若未配防火墙，等于把数据库裸露在公网，极易被暴力扫描和利用。
实操建议：
生产环境强烈设为bind-address = 127.0.0.1，强制只响应本地连接；远程应用应通过跳板机、SSH 隧道或内网服务网格访问 若必须监听内网 IP（如
192.168.1.100），请确保该 IP 所属网卡不对外暴露，并配合系统防火墙（如
ufw或
iptables）放行指定源 IP：
sudo ufw allow from 192.168.1.50 to any port 3306禁用
skip-networking——虽然它能彻底关闭 TCP 连接，但会导致无法使用任何远程管理工具，运维成本陡增，不推荐
禁用 root 远程登录并最小化用户权限
MySQL 安装后常遗留
'root'@'%'这类通配主机用户，一旦密码弱或泄露，攻击者可直接远程提权。即使端口受限，内部员工误配或应用漏洞也可能触发横向移动。
实操建议：
登录后立即执行：DROP USER 'root'@'%';，保留仅
'root'@'localhost'为应用创建专用账号，限定来源主机（如
'app_user'@'192.168.1.30'），并只赋予必要库表的
SELECT, INSERT, UPDATE权限，不用
GRANT ALL密码必须启用强策略：MySQL 8.0+ 可设
validate_password.policy = STRONG，并检查
validate_password.length是否 ≥12 定期审计账号：
SELECT user, host, authentication_string FROM mysql.user;，重点关注
host列含
%或空值的记录
启用 MySQL 原生 SSL 加密连接
明文传输账号密码和敏感数据（如身份证、订单号）在内网也不安全，尤其当交换机被嗅探或存在中间人风险时。
ssl_mode=DISABLED是很多 ORM 默认行为，容易被忽略。
实操建议：
生成证书（可用 OpenSSL）后，在my.cnf中启用：
ssl-ca = /var/lib/mysql/ca.pem，
ssl-cert = /var/lib/mysql/server-cert.pem，
ssl-key = /var/lib/mysql/server-key.pem重启后验证：
SHOW VARIABLES LIKE '%ssl%';应全部为
ON或显示路径；再查
SHOW STATUS LIKE 'Ssl_cipher';确认非空 客户端连接必须显式要求加密：
mysql -u app_user -p --ssl-mode=REQUIRED；应用代码中也要设置对应参数（如 Python PyMySQL 的
ssl={'ssl': {}}）
注意：自签名证书会导致客户端报 SSL connection error: SSL is required but the server doesn't support it，此时需在客户端配置信任 CA，而非禁用 SSL 实际部署中最容易被跳过的，是把
bind-address和防火墙规则当成“二选一”——其实二者必须叠加生效；还有人以为改了端口就等于隐藏了服务，却忘了
nmap -sV -p 3307 target依然能精准识别 MySQL 版本并发起针对性攻击。
