不能只UPDATE mysql.user表的Host字段，因MySQL 5.7+默认用caching_sha2_password插件，旧客户端不支持，且host仅控制路由不决定认证方式；必须用ALTER USER显式指定mysql_native_password插件并设密码，否则改后仍报Access denied。
直接改 mysql.user 表的 Host 字段为 'localhost' 不可靠，MySQL 5.7+ 会因认证插件不匹配导致登录失败；必须配合 ALTER USER 显式指定插件，否则即使改了 host，mysql -h 127.0.0.1 -u root 也可能报 Access denied。
为什么不能只 UPDATE user 表的 Host 字段
MySQL 5.7 默认用 caching_sha2_password 插件，而旧版客户端（如 MySQL 8.0 之前的命令行、某些 Python 驱动）不支持它。如果你只执行：
UPDATE mysql.user SET Host = 'localhost' WHERE User = 'root' AND Host = '%'; FLUSH PRIVILEGES;
——用户记录看似“变回”了本地，但认证插件没变，mysql -h 127.0.0.1 仍走 TCP 连接，触发插件不兼容，直接拒绝登录。
- 现象：
Access denied for user 'root'@'127.0.0.1'，哪怕密码正确 - 根本原因：host 字段只是连接路由判断依据，不控制认证方式
- 风险：改错
Host可能同时锁死本地和远程访问，无回退路径
正确做法：用 ALTER USER 强制指定本地认证插件
目标是让 'root'@'localhost' 唯一存在，且使用兼容性最好的 mysql_native_password 插件。操作分三步：
- 先确认当前 root 用户的 host 和 plugin：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root'; - 如果存在
'root'@'%'，先删掉：DROP USER 'root'@'%'; - 重置本地 root 的认证方式：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_actual_password';
注意：不要省略 BY 'xxx' ——不带密码参数会导致密码被清空，下次本地登录直接失败。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
bind-address 和 socket 连接的区别必须分清
改完用户后，mysql -u root -p 能连上，不代表 mysql -h 127.0.0.1 -u root -p 也能连。因为：
-
localhost默认走 Unix socket（更快、更安全），不受bind-address影响 -
127.0.0.1强制走 TCP，依赖bind-address是否监听该地址 - 若
my.cnf中bind-address = 127.0.0.1，TCP 连接可用；若为0.0.0.0或注释掉，默认也监听127.0.0.1 - 但若设为
bind-address = ::1（IPv6 only），127.0.0.1就连不上
验证是否监听 TCP：ss -tln | grep :3306，看到 127.0.0.1:3306 才算生效。
生产环境建议彻底禁用 root 远程，改用专用账号
单纯把 'root'@'%' 改成 'localhost' 并不能防止其他用户被远程连接。真正安全的做法是：
- 删掉所有
@'%'用户：DROP USER IF EXISTS 'root'@'%'; DROP USER IF EXISTS 'admin'@'%'; - 对需要远程管理的场景，创建最小权限账号：
CREATE USER 'dba'@'192.168.1.%' IDENTIFIED WITH mysql_native_password BY 'strong_pass'; GRANT SELECT, PROCESS ON *.* TO 'dba'@'192.168.1.%'; - 防火墙只放行 DBA 管理网段，云服务器安全组禁止 3306 对公网开放
最关键的细节常被忽略：MySQL 的 Host 匹配是精确字符串比对，'localhost' 和 '127.0.0.1' 是两个完全独立的用户条目，改一个不影响另一个。
