关于drop一张表却没有drop掉的问题

在数据库操作中遇到drop表命令执行失败的情况,通常由于进程占用导致。检查发现drop命令处于waiting状态,kill相关进程无效。最终发现是IDEA运行的程序占用了表资源,关闭IDEA后成功删除了表。解决问题时要注意检查程序是否占用资源。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

关于drop一张表却没有drop掉的问题

1.场景

  • 最近在搬一个项目,然后跑程序的时候报错了。一看,原来是我执行的建表sql还是旧的sql文件。于是打算先将这张旧表drop掉,再导出新的sql去建表。这时候就出现问题了:执行"drop table xxxxxx"的时候,执行了很久,也没能把表drop掉。
  • 首先确定一下方向:表删不掉,肯定是哪里有占用了。我们需要去找哪里占用了他,然后给他释放掉。

2.查找问题

  • 看正在执行的进程:
    show PROCESSLIST
    
  • 通过上一条命令,可以看到刚刚执行的drop命令处于waiting状态,除此之外没有别的进程在占用这张表。
  • 把查到的正在waiting的drop的进程kill掉。然后再次执行drop命令,仍然不能删除表。

3.问题的解决

  • 进程这里没找到,忽然想到是不是我刚刚起的程序访问这张表导致的占用。于是我把IDEA关掉了,再删就能成功删掉了。

4.结论

  • 表被占用时,除了看数据库执行的sql有没有占用外,也要注意一下程序有没有占用,或者程序有没有占用了却未释放。
### SQL `DROP TABLE` 与 `TRUNCATE TABLE` 的区别 #### 结构处理方式不同 - **`TRUNCATE TABLE`** 只会移除内的所有行,保留原有的结构及其约束条件、索引等属性不变。这使得当希望快速清空一张的数据而又不丢失其设计时非常有用[^3]。 - **`DROP TABLE`** 则不仅会删除内所有的数据,还会连同该本身一起从数据库中彻底移除,包括任何关联的对象如触发器、视图依赖关系以及权限设置等都将一并消失[^4]。 #### 对事务日志的影响差异 - 使用 **`TRUNCATE TABLE`** 命令执行的操作通常比使用带有无条件子句的 **`DELETE`** 更高效,因为它不会逐条记录每一行的变化到事务日志里去,从而减少了所需的系统资源消耗和提高了性能效率[^1]。 ```sql TRUNCATE TABLE example_table; ``` - 而对于 **`DROP TABLE`**, 它属于 DDL (Data Definition Language) 类型的操作,在某些情况下可能会产生较大的日志开销,尤其是在存在大量外键参照的情况下,因为需要更新这些对象的状态信息[^5]。 #### 是否可回滚特性对比 - 如果在一个显式的事务环境中运行了 **`TRUNCATE TABLE`**, 那么可以通过 ROLLBACK 来撤消此操作的效果;然而一旦提交,则无法再恢复已截断的数据[^2]. - 相反的是,由于 **`DROP TABLE`** 是一种不可逆的行为——它完全摧毁了一个的存在痕迹,所以不存在任何形式上的“撤销”机制来重新找回已被丢弃的信息. ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值