数据库死锁

Question

表结构：
CREATE TABLE `tab_callback_sms_instant` (
   `ID` bigint(15) NOT NULL AUTO_INCREMENT,
   `PHONE` varchar(20) DEFAULT NULL,
   `SMSCONTENT` varchar(300) DEFAULT NULL,
   `CREATTIME` datetime DEFAULT NULL,
   `UPDATETIME` datetime DEFAULT NULL,
   `TYPE` int(2) DEFAULT NULL,
   PRIMARY KEY (`ID`),
   KEY `PHONEINDEX` (`PHONE`),
   KEY `typeindex` (`TYPE`)
 ) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8
操作：1、DELETE FROM tab_callback_sms_instant WHERE TYPE=1
2、update tab_callback_sms_instant set type=1, updatetime=now（） where id=****
没弄明白数据库怎么加锁的，如何优化

Answer 1

DELETE FROM tab_callback_sms_instant WHERE TYPE=1这条语句需要删除多少数据

Answer 2

谢谢回复，删除数据数量不定，多了也就几百条；
大侠  这条语句数据库怎么加锁？我测试感觉所有行都加锁，update任意一条数据都锁住

Answer 3

type上有索引吗  没有索引的话肯定格式锁表的

Answer 4

有索引的   KEY `typeindex` (`TYPE`)

Answer 5

innodb 存储引擎在有索引的情况下会加行锁

Answer 6

谢版主我用的就是innodb
2、update tab_callback_sms_instant set type=1, updatetime=now（） where id=****
这条type值不等于1  也就是不应该被行锁锁住
我网上看了有个next-key locking有可能这个锁造成的   但我没明白这个范围锁怎么确定范围的

Answer 7

nextkey-locking表结构：（a列主键，b列非唯一索引）
mysql> desc t_innodb;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| a     | int(11)    | NO   | PRI | 0       |       |
| b     | varchar(5) | YES  | MUL | NULL    |       |
| c     | varchar(6) | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
3 rows in set (0.00 sec)两个并发：
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)mysql> update t_innodb set c='sohu' where b='xxx';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0其他session的情况：
         mysql> select * from t_innodb;
         +----+------+--------+
         | a  | b    | c      |
         +----+------+--------+
         |  1 | xxx  | NULL   |
         |  2 | yyy  | NULL   |
         |  3 | ccc  | NULL   |
         |  4 | ddd  | NULL   |
         |  5 | eee  | NULL   |
         |  6 | aaa  | taobao |
         |  7 | bbb  | baidu  |
         |  8 | ccc  | NULL   |
         |  9 | ddd  | NULL   |
         | 10 | eee  | NULL   |
         +----+------+--------+
         10 rows in set (0.00 sec)
         
         mysql> insert into t_innodb values(11,'aaa','sina');
         Query OK, 1 row affected (0.05 sec)         mysql> insert into t_innodb values(12,'xxx','sina');
         session被阻塞
         
         mysql> insert into t_innodb(a,c) values(12,'sina');
         Query OK, 1 row affected (0.06 sec)         mysql> insert into t_innodb values(13,'xxy','sina');
         session被阻塞 
         
         mysql> insert into t_innodb values(13,'yyy','sina');
         Query OK, 1 row affected (0.05 sec)         mysql> insert into t_innodb values(16,'www','sina');
         session被阻塞         mysql> insert into t_innodb values(16,'ddf','sina');
         Query OK, 1 row affected (0.05 sec)         mysql> insert into t_innodb values(18,'eee','sina');
         session被阻塞
         mysql> insert into t_innodb values(18,'eed','sina');
         Query OK, 1 row affected (0.07 sec)【结论】：b列上的非唯一索引，当‘xxx’行被锁定后，再插入与‘xxx’相同值就会发生阻塞;
 只有更新/插入与‘xxx’行无关的行数据时，才不会被阻塞（包括不明确的b列也不会被阻塞）。
 对于b列值'xxx'与'yyy'之间，'eee'与'xxx'之间的值的插入和更新都会被阻塞（‘yyy’值的插入和更新不会被阻塞），这就是next-key locking，为了保护session1的可能动作。
 即 [eee,xxx]与[xxx,yyy)，区间内的b值都会被锁定，即“上闭下开都锁定”。