一次数据库夯死引发的思考

今天开发那边过来和我说他那边数据库无法提交数据，一直卡住

我查看了一下进程show processlist，发现有几条delete语句和insert语句，已经执行了6000多秒了，都是非常简单的语句

在RR模式下：

有几条语句：

alter table tbname drop primary key;  执行了6000多秒。

其他delete，insert操作也一直卡在哪里。

试验：

新建一个表：

CREATE TABLE TEST(

id int,

name varchar(20)

);

插入几条数据。

1、全表均无任何索引和主键。

语句：

DELETE FROM TEST WHERE ID = '1'

查看其执行计划后，发现扫描了全表。

2、name列增加索引，删除ID列：

DELETE FROM TEST WHERE ID = '1'

查看其执行计划后，发现扫描了全表。

3、name列增加索引，删除name列：

DELETE FROM TEST WHERE name = 'a'

查看其执行计划后，发现只扫描了一行数据，也就是说走了索引。

 

结论：

在删除或者更新的列上建立索引，否则会扫描全表。

mysql文档中查到：

删除和建立索引会对整张表进行重建操作。

alter table语句的算法有两种：

1、copy，将原表复制到临时文件中，然后修改完毕后再移动回原位。

2、in place。在原表上进行，会短暂锁定元数据。

一般来说：索引相关操作，更改列名，设置和删除列默认值，修改定义长度，更改自增量，这些操作不会涉及到重建表。