Mysql---高级---4-CSDN博客

本文链接：https://blog.csdn.net/weixin_44761821/article/details/120578453

ps -ef|grep mysql 查到mysql 的进程

在这里插入图片描述
192.168.31.112 mysql 进入方法
cd /usr/local/mysql/bin/
./mysql -u root -p
123456

** 1.Mysql架构 **
在这里插入图片描述
插件式的存储引擎架构将
查询处理和其他的系统任务以及数据的存储提取相分离。

四层架构：连接层服务层引擎层存储层

在这里插入图片描述

**存储引擎 **

查询 mysql 提供了什么存储引擎
show engines;

在这里插入图片描述

查询当前 myql 使用哪个存储引擎
show variables like ‘%storage_engine%’;

在这里插入图片描述

** 索引优化 **

SQL 性能下降原因：执行时间长等待时间长
1.1 查询语句写的烂
1.2 索引失效：单值索引复合索引
1.3 关联查询太多 join （设计缺陷或不得已行为）
1.4 服务器调优各个参数设置（缓冲线程数）
SQL 执行顺序加载
2.1 人为手写过程

2.2 机器读取顺序

2.3 总结
七种 JOIN 理论

** 2.索引是什么？ **

索引是一种快速查找和检索数据的数据结构，
可以理解成排好序的快速查找数据结构。
索引的目的在于提高查询效率，可以类比字典。
索引会影响到 where 后面的条件查询和 order by 排序。
在 MySQL 中，MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是，两者的实现方式不太一样。
一般来说，索引本身也很大，不可能全部存储在内存中，索引往往以索引文件的方式存储在磁盘上。
在这里插入图片描述

在这里插入图片描述

索引官方含义：
数据本身之外，数据库还维护着一个满足特定查找算法的数据结构，
这种数据结构以某种方式指向数据（指针），这样就可以在这些数据结构的基础之上实现高级查找算法，这种数据结构就是索引。

** 索引优势劣势 **

优势：
1.类似于大学图书馆的索引，提高了数据检索的效率，降低了数据库 IO成本
2. 通过索引对数据的排序，降低了数据排序的成本，降低了 CPU 的消耗

  mysql的IO是指数据库文件的读写，也就是检索数据和插入数据。

劣势：
1.实际上索引也是一张表，该表保存了主键和索引字段，该索引列也需要占用磁盘空间。
2.虽然索引大大提高了查询效率，但会降低更新表的速度，如增删改。
（因为在更新表的时候， Mysql 不仅要保存数据，还要保存索引文件每次更新添加了的索引列的字段，然后都会调整因为更新所带来的键值变化后的索引信息。）
3.索引需要大量的维护，如花时间建立最优秀的索引，或者优化查询。

** 索引的分类 **

单值索引复合索引唯一索引

复合索引优于单值索引
一张表索引最多不要建立超过 5个索引。

单值索引：一个索引只包含单个列，一个表可以有多个单值索引。
唯一索引：索引列必须唯一，但允许为空值。
复合索引：一个索引包含多个列。

[] 代表可以省略

基本语法：

创建：
create [ UNIQUE ] index indexName（索引名） on mytable（表名） (column （length）) （字段）

CREATE INDEX t_dept_Name ON t_dept ( deptName );

alter table mytable（表名）add [ UNIQUE ] index [ indexName]（索引名） (column （length）) （字段）

ALTER TABLE t_dept ADD INDEX t_dept_Name ( deptName );

删除：
drop index [indexName] on mytable

DROP INDEX t_dept_Name ON t_dept;

查看：
show index from table_name\G(表名)

show index from t_dept;

CREATE INDEX t_dept_Name ON t_dept ( deptName );

DROP INDEX t_dept_Name ON t_dept;

ALTER TABLE  t_dept  ADD  INDEX t_dept_Name  ( deptName );

ALTER TABLE t_dept ADD INDEX t_dept_Name_address ( deptName ,address);

show index from t_dept;

使用 alter 创建 4种索引

alter table t_table add primary key （column_list）
该语句添加一个主键意味着索引值唯一不能为null

alter table t_table add unique index_name （column_list）
创建索引的值必须唯一（除了 null 外，null 可能多次出现）

alter table t_table add index index_name (column_list)
添加普通索引，索引值可能多次出现

alter table t_table add index_name （column_list，column_list2）
添加复合索引

