MySQL中DROP权限需显式授予且仅支持数据库级（如mydb.*），不支持单表粒度；权限修改后需FLUSH PRIVILEGES或重连生效；验证用SHOW GRANTS检查是否有DROP字样，并注意host精确匹配。
用户没有被授予 DROP 权限
MySQL 的权限是显式授权制，没给就真不能执行。DROP TABLE 依赖的是 DROP 权限，不是靠有 CREATE 或 ALTER 就能连带获得的。常见误操作是：用 GRANT ALL ON mydb.* TO 'u'@'%' 授过全权，后来又只 DROP USER 或删了账号，却没对现存用户做 REVOKE DROP ON mydb.* FROM 'u'@'%' ——结果权限还在。
验证方式很简单：用目标用户登录后执行 SHOW GRANTS;，看输出里有没有 DROP 字样。如果没有，就是缺这个权限。
DROP 权限只能控制到数据库级别
MySQL 不支持对单张表单独授予或回收 DROP 权限。像 GRANT DROP ON mydb.users TO 'u'@'%' 这种写法会直接报错，因为语法不合法。实际能设的最小粒度是 mydb.*（整个库）或 *.*（全局）。
这意味着：只要给了 DROP ON mydb.*，用户就能删 mydb 下任意表，包括你可能忘了的临时表、日志表、甚至 README 这种名字奇怪的表。
- 想限制更细？只能换思路：把高危操作隔离到专用账号，日常业务账号默认不给
DROP - 注意
TRUNCATE TABLE也走同一套权限检查，没DROP就会报ERROR 1142 (42000): TRUNCATE command denied to user
权限修改后没刷新或连接未重连
执行 REVOKE DROP ON mydb.* FROM 'u'@'%' 后，权限表磁盘数据确实改了，但 MySQL 服务端仍缓存旧权限。如果用户还连着旧连接，DROP TABLE 依然能成功——直到断开重连，或你手动执行 FLUSH PRIVILEGES;。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
典型踩坑场景：
- 运维在后台执行了
REVOKE，但开发同学用 Navicat 连着没关，继续删表成功，以为权限没生效 - 应用用了连接池，长连接复用，
FLUSH PRIVILEGES后仍需等连接重建才真正失效
错误信息里提到的表名可能是干扰项
像 DROP command denied to user 'mall'@'120.41.106.20' for table 'README' 这类报错，重点不在 README 是否真实存在，而在于权限检查发生在“查表是否存在”之前。MySQL 先验权限，权限不过就直接拒绝，根本不会去查 README 在不在库里。
所以别急着 SHOW TABLES LIKE 'README'，先确认权限和用户 host 是否匹配——'mall'@'120.41.106.20' 和 'mall'@'%' 是两个不同账号，后者不覆盖前者。
权限系统本身不复杂，但容易忽略缓存、host 匹配、以及 DROP 权限不可拆分这三点。一旦出问题，优先查 SHOW GRANTS、确认 FLUSH PRIVILEGES 是否执行、再核对连接来源 IP 是否与授权 host 完全一致。
