一 实战
 
# 第一个客户端，对 a = 4 执行更新操作，操作成功
mysql> update test_innodb_lock set b='4000' where a = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 第一个客户端，对 a = 9 执行更新操作，操作成功
mysql> update test_innodb_lock set b='9000' where a = 9;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

# 第一个客户端：执行 commit
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

# 第二个客户端：执行 commi
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

# 第一个客户端：查询 a = 4 和 a = 9
mysql> select * from test_innodb_lock where a in (4,9);
+------+------+
| a    | b    |
+------+------+
|    4 | 4000 |
|    9 | 9000 |
+------+------+
2 rows in set (0.00 sec)

# 第二个客户端：查询 a = 4 和 a = 9
mysql> select * from test_innodb_lock where a in (4,9);
+------+------+
| a    | b    |
+------+------+
|    4 | 4000 |
|    9 | 9000 |
+------+------+
2 rows in set (0.00 sec)

# 查询 from test_innodb_lock 的索引，这里有两个索引： test_innodb_a_ind 和 test_innodb_lock_b_ind
mysql> show index from test_innodb_lock;
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table            | Non_unique | Key_name               | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| test_innodb_lock |          1 | test_innodb_a_ind      |            1 | a           | A         |           8 |     NULL | NULL   | YES  | BTREE      |         |               |
| test_innodb_lock |          1 | test_innodb_lock_b_ind |            1 | b           | A         |           7 |     NULL | NULL   | YES  | BTREE      |         |               |
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)

# 第一个客户端：这里 b 是 varchar 类型，写成 b = 4000，会使得索引 b 失效，使得锁行变成了锁表
mysql> update test_innodb_lock set a=41 where b = 4000;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 第二个客户端：发生阻塞了，这就是上一句惹的祸，以为此时 test_innodb_lock 表已被锁上 
mysql> update test_innodb_lock set b='9001' where a = 9;

# 第一个客户端：执行commit
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

# 第二个客户端：阻塞解除
mysql> update test_innodb_lock set b='9001' where a = 9;
Query OK, 1 row affected (4.22 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 第二个客户端：执行commit

# 分别在两个客户端查表，结果正常了
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b1   |
|    3 | 3    |
|   41 | 4000 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9001 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)
 
二 结论
 
索引失效行锁变成表锁。

一.什么是Innodb?什么是行锁和表锁?
 
 
Innodb:是MySQL的数据库引擎之一，现为MySQL的默认存储引擎,其实也就是一套放在 MySQL后台的完整数据库系统，InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引.
 InnoDB 给 MySQL 提供了具有事务(transaction)、回滚(rollback)和崩溃修复能力(crash recovery capabilities),并且支持MVCC.
 
 
行锁:对一个表锁住某几行,其他事务对锁住的行不能进行写操作.
 
 
表锁:锁住整个表,其他事务对整个表不能进行写操作.
 
 
注意:这两个锁都是针对于事务来说的,没有开启事务或者是在一个事务里面也就不存在锁了.
 
 
二.行锁和表锁的特点.
 
行锁可以支持更好的并发,但可能发生死锁
表锁不会发生死锁,对并发支持低.
 
三.分类.
 
 
行锁.
 (1).共享锁: 在执行语句后加上lock in share mode,又叫读锁
 
当一个事务对某几行上读锁操作时,可以允许其他事务读,不允许写,但允许其他事务上读锁,
 
(2).排他锁: 在执行语句后加上for update,又叫写锁.
 
当一个事务对某几个上写锁时，不允许其他事务写，但允许读。更不允许其他事务给这几行上任何锁
 
 
表锁.
 
 
四.注意事项.
 
1.如果对某几行上行锁,但是没有索引,会变成表锁.行锁是针对索引来实现的
 
其实这里不太恰当的，并不是对变成表锁，而是对整个所有的数据行加行锁，因为在不使用索引的情况下，mysql并不知道哪些符合条件。会全部加锁返回。
       举例: 在一个事务中执行.
       SELECT * FROM account WHERE NAME IN(‘张三’,‘嗨’) LOCK IN SHARE MODE
       这个时候就会对整个表加锁.
       然后在另一个窗口执行. 将张三的名字改成张五
       UPDATE account SET NAME=“张五” WHERE id=2.
       就会发现不能更改,被锁住.但是如果对name加了索引就不会被锁住了.就会由表锁变为行锁.
 
2.两个事务不能锁同一个索引.
 
五.深入理解锁.
 
数据库的事务及其事务的隔离级别，但是数据库是怎样隔离事务的呢？这时候就牵连到了数据库锁。当插入数据时，就锁定表，这叫做”锁表”(其他不能做删除或新增操作,可以做更新)；当更新数据时，就锁定行，这叫做”锁行”。
 
锁在数据网络传输中是一个非常重要的概念，当多个用户对数据库进行操作时，会带来数据不一致的情况，所以，锁主要是在多用户情况下保证数据库数据完整性和一致性。
 
六.数据库得自动加锁,针对于InnoDB引擎.
 
当对表执行update,insert,delete操作时,会对涉及到得行默认加行级锁.其他事务可以读,但是不可以写.

有一些前提条件：
 
这个表有索引：
 
 
表的结构：
 
 
 
 
 
 
当一个事务对表的一行进行修改：
 
update test_innodb_lock set  a=4  where b=4000;
 
b 是varchar 型，但是输入的是int型。发生了类型转化，索引失效，导致 行锁变为表锁；

Mysql的InnoDB存储引擎支持事务，默认是行锁。因为这个特性，所以数据库支持高并发，但是如果InnoDB更新数据的时候不是行锁，而是表锁的话，那么其并发性会大打折扣，而且也可能导致你的程序出错。
 
而导致行锁变为表锁的情况之一就是：
 
SQL的更新（update）或者删除（delete）语句中未使用到索引，导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索（表锁）。而如果使用了索引的话，InnoDB只会通过索引条件检索数据，而只锁住索引对应的行（行锁）。
 
下面记录一下我遇到的问题：
 
描述：
 
系统中有一个实时的定时任务，当有条件触发的时候，会更新对应的表，就先叫其为A表；
 但是同时有一个任务有时候会对A表有写操作，因此当进行测试的时候，有时候会不固定的出“Lock wait timeout exceeded”的错误。
 　　当出现这个问题的时候，从很多的地方进行了分析，然后都无法得到正确的解决方案（因为描述1模块不是我写的，所以没有去查看更新表的代码操作）
 
导致原因：
 
在描述1中定时任务更新表A的时候，更新条件中没有使用索引，导致当进行定时任务更新表的时候形成了表锁。然后因为表A数据量比较大，检索较慢，然后导致了描述2中对表A的写操作的等锁超时。
 
最常见的索引：
 
主键：众所周知，自带最高效的索引属性，自动创建，聚簇索引
 唯一索引：属性值重复率为0，可以作为业务主键
 普通索引：属性值重复率大于0，不能作为唯一指定条件
 　　注意：对于普通索引，当“重复率”低时，甚至接近主键或者唯一索引的效果时，依然是行锁；但是如果“重复率”高时，Mysql不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而形成表锁。重复率高的情况下且数据量较小的情况下，可以不建立索引。