MySQL进阶（9）—— 并发参数调整及mysql锁的问题

1、MySQL并发参数调整

从实现上说，MySQL Server 是多线程结构，包括后台线程和客户服务线程。多线程可以有效利用服务器资源，提高数据库的并发性能。在 MySQL 中，控制并发连接和线程的主要参数包括 max_connections、back_log、thread_cache_siez、table_open_cache。

1. max_connections
   采用 max_connections 控制允许连接到 MySQL 数据库的最大数量，默认值是 151。如果状态变量 connections_errors_max_connections 不为零，并且一直增长，则说明不断有连接请求因数据库连接数已达到最大值而失败，这时可以考虑增大 max_connections 的值。

MySQL 最大可支持的连接数，取决于很多因素，包括给定操作系统平台的线程库的质量、内存大小、每个连接的负荷、CPU的处理速度、期望的相应时间等。在 Linux 平台下，性能好的服务器，支持 500-1000 个连接都不是难事，需要根据服务器性能进行评估设定。

2. back_log
   back_log 参数控制 MySQL 监听 TCP 端口时设置的积压请求栈的大小。如果 MySQL 的连接数达到 max_connections 时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即 back_bog，如果等待连接的数量超过 back_log，将不被授予连接资源，将会报错。5.6.6 版本之前默认值是 50，之后的默认为 50+ （max_connections / 5），但最大不超过900。

如果需要数据库在较短的时间内处理大量连接请求，可以考虑适当增大 back_log 的值。

3. table_open_cache
   该参数用来控制所有 SQL 语句执行线程可打开表的缓存的数量，而在执行 SQL 语句时，每一个 SQL 执行线程至少要打开 1 个表的缓存。该参数的值应该根据设置的最大连接数 max_connections 以及每个连接执行关联查询中涉及的表的最大数量来设定：

max_connections x N;

4. thread_cache_size
   为了加快数据库的速度，MySQL会缓存一定数量的客户服务线程以备重用，通过参数 thread_cache_size 可控制 MySQL 缓存客户端服务线程的数量。
5. innodb_lock_wait_timeout
   该参数是用来设置 InnoDB 事务等待行锁的时间，默认值是 50 ms，可以根据进行动态设置。对于需要快速反馈的业务系统来说，可以将行锁的等待时间调小，以避免事务长时间挂起；对于后台运行的批量处理程序来说，可以将行锁的等待时间调大，以避免发生大的回滚操作。

2、MySQL 锁问题

2.1、锁概述

锁 是计算机协调多个进程或线程并发访问某一资源的机制（避免争抢）。

在数据库中，除传统的计算资源（如：CPU、RAM、I/O 等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。

2.2、锁分类

从对数据操作的粒度分：

1. 表锁：操作时，会锁定整个表
2. 行锁：操作时，会锁定当前操作行

从对数据操作的类型分：

1. 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响
2. 写锁（排它锁）：当前操作没有完成之前，它会阻断其他写锁和读锁

2.3、MySQL锁

相对于其他数据库而言，MySQL 的锁机制比较简单，其最显著的特点就是不同的存储引擎支持不同的锁机制。下表中罗列出了各个存储引擎对锁的支持情况

存储引擎	表级锁	行级锁	页面锁
MyISAM	支持	不支持	不支持
InnoDB	支持	支持	不支持
MEMORY	支持	不支持	不支持
BDB	支持	不支持	支持

MySQL 这3中锁的特性可大致归纳如下：

锁类型	特点
表极锁	偏向 MyISAM 存储引擎，开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低
行极锁	偏向 InnoDB 存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高
页面锁	开锁和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般

从上述来看，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适。
仅从锁的角度来说：表级锁更适合以查询为主，只有少量按索引条件更新数据的应用，如web应用；行级锁 更适合于有大量按索引条件并发更新少量不同数据，同时又有并查询的应用，如一些在线事务处理（OLTP）系统。

2.4、MyISAM 表锁

MyISAM 存储引擎只支持表锁，这也是 MySQL 开始几个版本中唯一支持的锁类型。

2.4.1、如何加表锁

MyISAM 在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁。

这个过程并不需要用户干预，因此，用户一般不需要直接用 LOCJ TABLE命令给 MyISAM 表显示加锁。

显示加表锁语法：

加读锁：lock table table_name read;
加写锁：lock table table_name write;

2.4.2、读锁案例

准备环境

create database demo_03 default charset=utf8mb4;

use demo_03;

