secure_auth参数仅控制是否拒绝旧密码格式（pre-4.1）的连接，与匿名用户读权限完全无关；匿名用户能否执行SELECT操作，取决于mysql.user表中对应账号的Select_priv字段值、host匹配情况及显式授权状态。
secure_auth 参数不控制匿名用户读权限，它只拒绝使用旧密码格式（pre-4.1）的账户连接。想限制匿名用户读权限，得靠账号权限体系，不是靠 secure_auth。
为什么 secure_auth 和匿名用户读权限完全无关
secure_auth 是认证握手阶段的开关：只要客户端尝试用 pre-4.1 密码哈希（比如 mysql_old_password 插件生成的）登录，服务器就直接断连。它不管你是 root、test 还是 ''（空用户名），也不管你有没有 SELECT 权限。
匿名用户（即 User 列为空字符串的账号）能否读数据，取决于 mysql.user 表里对应行的 Select_priv 字段值，以及是否匹配 host、是否被 GRANT 显式授权。
-
secure_auth=ON（默认）时，匿名用户若用新密码（native 或 sha256）仍可连，连上后权限照旧 -
secure_auth=OFF已被弃用，MySQL 5.7.5+ 强制启用，设为 OFF 会启动失败 - 即使把
secure_auth关掉，也无法“放开”匿名用户的读权限——那得靠GRANT SELECT ON *.* TO ''@'localhost'这类操作
真正限制匿名用户读权限的操作路径
匿名用户通常指 ''@'localhost' 或 ''@'%' 这类记录。限制其读权限，本质是清理或降权这些账号：
- 先查出所有匿名用户：
SELECT User, Host FROM mysql.user WHERE User = ''; - 撤销其全局读权限：
REVOKE SELECT ON *.* FROM ''@'localhost'; - 若不需要该账号，直接删掉：
DROP USER ''@'localhost'; - 注意：删除后需执行
FLUSH PRIVILEGES;生效 - 检查是否还有残留权限：查
information_schema.SCHEMA_PRIVILEGES和TABLE_PRIVILEGES表
secure_auth 的实际配置要点与坑
它虽不解决读权限问题，但配置错误会导致合法用户无法连接：
-
secure_auth是只读全局变量，运行时不能用SET GLOBAL secure_auth = OFF;修改 - 只能在
my.cnf的[mysqld]段写secure_auth=ON（其实不写也默认开启） - 如果数据库里还存着 pre-4.1 格式的密码（
Password字段长度为 16），启动时会报错并退出 - 升级老库前必须先用
ALTER USER ... IDENTIFIED WITH mysql_native_password BY 'xxx';更新密码格式 - MySQL 8.0+ 默认用
caching_sha2_password，和secure_auth无冲突，但旧客户端可能不兼容
真正影响读权限的是账号是否存在、host 是否匹配、SELECT_priv 是否为 Y，以及是否被 REVOKE 过。别被 secure_auth 的名字误导——它管的是“怎么连进来”，不是“连进来后能干什么”。
