刚也被这个问题困扰，数据加工需要在备份库建临时表，用完后可以删掉，但是给drop后库也可以删除，也担心把库删掉
不只是动态sql的问题，当时新建的表建错了，就需要删掉，那就需要时时的去授权
管理员有drop权限应该够了
是的，并不是说通过一些其他方式也能实现要的效果的问题，只是说这个很常用的一个功能应该有，而且目前的这种DROP不分DATABASE和TABLE，风险还是挺大的。
不过这个是mysql本身也是这样的，tidb兼容mysql理论上两个行为一致的
TiDB 里权限管理面向的是表对象，粒度是表，不是库级别，表 Table 是实体，库 Schema 是一个逻辑概念。
控制表的权限就可以。
这个 想不出什么配置方法
实现不了
实现不了，删除和删表是同一个权限，如果能删表，批量删除表不就可以同样删除库了，那你设置不允许删库有何意义呢
创建role授权，然后把role权限反派到user，这样授权可能会省事些
1 个赞
我们要的效果只是想有便捷的命令可以实现独立的数据库和表权限控制，之所以需要独立的表权限控制是因为有某些表删表重建的需求，而且这种需求也很平常，比如：
（1）你刚开始创建了一个带随机主键（自增主键）的表，后面发现随机主键（自增主键）不需要，这个时候你只能删表重建；
（2）你刚开始创建了一个不带随机主键（自增主键）的表，后面发现需要随机主键（自增主键），这个时候你也只能删表重建；
但是删库是不允许的。
没有用的，通过角色权限控制也绕不开，DROP权限没有区分DROP DATABASE和DROP TABLE。
嗯嗯，目前看只能回收DROP权限，然后一个表一个表去赋DROP赋权，能实现，但是比较麻烦。
好像不行吧，赋予表权限后库是不是也有相应权限了？
在线执行ddl语句就行了，只是修改表结构，不需要删除重新创建
意思先回收db.* 全部drop权限，再具体指定表的drop权限，假如有多个用户情况，用role稍微方便些
https://docs.pingcap.com/zh/tidb/stable/dev-guide-use-temporary-tables#临时表
我猜你所谓的临时表，起始并没有利用mysql的临时表机制，而是建了一张真正的表。
如果只是建立临时表，这个权限可以单独给。而不是给create某个具体表的权限。
同理，因为tidb兼容mysql。所以mysql要怎么给一个表删除权限，tidb也只能这么做。
所以假设一个库里面有几千张表，你为了避开drop database的可能，就只能批量一个个表的添加drop权限。
横竖，这是个兼容mysql需要付出的代价。
和临时表没什么关系，但这确实有兼容mysql的原因，或者说从mysql拿过来没有进一步做细粒度的权限控制的原因。
临时建的表，比如清单，要根据清单坐操作，用完后删除，比如修改数据前备份，不是数据库定义的临时表