MySQL原生不支持仅开放DML而禁用DDL的语句级白名单，因其权限模型中DDL（如DROP_PRIV）与DML（如SELECT_PRIV）字段独立且粒度仅限库级或全局级，必须显式REVOKE并清空全局DDL权限后按库授予DML权限方可实现。
MySQL 原生不支持“只给 DML、禁用 DDL”的精细语句级白名单。你无法通过 GRANT 语法单独开启 SELECT 却关闭同库的 DROP TABLE——因为 DDL 权限（CREATE_PRIV、DROP_PRIV、ALTER_PRIV）和 DML 权限（SELECT_PRIV、INSERT_PRIV 等）在 mysql.user 表中是独立字段，但它们的控制粒度只到「库级」或「全局级」，且没有中间态。
为什么 GRANT SELECT, INSERT ON db.* 不自动禁止 DDL
MySQL 的权限模型里，SELECT、INSERT 属于表级权限，而 DROP、ALTER 等 DDL 操作依赖的是库级（db 表）或全局（user 表）的对应 _PRIV 字段。只要用户在 mysql.db 表中某条记录的 Drop_priv = 'Y'，哪怕你没显式 GRANT DROP，他仍可能有权限——尤其当之前执行过 GRANT ALL ON db.* 后又 REVOKE 不彻底时。
- 检查真实权限用：
SHOW GRANTS FOR 'user'@'host';，别信自己“记得没给” -
REVOKE DROP ON db.* FROM 'user'@'host';必须显式执行，且需FLUSH PRIVILEGES;生效 - 如果用户有全局
DROP权限（mysql.user.Drop_priv = 'Y'），库级REVOKE无效
最可靠的做法：先清空全局 DDL 权限，再按库授权 DML
这不是“最佳实践建议”，而是当前 MySQL（含 8.0.33）唯一可落地的方案。绕不开的两步：
REVOKE CREATE, ALTER, DROP, INDEX, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EXECUTE ON *.* FROM 'user'@'host';GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'user'@'host';- 确认无残留：
SELECT Drop_priv, Create_priv, Alter_priv FROM mysql.user WHERE User='user' AND Host='host';应全为'N' - 对每个目标库重复第二步；跨库 DML（如
INSERT INTO backup.t SELECT * FROM prod.t）仍受目标库权限约束，需额外控制
触发器拦截 DDL 是伪需求，实际不可用
网上流传的 CREATE TRIGGER ... BEFORE DROP ON db.* 写法根本不存在——MySQL 不支持 DDL 触发器。所谓“DDL 触发器”是误传，源自混淆了 Oracle 或 PostgreSQL 的能力。你执行会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。
- MySQL 支持的触发器类型只有
BEFORE/AFTER INSERT/UPDATE/DELETE，仅限 DML -
event_scheduler和事件（EVENT）也无法监听或中断 DDL 执行 - 试图用存储过程封装 DDL 并加
CURRENT_USER()判断，前提是所有操作必须主动调用该过程——应用层不配合就形同虚设
READ ONLY 数据库模式 ≠ 用户 DDL 限制
ALTER DATABASE app_db READ ONLY = 1; 确实能阻止 DML 和 DDL，但它作用于整个库，且要求 MySQL ≥ 8.0.22。问题在于：
- 它不区分用户：所有账号（包括 root）对该库都只读，违背“仅限制某用户”的初衷
- 它不限制跨库操作：
CREATE TABLE backup.tmp AS SELECT * FROM app_db.t;仍可能成功（取决于backup库权限） - 它不能替代权限清理：一个拥有
CREATE全局权限的用户，仍可CREATE DATABASE或CREATE TABLE在其他库
真正容易被忽略的点是：权限变更对已建立连接不生效。用户保持长连接时，REVOKE 后仍可继续执行旧权限允许的操作，直到断开重连。生产环境必须配合连接池配置（如 maxLifetime）或主动 KILL 对应线程。
