MySQL 8.0 创建开发只读角色需五步闭环：启用角色支持→创建带host的角色→授SELECT及information_schema权限→创建用户→绑定并SET DEFAULT ROLE；漏任一环（尤其host不一致或未设默认角色）将导致CURRENT_ROLE()返回NULL、权限不生效。
MySQL 8.0 中创建“开发角色”并设为默认只读权限，不能靠一步命令完成；必须严格走完五步闭环：启用角色支持 → 创建角色 → 给角色授 SELECT 权限 → 创建用户 → 绑定并激活角色。漏掉 SET DEFAULT ROLE 或角色没带 host 段，CURRENT_ROLE() 就会返回 NULL，权限实际不生效。
CREATE ROLE 前必须确认 activate_all_roles_on_login 已开启
MySQL 8.0 默认禁用角色功能。CREATE ROLE 会直接报错 ERROR 3719 (HY000) 或静默失败——这不是语法问题，而是全局开关未打开。
- 由 root 或高权限用户执行：
SET GLOBAL activate_all_roles_on_login = ON; - 同时授予角色管理权：
GRANT ROLE_ADMIN ON *.* TO 'admin_user'@'%'; - 写入配置文件持久化（否则重启失效）：在
my.cnf的[mysqld]段下添加activate_all_roles_on_login=ON - 执行
FLUSH PRIVILEGES;确保元数据刷新
给角色授只读权限必须明确对象和 host 段
角色本身是空容器，CREATE ROLE 'dev_reader' 后不授权，它就什么权限都没有。而且 MySQL 要求角色名必须带 host 段（如 'dev_reader'@'%'），否则后续绑定用户时会因 host 不匹配报 ERROR 3530。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 正确授权方式：
GRANT SELECT ON `myapp`.* TO 'dev_reader'@'%'; - 错误写法（绕过角色机制）：
GRANT SELECT ON `myapp`.* TO 'dev_user'@'%';—— 这是直授用户，无法复用、无法批量调整 - 注意：角色不支持列级授权，
GRANT SELECT(id) ON t1 TO 'dev_reader'@'%'会报ERROR 1142 - 如果开发需要查表结构（如 ORM 自动生成模型），还得额外加：
GRANT SELECT ON information_schema.TABLES TO 'dev_reader'@'%';和GRANT SELECT ON information_schema.COLUMNS TO 'dev_reader'@'%';，否则SHOW CREATE TABLE失败
SET DEFAULT ROLE 是权限生效的关键一步
GRANT 'dev_reader'@'%' TO 'dev_user'@'%' 只是在 mysql.role_edges 表里建了条记录，不会自动激活。用户登录后仍会 Access denied。
- 必须显式执行：
SET DEFAULT ROLE 'dev_reader'@'%' TO 'dev_user'@'%'; - host 必须完全一致：若角色是
'dev_reader'@'%'，就不能对'dev_user'@'localhost'执行该语句 - 该操作需要
SYSTEM_VARIABLES_ADMIN权限，普通用户无法自行设置 - 验证是否激活：
SELECT CURRENT_ROLE();返回非NULL值才算成功 - 别信
SHOW GRANTS FOR 'dev_user'@'%'—— 它默认不展开角色继承链；要查真实权限，得用：SHOW GRANTS FOR 'dev_user'@'%' USING 'dev_reader'@'%';
最容易被忽略的是 host 段的一致性、information_schema 的显式授权，以及 SET DEFAULT ROLE 这个看似多余却不可跳过的步骤。生产环境一旦漏掉任意一环，开发连 SELECT 都会失败，排查时却看不到明显报错。