CREATE TABLE `tb_book` (
  `id` INT(11) auto_increment,
  `name` VARCHAR(50) DEFAULT NULL,
  `publish_time` DATE DEFAULT NULL,
  `status` CHAR(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=myisam DEFAULT CHARSET=utf8 ;

INSERT INTO tb_book (id, name, publish_time, status) VALUES(NULL,'java编程思想','2088-08-01','1');
INSERT INTO tb_book (id, name, publish_time, status) VALUES(NULL,'solr编程思想','2088-08-08','0');



CREATE TABLE `tb_user` (
  `id` INT(11) auto_increment,
  `name` VARCHAR(50) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=myisam DEFAULT CHARSET=utf8 ;

INSERT INTO tb_user (id, name) VALUES(NULL,'令狐冲');
INSERT INTO tb_user (id, name) VALUES(NULL,'田伯光');

这里我们打开两个mysql的客户端来进行测试：
客户端 一：
1）获得 tb_book 表的读锁

lock table tb_book read;

2）执行

select * from tb_book;

可以正常执行，查询出数据。

客户端 二：
3）执行查询操作

select * from tb_book;

客户端一：
4）查询未锁定的表

select name from tb_user;

客户端二：
5）查询未锁定的表

select name from tb_user;

可以查询出未锁定的表。

客户端 一：
6）执行插入操作

insert into tb_book values(null, 'mysql高级', '2088-01-01', '1');

客户端 二：
7）执行插入操作

insert into tb_book values(null, 'mysql高级', '2088-01-01', '1');

当客户端一 中释放指令 unlock tables后，客户端二 中的 insert 语句，立即执行；

2.4.3、写锁案例

客户端 一：
1）获得 tb_book 表的写锁

lock table tb_book write;

2）执行查询操作

select * from tb_book;

查询操作执行成功
3）执行更新操作

update tb_book set name = 'python编程' where id = 1;

更新操作成功；

客户端 二：
4）执行查询操作

select * from tb_book;

当在客户端 一 中释放锁指令 ublock tables 后，客户端 二 中的 select 语句，立即执行。

2.4.4、结论

锁模式的互相兼容性如表中所示：

由上表可见：
1）对 MyISAM 表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对统一表的写请求；
2）对 MyISAM 表的写操作，则会阻塞其他用户对同一表的读和写操作；

简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁，既会阻塞读，又会阻塞写。

此外， MyISAM 的读写锁调度是 写 优先。这也是 MyISAM 不适合作为写为主的表的存储引擎的原因。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞。

2.4.5、查看锁的争用情况

show open tables;

1. In_user：表当前被查询使用的次数，如果为零，则表是打开的，但是当前没有被使用。
2. Name_locked：表名称是否被锁定。名称锁定用于取消表或对表进行重命名等操作。

show status like 'Table_locks%';

1. Table_locks_immediate：指的是能够立即获得表级锁的次数，每立即获取锁，值加 1。
2. Table_locks_waited：指的是不能立即获取表极锁而需要等待的次数，每等待一次，该值加 1，此值越高说明存在着较为严重的表极锁争用情况。

2.5、InnoDB 行锁

2.5.1、行锁介绍

行锁特点：偏向 InnoDB 存储引擎，开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率最低，并发度最高。

InnoDB 与 MyISAM 的最大不同有两点：一是支持事务，二是采用了行级锁。

2.5.2、背景知识

1、事务及其ACID属性
事务是由一组 SQL 语句组成的逻辑处理单元。
事务具有以下 4 个特性，简称为 事务ACID属性。

ACID属性	含义
原子性（Atomicity）	事务是一个原子操作单元，其对数据的修改，要么全部成功，要么全部失败
一致性（Consistent）	在事务开始和完成时，数据都必须保持一致状态
隔离性（Isolation）	数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立环境”下运行
持久性（Durable）	事务完成之后，对于数据的修改是永久的。

2、并发事务处理带来的问题

问题	含义
丢失更新（Lost Update）	当两个或多个事务选择同一行，最初的事务修改的值，会被后面的事务修改的值覆盖。
脏读（Dirty Reads）	当一个事务正在访问数据，并对数据进行了修改，而这种修改还没有提交到数据库中。这时，另外一个事务也访问了这个数据，然后使用了这个数据。
不可重复读（Non-Repeatable Reads）	一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现和以前读出的数据不一致。
幻读（Phantom Reads）	一个事务按照相同的查询条件重新读取以前查询过的数据，却发现其他事务插入了满足查询条件的新数据。

3、事务隔离级别
为了解决上述提到的事务并发问题，数据库提供一定的事务隔离机制来解决这个问题。数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使用事务在一定程度上“串行化”进行，这显然与”并发“是矛盾的。

数据库的隔离级别有 4 个，由低到高依次为 Read uncommitted、Read committed、Repeatable read、Serializbale ，这四个几杯可以逐个解决 脏写、脏读、不可重复读、幻读这几类问题。

隔离级别	丢失更新	脏读	不可重复读	幻读
Read uncommitted	×	√	√	√
Read committed	×	×	√	√
Repeatable read（默认）	×	×	×	√
Serializable	×	×	×	×

备注 ： √ 代表可能出现 ， × 代表不会出现 。

MySQL 的数据库默认隔离级别为 Repeatable read，查看方式为：

show variables like 'tx_isolation';

2.5.3、InnoDB 的行锁模式

InnoDB 实现了以下两种类型的行锁。

• 共享锁（S）：又称为 读锁，简称 S锁 ，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
• 排他锁（X）：又称为 写锁，简称 X锁 ，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就 行 读取和修改。

对于 UPDATE、DELETE、INSERT 语句，InnoDB 会自动给涉及数据集加 排他锁（X）；
对于普通 SELECT 语句， InnoDB 不会加任何锁；

可以通过以下语句显示给记录集加共享锁或排他锁。

共享锁（S）：select * from table_name where ... lock in share mode
排他锁（X）：select * from table_name where ... for update

2.5.4、案例准备工作

create table test_innodb_lock(
	id int(11),
	name varchar(16),
	sex varchar(1)
)engine = innodb default charset=utf8;

insert into test_innodb_lock values(1,'100','1');
insert into test_innodb_lock values(3,'3','1');
insert into test_innodb_lock values(4,'400','0');
insert into test_innodb_lock values(5,'500','1');
insert into test_innodb_lock values(6,'600','0');
insert into test_innodb_lock values(7,'700','0');
insert into test_innodb_lock values(8,'800','1');
insert into test_innodb_lock values(9,'900','1');
insert into test_innodb_lock values(1,'200','0');

create index idx_test_innodb_lock_id on test_innodb_lock(id);
create index idx_test_innodb_lock_name on test_innodb_lock(name);

2.5.5、行锁基本演示

Session-1	Session-2
以上， 操作的都是同一行的数据，接下来，演示不同行的数据 ：

2.5.6、无索引行锁升级为表锁

如果不通过索引条件检索数据，那么 InnoDB 将对表中的所有记录加锁，实际效果跟表锁一样。

查看当前表的索引：

show index from test_innodb_lock;

Session-1	Session-2

由于执行更新时， name 字段本来为 varchar 类型，我们是作为数据类型使用，存在类型转换，索引失效，最终 行锁变为表锁。

2.5.7、间隙锁危害

当我们用范围条件，而不是使用相等条件检索数据，并请求共享或排它锁时，InnoDB 会给符合条件的已有数据进行加锁；对于键值在条件范围内但不存在记录，叫做“间隙（GAP）”，InnoDB 也会对这个“间隙”加锁，这种机制就是所谓的 间隙锁（Next-key锁）

Session-1	Session-2

2.5.8、InnoDB行锁争用情况

show status like 'innodb_row_lock%';

Innodb_row_lock_current_waits: 当前正在等待锁定的数量

Innodb_row_lock_time: 从系统启动到现在锁定总时间长度

Innodb_row_lock_time_avg:每次等待所花平均时长

Innodb_row_lock_time_max:从系统启动到现在等待最长的一次所花的时间

Innodb_row_lock_waits: 系统启动后到现在总共等待的次数


当等待的次数很高，而且每次等待的时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化计划。

2.5.9、总结

InnoDB 存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面带来了性能损耗可能比表极锁会更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表锁的。当系统并发量比较高的时候，InnoDB 的整体性能和 MyISAM 相比就会有比较明显的优势。

但是，InnoDB 的行级锁也有脆弱的一面，当我们使用不当的时候，可能会让 InnoDB 的整体性能表现不仅不能比 MyISAM 高，甚至会更差。

2.5.10、优化建议

1. 尽可能让所有数据检索都能通过索引来完成，避免无索引行锁升级为表锁。
2. 合理设计索引，尽量缩小锁的范围
3. 尽可能减少索引条件，及索引范围，避免间隙锁
4. 尽量控制事务大小，减少锁定资源量和时间长度
5. 尽可能使用低级别事务隔离（但是需要业务层满足需求）