alter table t_table add fulltext index_name (column_list)
添加全文索引

** mysql 索引结构**
BTree索引 Hash索引 full-text索引 R-Tree索引

BTree树索引原理：
在这里插入图片描述

** 哪些情况适合建索引**

适合建立索引情况：
1.主键自动建立索引
2.频繁作为查询添加的字段应该建立索引
3.查询中与其他表关联的字段如外键关系建立索引
4.频繁更新的字段不适合建立索引
（因为每次更新不单单更新了数据还会更新索引）
5.where 条件用不到的字段不建立索引
6.单键/复合索引（高并发情况下建议复合索引）
7.查询中的字段，排序字段如果通过索引访问将大大提供排序速度
8.查询中统计或者分组字段

** 哪些情况不适合建索引**
不适合建索引情况：
1.表记录太少（高于三百万的数据）
2.经常增删改的表
（因为在更新表的时候， Mysql 不仅要保存数据，还要保存索引文件每次更新添加了的索引列的字段，然后都会调整因为更新所带来的键值变化后的索引信息。）
3.数据重复且发布平均的表字段
（如国籍大家都是中国人性别男或者女）

**MySql 性能分析 **

1.Mysql Query Optimizer （Mysql 在服务层自带的优化器）
在这里插入图片描述

Mysql 常见瓶颈
CPU CPU饱和的时候一般发生在数据装入内存或从磁盘读取数据的时候
IO 磁盘 I/O 瓶颈发生在装入数据远大于内存容量的时候
服务器硬件的性能瓶颈 — top free iostat vmstat 查看系统的性能状态
Explain

** Explain **（重点可以的话背下来吧）
含义：
使用EXPLIAIN 关键字可以模拟优化器执行 SQL 查询语句，从而知道Mysql 是如何处理你的SQL 语句。
分析你的查询语句或是表结构的性能瓶颈

基本用法：
explain + sql 语句

