(推荐课程：mysql教程)
在这里还需要注意一件事情，如果数据库的buffer pool设置的很大，就会导致遍历时间变长清理buffer pool时，还包含清理ahi包含此表的数据，ahi的功能在这里就不多说了，主要是当b+tree的层级变高时，为避免b+tree逐层搜索，ahi能根据某个检索条件，直接查询到对应的数据页，跳过逐层定位的步骤。其次ahi会占用 1/16 的buffer pool的大小，如果线上表数据不是特别大，不是超高并发，不建议将开启ahi，可以考虑关闭ahi功能
mysql> show global variables like 'innodb_adaptive_hash_index';+----------------------------+-------+| variable_name | value |+----------------------------+-------+| innodb_adaptive_hash_index | on |+----------------------------+-------+1 row in set (0.01 sec)mysql> set global innodb_adaptive_hash_index=off;query ok, 0 rows affected (0.00 sec)mysql> show global variables like 'innodb_adaptive_hash_index';+----------------------------+-------+| variable_name | value |+----------------------------+-------+| innodb_adaptive_hash_index | off |+----------------------------+-------+1 row in set (0.01 sec)
2、删除对应的磁盘数据文件ibd在删除数据文件时，如果数据文件过大，删除过程会产生大量的io并耗费更多的时间，造成磁盘io开销飙升,cpu负载过高，影响其他程序运行。我的一个好伙伴，就曾在线上库删除了一张 1tb 大小的表，结果20分钟，数据库无响应，最后库崩溃，重启了。
既然知道drop table做了2件事情，那就针对以上 2 个事情进行优化
在清除buffer pool缓冲上，为减少当个buffer pool的大小，可以合理设置innodb_buffer_pool_instances参数，减少buffer pool数据块列表扫描时间，同时关闭ahi功能
在步骤2上，可以巧妙的利用linux的硬连接特性，延迟删除真正的物理文件。
当多个文件名同时指向同一个inode时,这个inode的引用数 n>1, 删除其中任何一个文件名都会很快.因为其直接的物理文件块没有被删除.只是删除了一个指针而已;当inode的引用数 n=1 时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;
如果给数据库表的.ibd文件创建一个硬链接，当删除表时，删除物理文件时，其实删除的就是物理文件的一个指针，所以删除操作响应速度会非常快，大约不到1秒左右
下面就来演示一下具体的操作
先创建表文件的硬链接ln t_test.ibd t_test.ibd.bak删除表drop table t_test;
最后就是要真正删除掉物理文件，释放文件所占用的磁盘空间，那么问题来了，如果优雅的删除物理文件呢，在这里推荐大家coreutils工具集中的truncate命令
当然需要你先安装相关的软件包
wget http://ftp.gnu.org/gnu/coreutils/coreutils-8.29.tar.xz使用非root进行解压tar -xvjf coreutils-8.29.tar.xzcd coreutils-8.29./configuremake使用root进行make install
安装好之后，就可以写一个脚本，非常优雅的分布删除大文件，${i}g 表示，每次删除 10g
#!/bin/bashtruncate=/usr/local/bin/truncatefor i in `seq 2194 -10 10 `; do sleep 2 $truncate -s ${i}g /data/mysql/t_test.ibd.hdlk donerm -rf /data/mysql/t_test.ibd.hdlk ;
以上就是怎么drop掉mysql库中的1tb表单的详细内容。