MySQL 8.0 本地连接失败主因是服务未启动或 root 使用 auth_socket 认证；需先启服务，再查并改认证插件为 mysql_native_password，设密码后刷新权限。
MySQL 8.0 安装后连不上 localhost 怎么办
默认安装后 mysql 服务可能没启动，或者 root 用户被设为 auth_socket 插件认证（尤其 Ubuntu/Debian），导致 mysql -u root -p 直接拒绝登录。
- 先检查服务状态：
sudo systemctl status mysql，若 inactive 就运行sudo systemctl start mysql - 确认 root 认证方式：
SELECT user,host,plugin FROM mysql.user WHERE user='root';，如果 plugin 是auth_socket，需切到mysql_native_password - 临时切换（需先用 sudo 登录）：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES; - Ubuntu 22.04+ 默认禁用密码登录 root，不改插件就只能用
sudo mysql进去再改，别卡在“输密码却没设过密码”这一步
初始化配置文件 my.cnf 放哪、改哪些关键项
Linux 下优先级：/etc/my.cnf > /etc/mysql/my.cnf > /usr/etc/my.cnf > ~/.my.cnf；实际部署只动系统级配置，用户级会被忽略。
- 字符集必须显式设：
character-set-server = utf8mb4+collation-server = utf8mb4_unicode_ci，否则建库默认 latin1，后续改成本高 - 日志路径要提前建好并赋权：
log-error = /var/log/mysql/error.log，否则启动失败且错误日志不输出（陷入“服务起不来但看不到原因”的死循环） - bind-address 默认是
127.0.0.1，想远程连必须改成0.0.0.0或具体 IP，同时确认防火墙放行3306端口 - innodb_buffer_pool_size 建议设为物理内存的 50%~75%，但低于 2G 内存的机器别超过 1G，否则 swap 频繁拖垮性能
自动化脚本里怎么安全创建数据库和用户
不能直接 echo SQL 到 mysql 命令里——密码会暴露在进程列表（ps aux 可见），也不能硬编码密码到脚本中。
- 用
mysql_config_editor提前存连接凭据：mysql_config_editor set --login-path=local --user=root --password，之后脚本里用mysql --login-path=local -e "CREATE DATABASE ..." - 创建用户时指定 host 要谨慎：
CREATE USER 'app'@'%' IDENTIFIED BY 'pwd'允许任意 IP，生产环境应限制为应用服务器内网 IP，如'app'@'10.0.2.5' - 权限最小化：用
GRANT SELECT,INSERT,UPDATE ON mydb.* TO 'app'@'...';，别用GRANT ALL，尤其避免给mysql系统库权限 - 脚本末尾加
FLUSH PRIVILEGES;，否则新用户可能无法立即生效（尤其在某些 MySQL 版本或 SELinux 启用环境下）
脚本部署后验证连通性和权限是否真生效
自动化部署最常漏掉验证环节，结果上线才发现应用连不上，或连上但报 Access denied for user 却以为是密码错。
- 用目标用户直连测试：
mysql -u app -p -h 127.0.0.1 -e "SELECT DATABASE();"（注意必须用-h 127.0.0.1，用-h localhost会走 socket，认证逻辑不同） - 检查是否允许远程连接：
SELECT host,user FROM mysql.user WHERE user='app';，确认返回的 host 和你连接时用的 IP 匹配 - 模拟应用行为：在脚本末尾加一句
mysql -u app -p"pwd" -h 127.0.0.1 -D mydb -e "SHOW TABLES;" 2>/dev/null || echo "ERROR: app user can't access mydb" - SELinux 启用时，即使端口开放、用户权限正确，也可能因上下文限制拦截连接，临时关掉验证：
sudo setenforce 0，确认是它导致再配策略
所有自动化脚本里涉及密码的操作，都要避开命令行参数和明文变量；MySQL 的 host 匹配逻辑比想象中严格，localhost 和 127.0.0.1 在权限表里是两条记录；配置改完必须重启服务，systemctl restart mysql 不报错不代表配置加载成功——得看 journalctl -u mysql -n 50 里的实际日志。