作用：
1.表的读取顺序（可以通过 id 看优先级执行）
2.数据读取操作的操作类型（可以通过 select_type 查看操作类型）
3.哪些索引可以使用（可以通过 possible_keys 查看哪些索引可以被使用）
4.哪些索引被实际使用（可以通过 keys 查看实际中索引被使用）
5.表之间的引用（可以通过 ref 查看表之间的引用如 test.t2.id）
6.每张表有多少行被优化器查询 (可以通过 rows 查询表多少行被优化器查询）

explain 的表头 （也称为指标）

id select_type table type possible_keys key key_len ref rows Extra

在这里插入图片描述

** explain 之 id 介绍

select 查询的序列号，包含一组数字，表示查询中执行 select 子句或操作表的顺序。

三种情况：
id 相同，执行顺序由上往下（图一）
id 不同，如果是子查询， id的序号会递增， id值越大优先级越高，越先执行（图二）
id 相同不同，同时存在。（图三）
id如果相同，可以认为是一组，执行顺序由上往下
在所有组中， id值越大，优先级越高，越先执行
在这里插入图片描述

--------------------------------------（图一）-------------------------------------------------------

在这里插入图片描述 --------------------------------------（图二）-------------------------------------------------------

--------------------------------------（图三）-------------------------------------------------------

** explain 之 select_type 介绍
simple primary subquery derived（临时表衍生） union union result
有哪些：在这里插入图片描述
作用：
查询的类型主要用于区别
普通查询联合查询子查询等复杂查询

各种操作类型含义：
simple ：简单的select查询查询中不包含子查询或 union

primary ：查询中若包含复杂的子部分最外层查询被标记（如图二中的 id）

subquery ：在 select 或 where 中包含子查询

derived（临时表衍生）：
在 from 列表中包含的子查询被标记为 derive（衍生）
mysql 会递归执行这些子查询把结果放在临时表中（如图二中的 derived2）

union ：如果第二个 select 出现在 union 后，被标记 union
如果 union 包含 from 子句的子查询中，外层 select 标记为 derived

union result ：从 union 表获取结果的 select

** explain 之 table介绍
含义：
显示这一行的数据是关于哪个表

** explain 之 type 介绍
类型 all index range ref eq_ref const,system null

显示查询使用了何种类型

从最好依次到最差
system>const>eq_ref>ref>range>index>All
一般来说，得保证查询至少达到 range 级别，最好到达 ref

system ：表只有一行数据（等于系统表）这是 const 类型的特例，可以忽略

const ：表示通过索引一次就能找到， const 用于比较 primary key 或者
unique （唯一）索引。
因为只匹配一行数据很快。
（如将主键置于 where 中， mysql就能将查询转换成一个常量）

eq_ref ：唯一性索引扫描对于每个索引键表中只有一个记录与之匹配
常见：主键或者唯一索引扫描

ref ：非唯一性索引扫描返回匹配某个单独值的所有行
本质上是一种索引访问返回所有匹配某个单独值的行
然而可能会找到多个符合条件的行，所以属于查找和扫描的混合体

range ：只检索给定范围的行使用一个索引来选择行
key列显示使用哪个索引
一般在 where 出现 between > < in 等查询
范围查询比全表查询好因为它只需要开始于索引的一点，而结束语一点，不用扫描全部索引

index ： index 与 all 的区别在于只遍历索引树，通常比 all 快。
因为索引文件通常比数据文件小（index是从索引读取， all从硬盘读取）

All ：将遍历全表以找到匹配的行。

** explain 之 possible_keys key key_len介绍

possible_keys ：显示可能应用在这表中的索引一个或者多个
查询涉及到的字段上若存在索引，则该索引被列出，但不一定被查询实际使用

key : 实际使用的索引。如果为null ，则没有使用索引
查询中若使用了覆盖索引，则该索引仅出现在key列表中。

key_len: 表示索引中使用的字节数，可通过该列计算查询中使用的索引长度。
在不损失精度的情况下，长度越短越好。
key_len显示的值为索引字段的最大可能长度，并非实际长度
即key_len根据表定义计算而得，不是通过表内检索出。

** explain 之 ref 介绍
：显示索引的哪一列被使用了，可能是常数。
哪些列或常量被用于查找索引列上的值。

** explain 之 rows介绍
:
根据表统计信息以及索引选取情况，大致估算出找到所需记录需要读取的行数

** explain 之 Extra 介绍
group by 和 order by 顺序最好与索引顺序一致
：包含不适合在其他列中显示但十分重要的额外信息

Using filesort ：说明 mysql 会对数据使用一个外部的索引排序，
而不是按照表内索引顺序进行读取。
mysql中无法利用索引完成排序的操作称为 文件排序
（需要优化）

2.Using temporary ：使用了临时表保存中间结果， mysql 在对查询结果排序的时候使用了临时表。
常见于（group by 和 order by ）
（立马优化）

Using index （好事）：
1. 表示相应的 select 操作中使用了覆盖索引，避免了表的数据行，效率好
2. 如果同时出现 using where ，表明索引被用来执行索引键值的查找
3. 如果没有同时出现 using where，表明索引被用来读取数据而不是执行查找动作

覆盖索引（索引覆盖）
select 的数据列只用从索引中获取，不必读取数据行，
mysql 可以利用索引返回 select 列表中的字段，而不必根据索引再次读取数据文件，换句话说 查询列要被所建立的索引覆盖
如索引（1，2, 3）查询的列为（1，2, 3）
在这里插入图片描述

Using where ：表明使用 where 过滤
using join buffer:使用了连接缓存

6.impossible where : where 子句值为false，不能用来获取任何元组
（如名字不可能两个吧 name =‘1’ and name =‘2’）

select tables optimized away：
distinct

** 索引优化 ** (重点面试让你写一个索引）

**单表：
在这里插入图片描述

EXPLAIN
select id , author_id from article
where caregory_id= '1'
and comments > 1
ORDER  BY views DESC
LIMIT 0,1;

show index FROM article;
DROP INDEX article_caregory_id_comments_views ON article;

在这里插入图片描述
范围以后索引会失效

···
第一种索引
create index article_caregory_id_comments_views on article(caregory_id,comments,views);

alter table article add index article_caregory_id_comments_views (caregory_id,comments,views);

EXPLAIN select id , author_id from article where caregory_id= ‘1’
and comments > 1 ORDER BY views DESC LIMIT 0,1;

在这里插入图片描述

结论：
1. type 变成了 range 但是 extra 出现了 using filesort
2. 因为根据 Btree树原理
3. 先排序 caregory_id 在排序 comments ，遇到相同的 comments 在排序 views
4. 当comments 字段在联合索引里处于中间位置
5. 因为 comments >1 是范围值
Mysql 无法利用索引在对 views 部分进行检索，即 range 类型查询字段后面索引失效

第二种索引
create index article_caregory_id_comments_views on article(caregory_id,views);

alter table article add index article_caregory_id_comments_views (caregory_id,views);

结论：去掉了 comments 这个范围值， type 变成了 ref ， extra 的 using filesort 也消失了

**两表：
分析以下 sql语句

	EXPLAIN SELECT
	* 
FROM
	class
	LEFT JOIN book ON class.card = book.card;

在这里插入图片描述
左表： class 右表：book

create index Y on book(card);  建立右表索引
drop INDEX Y on book;

在这里插入图片描述
alter table class add index Z (card); 建立左表索引

DROP index Z on class;

在这里插入图片描述
结论：
1.这是由左连接特性决定的， left join 用于确定如何从右表搜索行，左边一定有
2.所以右边是我们的关键点，一定要建立索引

3.right join 用于确定如何从左表搜索行，左表一定需要建立索引

EXPLAIN SELECT
	* 
FROM
	class
	RIGHT JOIN book ON class.card = book.card;	

	alter table class add index Z (card);  建立左表索引
	
	DROP index Z on class;

结论：左连接建立右表索引，右连接建立左表索引

** 三表

explain SELECT	*  FROM 	class c
	LEFT JOIN book b ON c.card = b.card
	LEFT JOIN phone p ON b.card = p.card

在这里插入图片描述
结论：
1.全是all 优化
2. 根据左连接建立右表 book索引建立右表 phone索引

create index Y on book(card);
	
alter table phone add index Z(card);

在这里插入图片描述
结论：后两行的 type 都是 ref ，row 优化很好。
因为索引最好设置在经常需要查询的字段中。

大结论：
join的优化
1.尽可能减少 join 语句中的 NestedLoop（嵌套循环）的循环总次数：
“永远小结果驱动大结果” （小表驱动大表） (书籍类驱动书）
2.优先优化 NestedLoop 的内层循环
3.当无法保证被驱动表的 join 条件字段被索引且内存资源充沛下，
不要吝啬 joinbutter 设置

** 索引失效（应该避免）**

** 索引失效

全值匹配我最爱
索引（1，2, 3）查询顺序（1，2, 3）
··· EXPLAIN SELECT *
FROM staffs WHERE NAME = ‘李四’ AND age = ‘22’ AND pos = ‘经理’···

最左前缀原则（重中之重）
如果索引使用了多列要遵循最左前缀法则指的是查询从索引的最左前列开始并且不跳过索引中的列
索引的最左前列带头大哥
索引中的列：中间兄弟

EXPLAIN SELECT	* FROM	staffs WHERE	
NAME = '李四' 	AND age = '22' 	AND pos = '经理' 
(带头大哥，中间兄弟都在 ，索引生效 且配合 全值匹配)

EXPLAIN SELECT	* FROM	staffs WHERE	
NAME = '李四' 	 	AND pos = '经理'
(带头大哥在，中间兄弟不在 ，索引生效  但只会部分查询 索引NAME )
	
EXPLAIN SELECT	* FROM	staffs WHERE	
NAME = '李四' 	AND age = '22' 	
(带头大哥，中间兄弟在 ，最后兄弟没了，索引生效  不会部分查询 )

EXPLAIN SELECT	* FROM	staffs WHERE	
 age = '22' 		AND pos = '经理'
(带头大哥不在，中间兄弟在 ，最后兄弟在，索引失效 全表查询 all  )

不在索引列上做任何操作（计算函数（自动or手动）类型转换），
会导致索引失效而转向全表查询
```
EXPLAIN SELECT	* FROM	staffs 
WHERE	left(pos,2) = '经理' (索引失效，使用了 ）	
```

存储引擎不能使用索引中范围条件右边的列

范围之后全失效

EXPLAIN SELECT	* FROM	staffs WHERE	
NAME = '李四' 	AND age > '22' AND pos='经理'

在这里插入图片描述

尽量使用 覆盖索引 （只访问索引的查询（索引列和查询列一致）），减少使用 select *
(或者是查询列的一部分和索引列的一部分吻合)

	EXPLAIN SELECT NAME	,	age,	pos FROM	staffs 
	WHERE		
	NAME = '李四' 		AND age = '22' 		AND pos = '经理'
	
	(或者是查询列 的 一部分 和 索引列的一部分吻合)
	EXPLAIN SELECT NAME	 FROM	staffs 
	WHERE		
	NAME = '李四' 		AND age = '22' 		AND pos = '经理'

	EXPLAIN SELECT age,	pos FROM	staffs 
	WHERE		
	NAME = '李四' 		AND age = '22' 		AND pos = '经理'

mysql 在使用（！= <>）的时候无法使用索引会导致全表查询
is null ， is not null 无法使用索引
like 以通配符开头（' %abc.. '） mysql 索引失效会变成全表查询
(重点）
解决 like% 字符串% 时索引不被引用的方法？
建立覆盖索引，最好建的索引个数顺序最好吻合
注意主键自带索引
字符串不加单引号索引失效
varchar类型必须加单引号
少用 or ，用它连接会索引失效

总结

				【优化总结口诀】
			全值匹配我最爱，最左前缀要遵守；
			头大哥不能死，中间兄弟不能断；
			索引列上少计算，范围之后全失效；
			Like百分写最右，覆盖索引不写星；
			不等空值还有or，索引失效要少用；
			VAR引号不可丢，SQL高级也不难！

索引面试题

	定值（常量） 范围  还是 排序 ，  一般 order by 给范围
	group by 基本上 都需要 进行排序 ，会有临时表产生。

query （查询）
一般性建议：
单值索引，尽量选择针对当前 query 过滤性更好的索引
组合索引，当前 query 中过滤性最好的字段在索引字段顺序中，位置越靠左越好
组合索引，尽量选择可以能够包含当前 query中的 where字句中更多字段的索引
尽可能分析统计信息和调整 query 的写法来达到合适索引

**3. 查询截取分析 **
1.查询优化
2. 慢查询的开启并捕获
3. explain+慢SQL分析
4. 4.show profile 查询 sql 在mysql服务器里面的执行细节和生命周期情况
5.sql 数据库服务器的参数调优

** 查询优化
永远小表驱动大表
类似于嵌套循环 Nested Loop
在这里插入图片描述
基本语法：

select  ... from table where exists （subquery 子查询）
将主查询 的 数据  ，放到 子查询验证 ，
根据 验证结果 （true 或者 false） 来决定查询的数据是否保留

在这里插入图片描述
示例：

SELECT	* FROM	t_dept t 
WHERE	t.id IN ( SELECT id FROM t_emp p );

等价于	
SELECT	* FROM	t_dept t 
WHERE	EXISTS ( SELECT * FROM t_emp p WHERE t.id = p.id );

（子查询的 select ‘X’ 也无所谓 因为已经忽视了查询结果，
 而是 T表 数据是否存在于 P表）

** order by 关键字优化

一.order by 子句尽量使用 index 方式排序，避免使用 Filesort 方式排序

mysql 支持两种排序 – filesort 和 index
指的是 mysql 扫描索引本身完成排序。filesort本身效率低

二. 尽可能在索引列上完成排序，按照索引建的最左前缀原则
order by 两种情况出现 index排序
1.order by 语句满足索引最左前缀原则
2. where 子句和 order by 子句满足索引最左前缀原则

三. 如果不在索引列上，filesort 两种算法：
mysql 启动双路排序和单路排序
buffer（缓冲区）

**双路排序：
Mysql 4.1 之前使用的是双路排序，经过两次磁盘扫描，最终得到数据。
读取行指针和 order by 列，进行排序，然后扫描已经排序好的列表，
按照列表中的值查询从列表中读取对应数据输出

总结：从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。
缺点:
取一批数据，要对磁盘进行两次扫描， I/O 很耗时，
所以在 4.1之后出现单路算法

**单路排序：
从磁盘读取查询需要的所有列，按照 order by 排序在 buffer 进行排序，
然后扫描排序后的列表进行输出，效率快，避免了二次读取数据。
并且把随机 I/O 变成了顺序 I/O ，但会使用更多内存空间，
因为每一行都存储在内存中。

单路排序出现的问题：在这里插入图片描述

四. 优化策略
1. 增大 sort_buffer_size 参数设置
2. 增大 sort_length_for_data参数设置
3. 原因：
在这里插入图片描述
总结：为排序使用索引
Mysql 两种排序：
文件排序（Using firesort ） | | 扫描有序索引排序（Using index）
Mysql 能为排序和查询使用相同的索引

**group by 关键字优化

group by 实际上是先排序后分组，遵循最左前缀原则
当索引列无法使用的时候，
增大 sort_buffer_size 参数设置，增大 sort_length_for_data参数设置
where 高于 having ，能写在 where 限定条件就不使用 having

** 慢查询日志
在这里插入图片描述
总结 :
Mysql 慢查询日志是 mysql 提供的一种日志记录，
用来记录在 mysql 中响应时间超过阙值的语句，
具体指的是运行时间超过 long_query_time 值的sql，会被记录到慢查询日志中

long_query_time（阙值）默认值为 10 ，即运行时间超过10秒也是的sql语句

结合 sql 超过我们的最大忍耐时间值，可以结合 explain 进行全面分析

流程：

1.查询慢查询日志状态：show VARIABLES like ‘%slow%’;
在这里插入图片描述

使用 set global slow_query_log=1
开启慢查询日志但只对当前数据库生效
mysql 重启后失效

长期开启：
在这里插入图片描述

如何知道 sql 被记录到了慢查询日志中？

查看超过多少秒算是慢查询 : show VARIABLES like ‘long_query_time’;
设置慢的阙值时间： set global long_query_time =3;
（设置为3秒，原本为 10秒）
2.1 重新设置后，需要重新连接 mysql 或者开一个新会话查看
show VARIABLES like ‘long_query_time’;
2.2 新命令查看阙值时间
show global VARIABLES like ‘long_query_time’;

在这里插入图片描述

如何记录慢 sql 并后续分析
3.1 select sleep(4);

3.2 进入文件位置： cd /usr/local/mysql/data/

3.3 查看
vim MiWiFi-R4CM-srv-slow.log
或者
cat MiWiFi-R4CM-srv-slow.log
查询 当前 系统中有多少条慢查询记录
show global status like ‘%Slow_queries%’;

** mysql 提供了日志分析工具 mysqldumpslow
命令 mysqldumpslow --help
在这里插入图片描述
工作例子

** show Proflie 优化
含义：
mysql 提供可以用来分析当前会话中语句执行的资源消耗情况，
可以用于 sql 的调优的测量

默认情况下：
参数处于关闭状态，只保存最近15次运行结果

分析步骤：
1.查看是否支持
show variables like ’ profiling ';
在这里插入图片描述

2.开启
set profiling = ‘ON’;
show variables like ‘profiling’;
在这里插入图片描述

show profiles;
在这里插入图片描述

常用诊断SQL

show profile cpu,block,io for query ‘id’

如 show profile cpu ,block io FOR QUERY 618;
在这里插入图片描述

show profile all FOR QUERY 675;
在这里插入图片描述
日常开发注意结论：

在这里插入图片描述

全局查询日志
（测试环境下）

配置文件

在这里插入图片描述

2.命令行在这里插入图片描述

**4. MySql 锁机制（重中之重） **

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

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

2.从对数据库操作的粒度分：表锁行锁

** 三锁
手动增加锁：基本语法
lock table 表名 read（write），表名2 read（write），其他；
查看表上加过的锁 : show open tables;
释放锁： unlock tables；

表锁（偏读）
特点:
偏向MyISAM 存储引擎，开销小，加锁快；无死锁，锁定粒度大；
发生锁冲突概率最大，并发度低

总结：
在 MyISAM 引擎下的情况：
读锁： lock table mylock read； unlock tables； show open tables；
会话1 如果对某表进行了读锁操作， 只能查询该表的数据，不能进行其他操作，如增删改；也不能查询其他未锁定表的数据。（增删改也不可以，查都不行，改个毛）
会话2 可以对该表进行查询操作，也可以查询或更新其他未锁定的表；但如果对加了读锁操作的表进行更新插入删除操作，将会处于堵塞等待状态，
必须等待会话1 进行了解锁操作才能对该表进行更新操作。

写锁 lock table mylock write； unlock tables； show open tables；
会话1 如果对某表进行了写锁操作，可以对该表进行增删改操作；但不能对其他表进行查询操作。

会话2 如果对该表进行查询操作，将会处于堵塞等待状态,
必须等待会话1 进行解锁操作；
但可以对其他表进行增删改查操作。

MyISAM 大总结
MyISAM （表锁）
在执行查询语句（select）前，会自动给涉及的所有表加 读锁；
在执行增删改操作前，会自动给涉及的所有表加 写锁。

MySql 的表级锁有两种模式：
····表共享读锁 ···· 表独占写锁
在这里插入图片描述
对 MyISAM 引擎下的表：