mysql修改端口号本身不会导致权限失效，所谓“权限失效”实为连接偏差：连错端口、host匹配失败（如localhost与127.0.0.1区别）、认证插件不兼容、服务未真正重启或配置未加载所致，需按监听端口、配置加载、bind-address、错误日志、user()与current_user()比对顺序排查。
MySQL修改端口号本身不会导致权限配置失效——权限信息存在 mysql 系统库的表里，和端口无关。你感觉“权限失效”，实际是连接行为或权限检查环节出了偏差，核心问题从来不在端口改没改，而在于：你连的是哪个实例、用的是哪个用户、走的是哪条认证路径。
为什么改了 port=3307 后突然连不上、报 Access denied？
最常见的情况是：你改了端口，但客户端仍试图连 3306（旧端口），或者连对了 3307，却因 host 匹配失败触发了错误用户账户。
-
'user'@'localhost'和'user'@'127.0.0.1'是两个独立账号：前者走 Unix socket（Linux/macOS）或命名管道（Windows），后者强制走 TCP/IP；改端口后若显式指定-h 127.0.0.1，就可能匹配到一个没授过权的'user'@'127.0.0.1' - MySQL 8.0+ 默认用
caching_sha2_password插件，老客户端（如 JDBC 8.0 以下驱动）连3307时可能静默降级失败，表现就是“能握手但查不到权限” - 你改了端口，但没重启服务，或重启失败（比如配置语法错、端口被占），结果还是连着旧实例——而那个旧实例上，该用户的权限可能真被 revoke 过
如何确认当前连接到底用了哪个用户和权限？
别猜，直接在已连上的会话里查：
- 看当前登录用户：
SELECT USER(), CURRENT_USER();——USER()是你声明的登录名，CURRENT_USER()才是 MySQL 实际匹配到的权限账户（关键！） - 查这个账户的真实权限：
SHOW GRANTS FOR CURRENT_USER(); - 确认端口是否生效：
SHOW VARIABLES LIKE 'port';，必须返回你设的值（如3307），否则说明配置根本没加载
改端口后权限“看似失效”的真实排查链路
按顺序验证，跳过任一环都可能误判：
- 先确认 MySQL 进程监听的是新端口：
netstat -tlnp | grep :3307（Linux）或netstat -ano | findstr :3307（Windows）——没输出？说明服务根本没起来，或配置未生效 - 检查配置文件是否被正确加载：
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "port"（Linux）或mysqld --defaults-file="C:\ProgramData\MySQL\MySQL Server 8.0\my.ini" --verbose --help | findstr port（Windows） - 确认
bind-address没锁死为127.0.0.1或localhost，否则远程连3307会被拒，本地连又可能走错 socket 路径 - 查错误日志：
tail -n 50 /var/log/mysql/error.log或 Windows 下找hostname.err文件，里面常有 “Authentication plugin … can’t be loaded” 或 “Can’t start server: Bind on TCP/IP port” 这类直白提示
真正容易被忽略的点：改端口后，很多脚本、连接池、Docker Compose 配置里还硬编码着 3306；而你手动测试时用 mysql -u user -p -P 3307 连上了，却忘了 -h 参数默认是 localhost，结果走 socket 而非 TCP，压根没经过新端口——这种“连对了但不是你以为的连法”的情况，比权限真丢了更难定位。
