GRANT语句不可拆分，过长主因是批量授权或脚本未换行；应拆为多条独立语句，每条针对单库表，语法正确即累加生效，无需FLUSH PRIVILEGES。
MySQL 的 GRANT 语句本身不支持“过长拆分”——它不是 SQL 查询，不能像 INSERT 那样按 VALUES 行切开；强行截断或拼接会导致语法错误或权限不完整。
为什么 GRANT 语句会“看起来过长”
常见于两类场景：
- 给一个用户授予大量数据库/表级权限，例如：
GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE, ALTER, INDEX, CREATE VIEW, SHOW VIEW ON `db1`.* TO 'u'@'%'; GRANT ... ON `db2`.*; ...—— 多个GRANT合并在一行或单条命令中提交 - 使用脚本自动生成权限语句时未换行，导致整条命令超 shell 命令行长度限制（如报错
mysql: argument line too long） - 在 MySQL 客户端（如
mysql -e "GRANT ..."）中直接传入超长字符串，触发系统级参数限制（如ARG_MAX）
直接拆成多条独立 GRANT 语句最安全
MySQL 明确支持重复执行 GRANT，且权限是累加的。只要每条都语法正确、目标明确，就可逐条运行：
- 把一条含 20 个库的长
GRANT拆成 20 条，每条只针对一个库：GRANT SELECT ON `db_a`.* TO 'u'@'%'; - 避免用逗号连写多个库名：
GRANT SELECT ON `db_a`.*, `db_b`.* TO ...是非法语法 - 拆分后记得统一执行
FLUSH PRIVILEGES;（仅当直接修改mysql系统表时才强制需要；常规GRANT会自动生效） - 如果用脚本生成，确保每条以分号结尾，并用换行分隔，再通过
mysql -u... -p 导入
用角色（ROLE）替代冗长 GRANT 更可持续
MySQL 8.0+ 支持角色，适合管理复杂权限集：
- 先创建角色：
CREATE ROLE 'app_reader'; - 批量授权给角色（可跨库）：
GRANT SELECT ON `sales`.* TO 'app_reader'; GRANT SELECT ON `inventory`.* TO 'app_reader'; - 再把角色授给用户：
GRANT 'app_reader' TO 'u'@'%'; - 启用角色：
SET DEFAULT ROLE 'app_reader' TO 'u'@'%'; - 后续增减权限只需改角色，不用反复重授用户
注意：角色不能用于 MySQL 5.7 及更早版本；且用户需显式激活（或设为默认）才生效。
别踩这些坑
容易被忽略但实际高频出问题的地方：
-
GRANT语句中的反引号（`）必须成对、不能嵌套，字段名或库名含特殊字符时漏掉一个就会报错ERROR 1064 - 用
mysql -e执行时，shell 层面对命令长度有限制（Linux 通常ARG_MAX ≈ 2MB），但实际触发点常远小于此——建议超过 50KB 就改用文件导入 - 远程执行时还受
max_allowed_packet影响，但该参数只控制「网络包大小」，不影响GRANT语法解析；它主要影响大INSERT或LOAD DATA，对权限语句基本无感 - 不要试图用存储过程或变量拼接
GRANT语句——MySQL 不允许在 SP 中动态执行GRANT
