MySQL 知识

Hash索引 与 b+树索引区别？

Hash索引结构的特殊性，检索效率非常高，能一次定位。
B+树索引，需要从根节点到枝节点，再到叶节点，这样多次io访问。

为什么不用hash索引，而要使用 B+树索引

1、Hash索引不能满足范围查询，无法避免排序操作，因为hash值的大小与运算前的大小不一定能完全一致。
2、对于组合索引，hash索引在计算索引值的时候是合并 组合索引再一起计算hash值，而不是单独计算hash值，所以通过一个或几个索引键查询的时候，hash索引无法被利用。
3、Hash索引遇到大量hash值相等的情况下性能不一定比 B+树高，存储hash冲突
4、如果是等值查询，那么哈希索引绝对有优势，因为只需要经过一次算法就能 找到相应的键值，这个前提是，键值都是唯一的，如果键值不唯一，就需要先找到键所在的位置，然后再根据链表往后扫描，直到找到相应的数据。

B+树索引

常用的innodb引擎默认使用B+树索引，它会实时监控索引的使用情况，如果认为建立hash索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在innodb中默认开启自适应哈希索引），通过观察 查询模式，mysql会利用index key前缀建立哈希索引，如果一个表大部分在缓冲区中，那么建立哈希索引能够加快等值查询。

innodb 引擎的普通索引和主键索引有什么区别？

区别：
索引是一种数据结构，是存储了表数据的物理地址
聚集索引既存储了表数据key又存储了行值，物理地址的逻辑顺序和表存储的顺序一致！是唯一的
非聚簇索引：存放了表数据的物理地址和key值，可根据key值对应的物理地址再查询具体的行值，但是物理地址存放的顺序和表存放的逻辑顺序没有强一致性！

根本区别：表记录的排列顺序和索引的排列顺序是否一致

普通索引：这是最基本的索引类型，而且它没有唯一性之类的限制。
主键索引：就是唯一 且不能为空
主键索引也被称为聚簇索引,叶子节点存放的是整行数据; 而非主键索引被称为二级索引,叶子节点存放的是主键的值.
如果根据主键查询, 只需要搜索ID这颗B+树
而如果通过非主键索引查询, 需要先搜索k索引树, 找到对应的主键, 然后再到ID索引树搜索一次, 这个过程叫做回表.
总结, 非主键索引的查询需要多扫描一颗索引树, 效率相对更低.

MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句

1，slow_query_log
这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。
2，long_query_time
当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
3，slow_query_log_file
记录日志的文件名。

explain 语句

type
对表访问方式，表示MySQL在表中找到所需行的方式，又称“访问类型”。
常用的类型有： ALL、index、range、 ref、eq_ref、const、system、NULL（从左到右，性能从差到好）

ALL：Full Table Scan， MySQL将遍历全表以找到匹配的行
index: Full Index Scan，index与ALL区别为index类型只遍历索引树
range:只检索给定范围的行，使用一个索引来选择行
ref: 表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
eq_ref: 类似ref，区别就在使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配，简单来说，就是多表连接中使用primary key或者 unique key作为关联条件
const、system: 当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量，system是const类型的特例，当查询的表只有一行的情况下，使用system
NULL: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。

Extra
该列包含MySQL解决查询的详细信息,有以下几种情况：
1、Using filesort：说明mysql会对数据适用一个外部的索引排序。而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成排序操作称为“文件排序”
2、Using temporary:使用了临时表保存中间结果，mysql在查询结果排序时使用临时表。常见于排序order by和分组查询group by。
3、Using index:表示相应的select操作用使用覆盖索引，避免访问了表的数据行。如果同时出现using where，表名索引被用来执行索引键值的查找；如果没有同时出现using where，表名索引用来读取数据而非执行查询动作。
4、Using where :表明使用where过滤
5、using join buffer:使用了连接缓存
6、impossible where:where子句的值总是false，不能用来获取任何元组
7、select tables optimized away：在没有group by子句的情况下，基于索引优化Min、max操作或者对于MyISAM存储引擎优化count（*），不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。
8、distinct：优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。

Key
显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。查询中如果使用覆盖索引，则该索引和查询的select字段重叠。

possible_keys
指出MySQL能使用哪个索引在该表中找到行

事务特性

原子性、一致性、隔离性、持久性

原子性（atomicity）

一个事务必须被视为一个不可分割的最小单元，整个事务中的所有操作要么全部提交成功，要么全部失败，对于一个事务来说，不可能只执行其中的一部分操作

一致性（consistency）

一致性是指事务将数据库从一种一致性转换到另外一种一致性状态，在事务开始之前和事务结束之后数据库中数据的完整性没有被破坏

持久性（durability）

一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，已经提交的修改数据也不会丢失

隔离性（isolation）

一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

四种隔离级别

Read Uncommitted（读取未提交内容）

   在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）

   这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重读）

   这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化）

   这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

     这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。（事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据）

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。（事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。）

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。（系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。）

在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

Sql语句优化原则：

原则1：避免在列上进行运算 select * from t where YEAR（d） >= ‘2020’ 优化为 ： select * from t where d >= ‘2020’
原则2：使用join时，应该用小结果集驱动大结果集
原则3：使用 like 模糊查询时避免 %%
原则4：避免select *
原则5：使用批量插入语句节省交互 insert into t (id,name) values(1,’a’),(2,’b’),(3,’c’)
原则6：limit基数比较大的时候使用between（有缺陷，id断行时，读取的数量会小于预计数量）在取比较后面的数据时，通过desc方式把数据方向查找，可以减少对前段数据的扫描，让limit的基数越小越好
原则7：不要使用rand函数获取多条随机数据
原则8：避免使用null
原则9：使用count（*） 而不是count（id）
原则10：不要做无谓的排序操作，而应尽可能在索引中完成排序
Text类型 查询会使用临时表，导致严重的性能开销，分开查

