B+tree mysql 索引底层B+tree
利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：
每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
由于B+Tree内节点去掉了data域，因此可以拥有更大的出度，拥有更好的性能。
B+树扫库、表能力更强
B+树的磁盘读写能力更强
B+树的排序能力更强
B+树的查询效率更加稳定
SHOW GLOBAL STATUS LIKE 'Innodb_page_size' 查看叶子节点的大小 16kb
数据库表存在哪里？
mysql 数据库是存储在磁盘上的，查看命令 show variables like 'datadir';
InnoDB 索引表结构显示
MyISAM 引擎表结构显示
两者引擎区别 ：
构成上的区别：
-
InnoDB支持外键，而MyISAM不支持。
-
InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交
-
InnoDB表必须有主键，而Myisam可以没有
如何选择：
1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；
2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读也有写，请使用InnoDB。
3. 系统奔溃后，MyISAM恢复起来更困难；
4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。
5. MYISAM 支持表所，InnoDB支持行锁 颗粒度比较细 （具体还很多就先写这些了）
接下来说一下并发量大、数据量大的互联网业务规范
1.使用InnoDB，支持事务，并发量大，支持事务，能作用于表锁和行锁,cpu及内存缓存优化资源利用率比较高。
2.必须使用UTF8字符集 万国码，无需转码，无乱码风险，节省空间
3.数据表、数据字段必须加入中文注释
4.单表列数目必须小于30
5.表必须有主键，例如自增主键
6.禁止使用外键，如果有外键完整性约束，需要应用程序控制，外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql的性能，甚至会造成死锁。
7.必须把字段定义为NOT NULL并且提供默认值 无论是表还是索引中每行中的null的列都需要额外的空间来标识
8.必须使用varchar(20)存储手机号
9.单表索引建议控制在5个以内
10.禁止在更新十分频繁、区分度不高的属性上建立索引。更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能
11.建立组合索引，必须把区分度高的字段放在前面
12.禁止使用SELECT *，只获取必要的字段，需要显示说明列属性，读取不需要的列会增加CPU、IO、NET消耗
13.禁止负向查询，以及%开头的模糊查询，负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描，%开头的模糊查询，会导致全表扫描
sql 优化 （官方文档 https://dev.mysql.com/doc/refman/5.7/en/select-optimization.html）
# 状态命令
SHOW FULL PROCESSLIST / SHOW PROCESSLIST
kill id 进行抹杀
sleep 等待客户端发送信息 （查看状态命令大全显示 https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html）
# 缓存
SHOW VARIABLES LIKE '%query_cache%' ； show status like 'Qcache%' 命令可查看缓存情况
query_cache_type
值：0 -– 不启用查询缓存，默认值；
值：1 -– 启用查询缓存，只要符合查询缓存的要求，客户端的查询语句和记录集
都可以缓存起来，供其他客户端使用，加上 SQL_NO_CACHE将不缓存
值：2 -– 启用查询缓存，只要查询语句中添加了参数：SQL_CACHE，且符合查询
缓存的要求，客户端的查询语句和记录集，则可以缓存起来，供其他客户端使用
query_cache_size
允许设置query_cache_size的值最小为40K，默认1M，推荐设置 为：64M/128M；
query_cache_limit
限制查询缓存区最大能缓存的查询记录集，默认设置为1M
#缓存不会出现的情况
1.当查询语句中有一些不确定的数据时，则不会被缓存。如包含函数NOW()，
CURRENT_DATE()等类似的函数，或者用户自定义的函数，存储函数，用户变量等都不会被缓存
2.当查询的结果大于query_cache_limit设置的值时，结果不会被缓存
3.对于InnoDB引擎来说，当一个语句在事务中修改了某个表，那么在这个事务
提交之前，所有与这个表相关的查询都无法被缓存。因此长时间执行事务，
会大大降低缓存命中率
4.查询的表是系统表
5.查询语句不涉及到表
#为什么默认关闭缓存
为什么mysql默认关闭了缓存开启？？
1.在查询之前必须先检查是否命中缓存,浪费计算资源
2.如果这个查询可以被缓存，那么执行完成后，MySQL发现查询缓存中没有这
个查询，则会将结果存入查询缓存，这会带来额外的系统消耗
3.针对表进行写入或更新数据时，将对应表的所有缓存都设置失效。
4.如果查询缓存很大或者碎片很多时，这个操作可能带来很大的系统消耗
#缓存使用的场景 ？
以读为主的业务，数据生成之后就不常改变的业务 比如门户类、新闻类、报表类、论坛类等
explain操作命令 解读 ？
执行计划select_id
1、id相同，执行顺序由上至下
2、id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
3、id相同又不同即两种情况同时存在，id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行
执行计划select_type
4、SIMPLE：简单的select查询，查询中不包含子查询或者union
5、SUBQUERY/MATERIALIZED：SUBQUERY表示在select 或 where列表中包含了子查询 MATERIALIZED表示where 后面in条件的子查询
6、UNION：若第二个select出现在union之后，则被标记为union；
7、UNION RESULT：从union表获取结果的select
执行计划type
访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：
system > const > eq_ref > ref > range > index > ALL
system：表只有一行记录（等于系统表），const类型的特例，基本不会出现，可以忽略不计
const：表示通过索引一次就找到了，const用于比较primary key 或者 unique索引
eq_ref：唯一索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键 或 唯一索引扫描
ref：非唯一性索引扫描，返回匹配某个单独值的所有行，本质是也是一种索引访问
range：只检索给定范围的行，使用一个索引来选择行
index：Full Index Scan，索引全表扫描，把索引从头到尾扫一遍
ALL：Full Table Scan，遍历全表以找到匹配的行
执行计划--possible_keys
possible_keys 可能用到的索引
key 实际使用的索引 如果是null 则没有索引
rows 根据表统计信息或者索引选用情况，大致估算出找到所需的记录所需要读取的行数
filtered
它指返回结果的行占需要读到的行(rows列的值)的百分比
表示返回结果的行数占需读取行数的百分比，filtered的值越大越好
# 执行计划-Extra
1、Using filesort ：
mysql对数据使用一个外部的文件内容进行了排序，而不是按照表内的索引进行排序读取
2、Using temporary：
使用临时表保存中间结果，也就是说mysql在对查询结果排序时使用了临时表，常见于order by 或 group by
3、Using index：
表示相应的select操作中使用了覆盖索引（Covering Index），避免了访问表的数据行，效率高
4、Using where ：
使用了where过滤条件
5、select tables optimized away：
基于索引优化MIN/MAX操作或者MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段在进行计算，查询执行
计划生成的阶段即可完成优化
#如何定位慢的sql？
1、业务驱动
2、测试驱动
3、慢查询日志
配置慢sql 命令
show variables like 'slow_query_log'
set global slow_query_log = on
set global slow_query_log_file = 'D:/develop/mysql-5.7.22-winx64/lib/mysql/hechuan-slow.log'
set global log_queries_not_using_indexes = on
set global long_query_time = 0.1 (秒)
Time ：日志记录的时间
User@Host：执行的用户及主机
Query_time：查询耗费时间 Lock_time 锁表时间 Rows_sent 发送给请求方的记录条数 Rows_examined 语句扫描的记录条数
SET timestamp 语句执行的时间点
select .... 执行的具体语句
#select 优化
1 SELECT WHERE 查询更快，前提判断字段是否添加了索引 （可以使用EXPLAIN语句来确定用于的索引 SELECT）
2 调整MySQL用于缓存的内存区域的大小和属性。通过有效地使用 InnoDB 缓冲池，重复查询的运行速度更快，因为第二次及其后的结果是从内存中检索的。
（SHOW VARIABLES LIKE '%query_cache%';set global query_cache_size = 1024 * 1024 * 32;set global query_cache_type= 1）
#where 优化
ORDER BY或GROUP BY 包含了其他表的列 则产生一个临时表
select id from t where num is null 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描
应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
应尽量避免在 where 子句中使用 or 来连接条件
in 和 not in 也要慎用，否则会导致全表扫描 like
很多时候用 exists 代替 in 是一个好的选择：select num from a where exists(select 1 from b where num=a.num)
mysqlInnoDB锁类型
行锁级别： 有共享锁Shared Locks和排他锁 Exclusive Locks
共享锁：都能访问到，只能读 不可以修改 。
#-- 共享锁加锁
SET AUTOCOMMIT=ON;
BEGIN;
select id,hc_name from hc_car_info WHERE id=1 LOCK IN SHARE MODE;（LOCK IN SHARE MODE 设置了共享锁）
#-- 排它锁（行锁）Exclusive Locks
只有该获取了排他锁的事务是可以对数据行进行读取和修改
delete / update / insert 默认加上X锁
SELECT * FROM table_name WHERE ... FOR UPDATE
innodb 行锁到底锁了什么？
innodb是用于锁定索引，只有通过索引条件进行数据检索InnoDB才使用行级锁。
