云服务器部署MySQL必须修改默认配置：确认配置文件路径、绑定0.0.0.0、关闭skip-networking、合理设置innodb_log_file_size；严格管理用户权限与host匹配；指定独立数据目录和日志路径；注意云平台快照、SELinux及DNS解析影响。
MySQL 云服务器首次启动前必须改的默认配置
云环境里直接用 MySQL 默认配置，大概率会连不上、写不进数据、或者被扫端口拖垮。重点不是“装没装好”，而是mysqld启动时读的配置文件路径和内容是否生效。
-
/etc/my.cnf或/etc/mysql/my.cnf是常见路径，但 Docker 或一键脚本可能写到/etc/my.cnf.d/下的独立文件，务必用mysqld --help --verbose | grep "Default options"确认真实加载顺序 - 云服务器默认绑定
127.0.0.1，远程连接失败？检查bind-address是否为0.0.0.0或具体内网 IP，**不要设成***（5.7+ 不支持） -
skip-networking必须关闭，否则 TCP 连接全拒 - 云盘 I/O 偏弱，
innodb_log_file_size别照搬本地配置，建议从128M起步，太大反而触发频繁刷盘
用户权限与远程访问的实际操作步骤
云服务器安全组放行了 3306，但还是连不上？90% 出在权限粒度或 host 匹配上。MySQL 的 user@host 是严格匹配的，'root'@'localhost' 和 'root'@'%' 完全是两个账户。
- 新装实例默认只有
'root'@'localhost'，执行CREATE USER 'app'@'%' IDENTIFIED BY 'xxx';后，必须立刻GRANT SELECT,INSERT ON db.* TO 'app'@'%';，不能只靠GRANT ALL（5.7+ 默认禁用） - 云服务器公网 IP 经常变化，别用
'app'@'114.114.114.114'这种固定 IP 授权，用'app'@'10.0.0.%'（对应 VPC 内网段）或'app'@'%'+ 强密码 + 安全组双重限制 - 改完权限必须
FLUSH PRIVILEGES;，但更推荐重启mysqld——某些云厂商镜像的权限缓存机制不稳定
磁盘空间与日志文件的隐蔽风险
云服务器系统盘小、数据盘挂载点不统一，MySQL 很容易把 ibdata1、binlog、slow_query_log 全塞进根分区，撑爆后服务静默退出。
- 初始化前就指定数据目录：
mysqld --initialize --datadir=/data/mysql，然后在配置中固化datadir = /data/mysql -
log-bin默认开，但没设expire_logs_days或binlog_expire_logs_seconds（8.0.28+），日志永不清，几周就能吃光 100G 磁盘 -
slow_query_log_file和general_log_file如果没指定绝对路径，会写进datadir，和 InnoDB 日志抢空间 - 用
df -h和du -sh /var/lib/mysql/*定期交叉核对，云监控里的“磁盘使用率”有时滞后
云厂商特有行为：备份、快照与 SELinux 干扰
阿里云 RDS、腾讯云 CVM、AWS EC2 上的自建 MySQL，会被底层机制悄悄影响。不是配置问题，是平台级干预。
- 某些云厂商的“系统盘快照”会强制冻结 MySQL 进程几秒，若此时正在刷
ib_logfile，恢复后可能报错InnoDB: Database page corruption——务必在快照前执行FLUSH TABLES WITH READ LOCK;并SERVICE mysqld stop - SELinux 在 CentOS Stream / Rocky Linux 云镜像中默认启用，
chcon -R -t mysqld_db_t /data/mysql才能让非标准路径读写正常，否则启动卡在Starting MySQL... ERROR! - 云 DNS 解析慢会导致
skip-name-resolve必开，否则连接时握手延迟高达 30 秒，且host字段全变成 IP，权限判断失效
sudo semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?" sudo restorecon -Rv /data/mysql
云环境部署 MySQL，最难的不是命令怎么敲，而是得同时盯住三层：MySQL 自身配置、操作系统层权限与挂载、云平台底层策略。少看一眼安全组，多写一行日志保留策略，都可能让服务在半夜三点掉线。
