只给DML权限的账号需显式授予SELECT、INSERT、UPDATE、DELETE，不授CREATE/ALTER/DROP等DDL权限；TRUNCATE属DDL需DROP权限，不可包含；授权后须验证CREATE/ALTER/DROP均报错且SHOW GRANTS无DDL关键词。
只给DML权限，不给DDL权限的账号怎么建
直接用 GRANT INSERT, UPDATE, DELETE, SELECT ON db_name.* TO 'user'@'host';，别碰 GRANT ALL PRIVILEGES 或 GRANT DDL 这类模糊写法——MySQL 没有 “DDL 权限” 这个独立权限项，它拆成 CREATE、ALTER、DROP 等具体权限，不显式授予就默认没有。
常见错误是顺手写了 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON ...，结果用户能建表；或者用 GRANT ALL ON db_name.* 后再 REVOKE DROP, ALTER，但 MySQL 的权限撤销在部分版本中不彻底（尤其跨库对象），不如从头只授必要项。
DML权限包含哪些操作，哪些容易被误当成DML
DML（Data Manipulation Language）严格指对表中数据的操作，包括：SELECT、INSERT、UPDATE、DELETE、REPLACE、LOAD DATA（需额外 FILE 权限）、TRUNCATE（注意：TRUNCATE 是 DDL 语句，不是 DML，执行它需要 DROP 权限）。
-
TRUNCATE TABLE t1→ 实际触发DROP + CREATE行为，必须有DROP权限，不能放进 DML 账号里 -
INSERT ... ON DUPLICATE KEY UPDATE→ 属于 DML，无需额外权限 -
SELECT ... INTO OUTFILE→ 需要FILE权限，不属于 DML，也不应授予 -
SHOW CREATE TABLE t1→ 查询元数据，不需要 DML 权限，但依赖SELECT权限（因访问INFORMATION_SCHEMA表）
权限生效后怎么验证没漏给DDL能力
用该账号登录后逐条测试关键 DDL 操作，观察是否报错：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
CREATE TABLE test_dml_only (id INT);→ 应报错ERROR 1142 (42000): CREATE command denied -
ALTER TABLE users ADD COLUMN remark VARCHAR(100);→ 同样应拒绝 -
DROP TABLE temp_log;→ 必须失败 -
SHOW GRANTS FOR CURRENT_USER;→ 输出里不能出现CREATE、ALTER、DROP、INDEX、CREATE VIEW等权限关键词
特别注意：如果账号之前被授予过 ALL PRIVILEGES，改用最小集后必须执行 FLUSH PRIVILEGES;，且已有连接不会自动刷新权限——得 KILL 对应线程或等其断开重连。
函数、视图、存储过程这些算不算DDL风险点
创建函数/存储过程/视图属于 DDL 操作，对应权限是 CREATE ROUTINE、CREATE VIEW、CREATE PROCEDURE，只要不显式授予，DML 账号就无法创建。但要注意：
- 调用已有函数或视图只需
EXECUTE权限（对函数）或SELECT权限（对视图），这两者都属于 DML 范畴，可以给 - 若函数定义里含
INSERT/UPDATE，调用它仍受 DML 权限约束，但函数本身运行身份（DEFINER）可能绕过调用者权限——所以确保DEFINER是高权限账号，且函数逻辑可控 - 避免把
mysql系统库或performance_schema的权限混进来，哪怕只是SELECT，也可能暴露敏感配置
最稳妥的做法是：权限只落在业务库的 db_name.* 上，不带通配符（比如不用 *.*），也不跨库授权。DDL 和 DML 的边界看似清晰，但实际权限粒度藏在每个动词背后，漏一个 CREATE 就可能让只读预期彻底失效。
