mysql 删表引出的问题

约定不等于承诺〃 2024-03-16 20:33 18阅读 0赞

## 背景 ##

将测试环境的表同步到另外一个数据库服务器中，但有些表里面数据巨大，（其实不同步该表的数据就行，当时没想太多），几千万的数据！！

## 步骤 ##

1. 既然已经把数据同步过来的话，那就直接delete掉就行，多大的事呢？ 于是

delete from table_name where 1=1;

复制

结果傻眼了，执行了一会儿就卡死了，对卡死了！

2. 那么问题来了，是不是死锁了呢？那怎么判断死锁呢？

SHOW PROCESSLIST;

复制

![ac9210c2cbd975c2720563fc7db4a8aa.png][]

执行这个命令可以查看数据库当前的进程

3. 查看当前的事物

#当前运行的所有事务
    mysql> SELECT * FROM information_schema.INNODB_TRX;
    
    #当前出现的锁
    mysql> SELECT * FROM information_schema.INNODB_LOCKs;
    
    #锁等待的对应关系
    mysql> SELECT * FROM information_schema.INNODB_LOCK_waits;

复制

如果你是linux上直接执行mysql命令的话可以这样执行

`SELECT * FROM information_schema.INNODB_TRX\G`这样的话会换行展示数据，更人性化

4. 可以通过kill命令来干掉一些数据库的进程

![b5217d3b3de09fe3a2196e9105d25f3e.png][]

kill 2；

复制

这样既可，这样只是解决了卡死的问题，执行同样的命令还是会卡死的 ；

5. 那就想想为什么会卡死呢 ？原来有个这么一个参数

一般等待超时的时候会抛出这样的异常：

> Lock wait timeout exceeded; try restarting transaction

是因为mysql的话，默认锁等待时间是50s，就是说50s后就会报错，所以需要修改下个时间

mysql的配置一般都是在my.cnf文件中，自己找下

新增/修改`innodb_lock_wait_timeout=500`既可

6. 修改后重启mysql，这里面又涉及到mysql的关闭

bin/mysqladmin -uroot -p shutdown

复制

就关闭了sql的，不建议直接kill -9 ，不知道会出现什么幺蛾子

重启的话，还是用mysql\_safe去启动既可

7. 其实把，删除表数据的话，用truncate就行的 ，

truncate table table_name;

复制

8. 那么就比较下 drop，truncate，delete的区别吧

a. drop是整个表都没有了的，表结构也没没有了的，truncate和delete的表结构还在；

b. delete可以指定where条件删除哪一行，truncate是整个表的；

c. 来百度一下，^\_^

> 1. truncate和 delete只删除数据不删除表的结构(定义) drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index); 依赖于该表的存储过程/函数将保留,但是变为invalid状态. 2.delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发. truncate,drop是ddl, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger. 3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动 显然drop语句将表所占用的空间全部释放 truncate 语句缺省情况下见空间释放到 minextents个 extent,除非使用reuse storage; truncate会将高水线复位(回到最开始). 4.速度,一般来说: drop>; truncate >; delete 5.安全性:小心使用drop 和truncate,尤其没有备份的时候.否则哭都来不及

[ac9210c2cbd975c2720563fc7db4a8aa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/73e9deda7dc24694abfec03c0bb00405.png
[b5217d3b3de09fe3a2196e9105d25f3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1146f8a928084840a6761c6297e452f5.png