- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句可能会比较慢，因为需要排队等待
- 在正常集群启动后，第一个 DDL 操作的执行时间可能会比较久，可能是 DDL 在做 owner 的选举
这种情况应该查看哪些信息导致删除过慢？
对于 tidb 的 online ddl 来讲，drop table 保守需要 1s 左右，300 多张表可以估计出来，请问是否可以执行一个 drop table 的命令看下需要多久呢，一般情况可以从网络这边来排查
PS：希望可以正确选择帖子标签和分类~
一次最多删除所少表比较快呢
因为是串行的所以执行都是一样的。
我在导入数据和删除表的时候CPU和IO都挺高的，和磁盘有关吗
预期的吧，有操作此项应该会有波动，如果接受不能，可以调整导入数据的 thread
此项在哪调整
与导入工具有关，可以明示下使用的工具，找下他的帮助文档。tidb 这边没有此限制。
这是当时的监控信息 和系统资源有关吗
此 drop table 应该不符合预期的，辛苦反馈以下信息，
- select tidb_version();
- 使用以下工具将 tidb / tikv-detail / pd 监控完整上传下，辛苦，
- 如果方便，也可将执行 drop table 时，tidb / tikv / pd log 日志也上传下。
打开 grafana 监控，先按 d 再按 shift+e 可以打开所有监控项。
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
先按 d 再按 shift e 即可。点一下 dashboard 在操作
如果不是SSD磁盘会不会造成此种情况
不会，admin show dll jobs 看下返回信息
这个在哪执行
mysql cli ，navicat 也行，与 drop table 执行位置一致
admin show ddl jobs