事情的起因是这样的，今天同事碰到MYSQL奇怪的慢查询问题，大概如下：

select * from table where id=?

id是主键，按常理，这条SQL应该很快才对，但是每天都有不定期的出现慢的情况。

这个表只有三种操作，insert delete ,select。

经过下面的实验发现了一个很严重的问题，MYSQL的锁似乎有点暴力，在对表进行DML操作的时候，SELECT需要等待。

测试如下（分别对MyISAM和innodb引擎的表进行了测试)：

create table tbl_test1 (id int primary key) engine=myisam;

insert into tbl_test1 (3千万记录）

create table tbl_test2 (id int primary key) engine=innodb;

insert into tbl_test2 (3千万记录）

看看执行计划：

select * from tbl_test1 wher id=?+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
| id | select_type | table     | type  | possible_keys | key           | key_len | ref   | rows | Extra       |
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
|  1 | SIMPLE      | tbl_test1 | const | tbl_test2_idx | tbl_test2_idx | 4       | const |    1 | Using index |
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
1 row in set (0.00 sec)
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
| id | select_type | table     | type  | possible_keys | key           | key_len | ref   | rows | Extra       |
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
|  1 | SIMPLE      | tbl_test2 | const | tbl_test2_idx | tbl_test2_idx | 4       | const |    1 | Using index |
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+
1 row in set (0.00 sec)
+—-+————-+———–+——-+—————+—————+———+——-+——+————-+| id | select_type | table     | type  | possible_keys | key           | key_len | ref   | rows | Extra       |+—-+————-+———–+——-+—————+—————+———+——-+——+————-+|  1 | SIMPLE      | tbl_test2 | const | tbl_test2_idx | tbl_test2_idx | 4       | const |    1 | Using index |+—-+————-+———–+——-+—————+—————+———+——-+——+————-+1 row in set (0.00 sec)

好了，接下来开始执行一条删除的SQL

session1:delete from tbl_test1 where id <?session 2:select * from tbl_test1 where id=?session 3:show processlist;mysql> show processlist;+—-+——+———–+——+———+——+———-+—————————————–+| Id | User | Host      | db   | Command | Time | State    | Info                                    |+—-+——+———–+——+———+——+———-+—————————————–+|  3 | root | localhost | test | Query   |   23 | Locked   | select * from tbl_test2 where id=122767 ||  4 | root | localhost | test | Query   |   24 | updating | delete from tbl_test2 where id<6276758  ||  5 | root | localhost | test | Query   |    0 | NULL     | show processlist                        |+—-+——+———–+——+———+——+———-+—————————————–+3 rows in set (0.00 sec)mysql> show processlist;+—-+——+———–+——+———+——+———-+—————————————–+| Id | User | Host      | db   | Command | Time | State    | Info                                    |+—-+——+———–+——+———+——+———-+—————————————–+|  3 | root | localhost | test | Query   |   23 | Locked   | select * from tbl_test1 where id=10122767 ||  4 | root | localhost | test | Query   |   24 | updating | delete from tbl_test1 where id<6276758  ||  5 | root | localhost | test | Query   |    0 | NULL     | show processlist                        |+—-+——+———–+——+———+——+———-+—————————————–+3 rows in set (0.00 sec)

在SESSION1删除TBL_TEST2的某些记录时，SESSION2查询处于等待状态。

所以，DELETE如果慢的话，SELECT也跟着变慢了。这太不能接受了，而且myisam和innode都一样。

最不能理解的是删除的记录里面并没有包含我要查询的记录，为啥要等待呢？

接下来看看PostgreSQL:

同样的表，SESSION1在删除时，SESSION2的查询不会受到影响，SESSION2在SESSION1没有真正删除到被删除的行是，SESSION2是可以查询到该记录的。很明显在Postgresql做批量删除时，是行锁或块锁。所以并发度很好。

而MYSQL在删除时看样子不应该是行锁或块锁，所以并发性能不好。

在设计MYSQL的应用的时候，切记这种类型的SQL操作，防止并发下降.

（我对MYSQL还不太熟悉，哈哈，写的不对的话请多批评）