mysql

mysql的引擎

image.png

MyIsam(5.1默认)

支持表锁，底层结构为B+树

INNDB

支持表锁和行锁，底层结构为B+树

Mysql5.1之前默认的是myIsam，之后是innoDb；
MyISAM是非集聚引擎，支持全文索引;不支持事务;它是表级锁;会保存表的具体行数.
innoDB是集聚引擎，5.6以后才有全文索引;支持事务；它是行级锁;不会保存表的具体行数.
一般：不用事务的时候,count计算多的时候适合myisam引擎。对可靠性要求高就是用innodb引擎。

B树：

一个m阶的B树具有如下几个特征：
1.根结点至少有两个子女。
2.每个中间节点都包含k-1个元素和k个孩子，其中 m/2 <= k <= m
3.每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m
4.所有的叶子结点都位于同一层。
5.每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域分划。

image.png

B+树

B+树的特征：
1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。（链表）
3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
4、B+树查找时是从上到下查找；B-树则是从下往上查找（中序遍历）
B+树的优势：
1.单一节点存储更多的元素（这样该节点下分支变多了，树变矮胖了），使得查询的IO次数更少。
2.所有查询都要查找到叶子节点，查询性能稳定。
3.所有叶子节点形成有序链表，便于范围查询。

image.png

B+ 树一般能储存多少数据？

这里我们先假设 B+ 树高为 2，即存在一个根节点和若干个叶子节点，假设一行记录的数据大小为 1 KB，那么单个叶子节点（页）中的记录数等于 16 KB / 1 KB = 16 条数据。然后要计算出非叶子节点能存放多少指针，我们假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节，我们一个页中能存放多少这样的单元，其实就代表有多少指针，即 16 KB / 14 B = 1170。那么可以算出一棵高度为 2 的 B+ 树，大概就能存放下 1170 * 16 = 18720 条数据。根据同样的原理我们可以算出一个高度为 3 的 B+ 树就可以存放下 21902400 条数据。所以在 InnoDB 中 B+ 树高度一般为 1 - 3 层，它就能满足千万级的数据存储。在查找数据时一次页的查找代表一次 IO，所以通过主键索引查询通常只需要 1 - 3 次逻辑 IO 操作即可查找到数据

索引

索引分类：
主键索引：
唯一索引：
普通的索引：
主键联合索引：
唯一联合索引：
普通联合索引：
全文索引：
哈希索引：根据hashCode 生成的索引，不支持最左查询，只能完全匹配情况下查询效率高
聚簇索引和非聚簇索引
聚簇索引：一般为主键索引，所有的数据都放在叶子节点
非聚簇索引：叶子节点上存放的是主键节点的数据，需要查询的时候需要再次通过主键索引获取数据，二次查询

联合索引需要关注最左原则

MySql语句注意问题：

对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
1、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0
2、应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。
3、应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10 union all select id from t where num=20
4、下面的查询也将导致全表扫描：select id from t where name like ‘%李%’若要提高效率，可以考虑全文检索。
5、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num
6、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where num/2=100应改为:select id from t where num=1002
7、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where substring(name,1,3)=’abc’ ，name以abc开头的id应改为:
select id from t where name like ‘abc%’
8、使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
9、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10、很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b) 用下面的语句替换： select num from a where exists(select 1 from b where num=a.num)
11、并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
12、索引并不是越多越好，索引固然可 以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要
13、任何地方都不使用 select * from t ，用具体的字段列表代替“”，不要返回用不到的列

Explain语句分析：

Id,select_type,table,type,possible_key,key,key_len,ref,row,ext

select_type类型说明

【simple表示简单的select查询,查询语句不包含子查询或union】
【primary表示查询中包含复杂子部分，最外层查询标记为primary】
【subquery表示在select或where列表包含子查询】
【derived表示在from列表包含子查询被标记为衍生derived，mysql会递归这些子查询，把结果放到临时表里】
【出现第二个select出现在union之后，则被标记为union。若union包含在from子句的子查询中，外层select被标记为derived】
【union result从union表获取结果的select】

EXPLAIN字段解析：

1、table：显示这一行的数据是关于哪张表的
2、type：这是最重要的字段之一，显示查询使用了何种类型。
从最好到最差的连接类型为system、const、eq_reg、ref、range、index和ALL，一般来说，得保证查询至少达到range级别，最好能达到ref。

type中包含的值：
system、const： 可以将查询的变量转为常量. 如id=1; id为 主键或唯一键.
eq_ref： 访问索引,返回某单一行的数据.(通常在联接时出现，查询使用的索引为主键或惟一键)
ref： 访问索引,返回某个值的数据.(可以返回多行) 通常使用=时发生
range： 这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西，并且该字段上建有索引时发生的情况(注:不一定好于index)
index： 以索引的顺序进行全表扫描，优点是不用排序,缺点是还要全表扫描
ALL： 全表扫描，应该尽量避免

3、possible_keys：显示可能应用在这张表中的索引。如果为空，表示没有可能应用的索引。
4、key：实际使用的索引。如果为NULL，则没有使用索引。
MySQL很少会选择优化不足的索引，此时可以在SELECT语句中使用FORCE INDEX（index_name）来强制使用一个索引或者用IGNORE INDEX（index_name）来强制忽略索引。
MySQL强制使用和不使用索引：https://www.cnblogs.com/lcngu/p/6023179.html
5、key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
6、ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
7、rows：MySQL认为必须检索的用来返回请求数据的行数
8、Extra：关于MySQL如何解析查询的额外信息，主要有以下几种

Extra中包含的值：
using index： 只用到索引,可以避免访问表，性能很高。
using where： 使用到where来过滤数据， 不是所有的where clause都要显示using where. 如以=方式访问索引。
using tmporary： 用到临时表去处理当前的查询。
using filesort： 用到额外的排序，此时mysql会根据联接类型浏览所有符合条件的记录，并保存排序关键字和行指针，然后排序关键字并按顺序检索行。(当使用order by v1,而没用到索引时,就会使用额外的排序)。
range checked for eache record(index map:N)： 没有好的索引可以使用。
Using index for group-by：表明可以在索引中找到分组所需的所有数据，不需要查询实际的表。explain select user_id from t_order group by user_id;

见到Using temporary和Using filesort，就意味着MySQL根本不能使用索引，结果是检索会很慢，需要优化sql了。

MySql的语句执行流程

https://www.cnblogs.com/liran123/p/14324184.html

image.png

image.png

索引下推

image.png

image.png

image.png

image.png

image.png

https://zhuanlan.zhihu.com/p/121084592

创建索引的原则

image.png

image.png

image.png

查询字段的注意

image.png

事务

读未提交 会产生脏读，幻读，不可重复度
读已提交 会产生幻读，不可重复
可重复读 会产生幻读
序列化 性能低
幻读：新插入数据，导致二次获取的数据二第一次获取的数据不同
不可重复读：修改原有的数据，导致获取的数据和第一次获取的不同

解决读已提交和可重复读的事务级别：

MVCC：(多版本并发控制)

image.png

https://www.cnblogs.com/jelly12345/p/14889331.html

一致性快照度

每个事务都会有一个自增长的事务ID，如果删除的话，会标记删除的事务ID
获取的数据事务ID小于最小未提交的事务ID或者等于当前事务ID
获取的数据事务ID必须小于删除的事务ID

image.png

image.png

解决幻读

image.png

数据库的分库分表