select权限不包含元数据访问能力，show create table等需额外授予information_schema或show view权限；字段级dml权限不可靠，应按表控制；运维脚本宜动态授/回收权限；mysql 8.0角色适合运维但不推荐用于应用连接池。
只给 SELECT 权限时，为什么连 SHOW CREATE TABLE 都被拒绝？
MySQL 的 SELECT 权限不包含元数据访问能力。即使用户能查表内容，SHOW CREATE TABLE、DESCRIBE table_name、甚至 INFORMATION_SCHEMA 中对应表的查询，都需要额外的 SELECT 权限（对 information_schema 库）或 SHOW VIEW 权限（如果涉及视图）。
- 最小权限下，若应用仅需读取数据，就不要授予
SHOW DATABASES或全局SELECT - 如需让应用能自动探测表结构（如 ORM 的 auto-discovery），可单独授权：
GRANT SELECT ON information_schema.columns TO 'app_user'@'%';
但注意：这会暴露所有库的列名，应限制到具体业务库的information_schema子集（MySQL 8.0+ 支持行级过滤，但通常靠应用层隔离更稳妥） - 避免用
GRANT SELECT ON *.*—— 它隐式包含information_schema和performance_schema，风险远超预期
INSERT/UPDATE/DELETE 权限要按字段还是按表控制？
MySQL 原生不支持字段级 DML 权限（如“只允许 UPDATE status 字段”）。所谓“列权限”仅适用于 SELECT 和 INSERT（且 INSERT 列权限只约束 VALUES 列表，不限制 SET 子句），实际生产中几乎不用——维护成本高、易出错、ORM 生成的 SQL 常绕过列限制。
- 真正可控的是表级：为写操作创建专用账号，例如
app_writer，只授予INSERT, UPDATE, DELETE在app_db.orders上的权限 - 敏感字段（如
password_hash、deleted_at）必须靠应用逻辑拦截，不能依赖 MySQL 权限兜底 - 若需审计修改来源，优先用触发器 +
CURRENT_USER()记录，而非靠权限收缩——权限管不到“谁改了”，只管“能不能改”
如何安全地给运维脚本分配临时 DBA 权限？
直接给长期账号 SUPER 或 PROCESS 权限等于放弃最小权限原则。MySQL 5.7+ 支持 SET PERSIST_ONLY 和角色（ROLE），但更轻量的做法是动态授予权限 + 显式回收。
- 运维脚本开头执行：
GRANT RELOAD, PROCESS ON *.* TO 'deploy_user'@'localhost'; FLUSH PRIVILEGES;
- 脚本结尾必须执行：
REVOKE RELOAD, PROCESS ON *.* FROM 'deploy_user'@'localhost'; FLUSH PRIVILEGES;
（注意：REVOKE 不会报错即使权限原本不存在，所以建议搭配SELECT * FROM mysql.role_edges或SHOW GRANTS校验） - 禁止在脚本中使用
root或空密码账号；用mysql_config_editor存储加密凭据，并限定 host 为127.0.0.1而非%
MySQL 8.0 的角色（ROLE）真的适合权限分组吗？
角色解决了权限批量管理问题，但默认不激活——用户登录后需显式 SET ROLE，否则权限不生效。这对应用连接池极不友好，因为连接复用时角色状态不可控。
- 对 CLI 运维人员，角色很实用：
CREATE ROLE 'backup_admin'; GRANT LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_admin'; SET DEFAULT ROLE 'backup_admin' TO 'ops_user'@'%';
- 对应用账号，仍推荐直接授予权限，避免连接初始化时漏掉
SET ROLE导致偶发权限错误 - 角色无法替代资源限制（如
MAX_QUERIES_PER_HOUR），这些仍需在CREATE USER时指定
权限不是设一次就完事的事。每次加新表、换 ORM 版本、引入新监控工具，都要重新审视账号权限——最常被忽略的是 information_schema 的泄露面和连接池复用下的角色状态漂移。
