MySQL 8.0+ 创建只读用户必须分两步：先 CREATE USER，再 GRANT SELECT；直接 GRANT 不存在用户会报 ERROR 1410；需指定 host、强密码及兼容认证插件，并显式回收 LOCK TABLES、FILE 等危险权限。
MySQL 8.0+ 创建只读用户必须用 CREATE USER + GRANT 分两步
直接 GRANT 一个不存在的用户在 MySQL 8.0+ 会报错 ERROR 1410 (42000): You are not allowed to create a user with GRANT。这是安全策略变更，不能再靠 GRANT 自动建用户。
实操建议：
- 先执行
CREATE USER 'reporter'@'%' IDENTIFIED BY 'strong_password123'; - 再执行
GRANT SELECT ON *.* TO 'reporter'@'%'; - 如果只需访问特定库（更安全），把
*.*换成sales_db.*或`reporting-2024`.*（库名含短横需反引号） - 最后别忘
FLUSH PRIVILEGES;—— 虽然多数情况下自动生效，但跨主机或权限缓存异常时它能兜底
MySQL 5.7 及更早版本要禁用 sql_mode=NO_AUTO_CREATE_USER
老版本默认允许 GRANT 建用户，但若启用了严格模式（比如部署时套了 Docker 镜像或云服务商模板），NO_AUTO_CREATE_USER 会被默认开启，导致同样报错。
检查方法：SELECT @@sql_mode;。若输出含 NO_AUTO_CREATE_USER，临时关闭需：
- 连接后执行
SET sql_mode=(SELECT REPLACE(@@sql_mode,'NO_AUTO_CREATE_USER','')); - 或永久修改配置文件
my.cnf的sql_mode行，删掉该项 - 注意：MySQL 8.0 已彻底移除此 mode，该步骤仅限 5.7 及以前
SELECT 权限不等于“真正只读”——要防 LOCK TABLES 和 SELECT ... INTO OUTFILE
只给 SELECT 看似安全，但用户仍可能执行 LOCK TABLES orders READ; 阻塞写操作，或用 SELECT * FROM logs INTO OUTFILE '/tmp/dump.csv'; 导出敏感数据（取决于 secure_file_priv 设置）。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
加固建议：
- 显式回收危险权限：
REVOKE LOCK TABLES, FILE ON *.* FROM 'reporter'@'%'; - 确认
secure_file_priv不为空（查SELECT @@secure_file_priv;），理想值是NULL或明确限制路径 - 如用 MySQL Router 或代理层，可在前端过滤掉含
INTO OUTFILE、LOCK、SHOW PROCESSLIST的语句
连接池和报表工具常因 autocommit=0 触发隐式事务，导致长事务阻塞元数据锁
很多 BI 工具（如 Metabase、Tableau）默认关自动提交，执行 SELECT 后不显式 COMMIT 或 ROLLBACK，会让事务一直挂着。这会导致后续对表结构变更（如 ALTER TABLE）被卡住，错误信息类似 Waiting for table metadata lock。
解决办法不是改用户权限，而是从使用侧控制：
- 在用户连接串里加
?autocommit=true（JDBC）或autocommit: true（Python mysql-connector） - BI 工具中关闭「Use transaction for queries」类选项
- 监控活跃事务：
SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE 'SELECT%';查长期未结束的查询
真正难处理的是跨库 JOIN 查询时的权限粒度——MySQL 不支持“只读视图跨库授权”，必须给所有涉及库的 SELECT 权限，哪怕只是查一个视图。这点容易在权限审计时被忽略。