利用表的覆盖索引来加速分页查询

我们都知道，利用了索引查询的语句中如果只包含了那个索引列（覆盖索引），那么这种情况会查询很快。
因为利用索引查找有优化算法，且数据就在查询索引上面，不用再去找相关的数据地址了，这样节省了很多时间。
另外Mysql中也有相关的索引缓存，在并发高的时候利用缓存就效果更好了。
在我们的例子中，我们知道id字段是主键，自然就包含了默认的主键索引。现在让我们看看利用覆盖索引的查询效果如何：
这次我们之间查询最后一页的数据（利用覆盖索引，只包含id列），如下：
select id from product limit 866613, 20
查询时间为0.2秒，相对于查询了所有列的37.44秒，提升了大概100多倍的速度。
那么如果我们也要查询所有列，有两种方法，
id>=的形式：
SELECT * FROM product
WHERE ID > =(select id from product limit 866613, 1) limit 20

mysql防注入

1、如果是整形变量或字段，使用intval（）函数把所有传入的参数转化为一个数值，比如翻页，按id浏览文章
2、对于字符型变量，用addslashes（）会把所有单引号(‘)，双引号(“)，反斜杠()和空字符转为含有反斜杠的溢出字符，或者使用pdo参数绑定来提高安全性
3、转义或过滤一些特殊字符，如%等
4、保护表结构等关键信息（对于开源程序此条不成立，这仅是无奈之举，例如有人会故意把字段名命名搞得古怪，这是不可取的，最可靠的还是在代码级别上把好关。）
5、任何情况下都要做好数据备份，以防万一。

Mysql各种锁的总结

1.共享锁（又称读锁）、排它锁（又称写锁）：

InnoDB引擎的锁机制：InnoDB支持事务，支持行锁和表锁用的比较多，Myisam不支持事务，只支持表锁。
共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

说明：
1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。
2）对于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。

**对于锁定行记录后需要进行更新操作的应用，应该使用Select…For update 方式，获取排它锁。（用共享锁，在读了之后再写会阻塞，会导致死锁）

这里说说Myisam：MyISAM在执行查询语句(SELECT)前，会自动给涉及的所有表加读锁，在执行更新操作(UPDATE、DELETE、INSERT等)前，会自动给涉及的表加写锁。

3）InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

2.乐观锁、悲观锁：

悲观锁：悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

1）使用悲观锁，我们必须关闭mysql数据库的自动提交属性，采用手动提交事务的方式，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

2）需要注意的是，在事务中，只有SELECT … FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般SELECT … 则不受此影响。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)。

3）补充：MySQL select…for update的Row Lock与Table Lock
使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键（或有索引的地方），MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。

乐观锁：
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做（一般是回滚事务）。那么我们如何实现乐观锁呢，一般来说有以下2种方式：

1）.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

2）.乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

总结：两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
另外，高并发情况下个人认为乐观锁要好于悲观锁，因为悲观锁的机制使得各个线程等待时间过长，极其影响效率，乐观锁可以在一定程度上提高并发度。

3.表锁、行锁

表级锁(table-level locking)：MyISAM和MEMORY存储引擎
行级锁(row-level locking) ：InnoDB存储引擎
页面锁(page-level-locking)：BDB存储引擎
表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般。

数据库的主从复制和读写分离**：**

原理：

MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志（relay log）中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。

主服务器配置

1. 开启二进制日志
2. 配置唯一的server-id
3. 获得master二进制日志文件名及位置 show master status；
4. 创建一个用于slave和master通信的用户账号
实现：
1. 找到数据卷映射的mysqld.cnf文件(例如：/var/lib/docker/volumes/mysql_mysql-conf/_data/mysql.conf.d)
2. 修改配置
3. 连接mysql,创建用户并赋予权限
如（GRANT REPLICATION SLAVE ON . TO ‘wzh‘@’%’ IDENTIFIED BY ‘123456’）

从服务器配置：

1. 配置唯一的server-id
2. 使用master分配的用户账号读取master二进制日志
3. 启用slave服务
实现：
slave库CHANGE MASTER TO MASTER_HOST=’192.168.79.130’,MASTER_USER=’wzh’,MASTER_PASSWORD=’123456’,MASTER_LOG_FILE=’mysql-bin.000003’,MASTER_LOG_POS=1329;
start slave;
show slave status;
两者都为yes即可成功

注意事项**：**

1. docker-compose复制过来修改配置后需要重启 docker-compose restart
2. 复制从库后，需要修改mysql的uuid，find -name auto.cnf找到位置后修改，使主从不一致即可
3. 默认主从复制所有库，可以配置指定读写库
4. 如果主从表结构不同，修改主表后，slave-sql-running会变为No,需要stop slave后，修改表结构，重新建立连接启动。
因此，为了保持同步， 可以给从库添加一个只读权限的用户，从库不写只读，实现读写分离。

Mysql分表

分表是分散数据库压力的好方法。
分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。
当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。

1，分表的分类

1>纵向分表
将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）
分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）
案例：
对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。

这样纵向分表后：
首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。活跃数据，可以使用Innodb ,可以有更好的更新速度。
其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。
其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis
之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。

2>横向分表
字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2 等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。
分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。
案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。

本作品采用《CC 协议》，转载必须注明作者和本文链接