MySQL 8.0+只读权限须按库+表粒度显式授权，不支持表名通配符；需脚本批量生成GRANT语句，避免越权、大小写不一致及命名不规范导致漏授，并注意连接重连生效。
只读权限必须按库+表粒度显式授权，不能靠角色继承
MySQL 8.0+ 虽支持角色（ROLE），但历史分表通常按时间命名（如 sales_2023_q1、sales_2023_q2），角色无法动态匹配表名通配符。直接对 db_name.sales_% 授权会失败——MySQL 不支持表名通配符在 GRANT 语句中（哪怕加反引号也不行）。
实操建议：
- 用脚本批量生成授权语句：查出所有匹配的历史分表名，拼
GRANT SELECT ON db_name.table_name TO 'analyst'@'%' - 避免给
SELECT权限时顺手加上SHOW VIEW——除非分析师真要查视图定义，否则多余且可能暴露元数据结构 - 如果分表数量超 50 张，别手敲；用
SELECT CONCAT('GRANT SELECT ON `', table_schema, '`.`', table_name, '` TO ''analyst''@''%'';') ...生成 SQL 后执行
禁止授予 USAGE 权限以外的全局权限
有些 DBA 习惯先执行 GRANT USAGE ON *.* TO 'analyst'@'%'，再逐库授权。这本身没问题，但务必确认没额外执行过 GRANT SELECT ON *.* 或 GRANT PROCESS ON *.*——后者会让分析师看到所有连接和正在执行的 SQL，属于严重越权。
检查方法：
- 运行
SHOW GRANTS FOR 'analyst'@'%'，逐行核对输出里是否含ON *.* - 特别注意
WITH GRANT OPTION是否被误加：它允许该用户转授权限，与“只读”目标完全冲突 - 若发现多余权限，用
REVOKE ... FROM 'analyst'@'%'精确回收，不要用DROP USER重来——会丢失密码哈希和账户属性
分表命名不规范时，权限会漏授或误授
常见陷阱是分表名混用下划线/横线、大小写不一致（如 log_202401 和 LOG_202402），而 MySQL 在 Linux 下默认区分表名大小写（lower_case_table_names=0）。这时 GRANT SELECT ON db.log_202401 对 LOG_202402 完全无效。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
应对方式：
- 统一要求分表命名小写+下划线（如
event_2024_q3），并在建表 DDL 中强制使用反引号包裹 - 授权前用
SELECT table_name FROM information_schema.tables WHERE table_schema = 'db_name' AND table_name REGEXP '^event_[0-9]{4}_[q][1-4]$'校验实际存在的表名 - 避免用模糊匹配脚本自动授权，比如把
event_backup也当分表授了权
权限生效延迟？别忽略 FLUSH PRIVILEGES 的适用场景
正常情况下，GRANT 执行后权限立即生效，无需 FLUSH PRIVILEGES。但如果你是在修改 mysql.user 表（例如直连 mysql 系统库 update 用户行），就必须执行 FLUSH PRIVILEGES，否则权限不会加载进内存。
所以关键判断点是：
- 用
GRANT命令授权 → 不需要 flush - 用
INSERT/UPDATE直改系统表 → 必须FLUSH PRIVILEGES - 不确定是否改过系统表？执行一次
FLUSH PRIVILEGES无害，但别养成“每次授权都 flush”的习惯——它会重载整个权限缓存，高并发时有轻微性能抖动
最易被忽略的是：权限变更后，分析师已建立的连接不会自动更新权限，需断开重连。这点常被当成“授权没生效”反复排查。
