MYSQL

DDL 建表
DML增删改
DQL查询
DCL控制用户权限

存储引擎

MYSQL体系结构
*连接层
*服务层（DML DDL ）
*引擎层（可插拔）（索引在这里，不通的引擎 索引结构不同）
*存储层，

外键：
外键关系（Foreign Key Relationship）：从表的外键与主表的主键或唯一键相对应。
级联更新（Cascade Update）：当主表中的主键或唯一键更新时，从表中对应的外键也会自动更新。
级联删除（Cascade Delete）：当主表中的主键或唯一键删除时，从表中对应的外键也会自动删除或置为NULL。

存储引擎

基于表的（创建表的时候）
Innodb默认--5.5版本后
myISAM早期默认
Memory

Innodb

*特点
*支持DML ， 事务 ，行锁 ，高并发，外键约束，保证数据完整和正确
*磁盘：每个表都有一个表空间文件（表结构 ，数据，索引）

逻辑存储结构：表--段--区（1M）--页(16K)--行

MYISAM（mongodb替代）

*不支持事务，外键，行锁
*支持表锁，
*访问速度快
*磁盘有三个文件（分别存：表结构 ，数据，索引）

Memory（redis替代）

*内存存放
*hash索引（默认）
磁盘一个文件（表结构）


选择引擎  
事务-外键-完整性等  Innodb
插入-读取多，更新和删除少的 MYISAM
临时Memory

索引

*概述：是一种高速获取数据的-有序的数据结构
（二叉树：先比较 --小的往左， 大的往右）
*优点：
高速获取数据，
提高排序效率  降低cpu消耗
缺点：
占用磁盘
影响增删改
 

索引结构

B+tree索引      支持所有引擎
hash索引      支持memory

Btree:中间元素向上分裂     4ket 5指针

B+tree: 
*所有的元素都会出现在叶子节点
*所有叶子都会形成一个单向链表

mysql优化后的B+tree
*增加一个指向相邻叶子节点的链表指针（双向），形成有序的指针提高访问

Hash（等值配匹-不能范围-不能排序）通常一次查询 很快
*将键值换算成hash值 映射到对应的槽位上，然后存在hash表中
*hash冲突（碰撞）通过链表来解决
 

Innodb自适应hash功能，在指定环境下可以自动构建


为什么Innodb选择使用B+tree
*相对二叉树，层级更少，查询效率更高

*对于Btree,无论是叶子还是非叶子节点都存储数据，这样导致一页中存储的键值和指针减少，要保存同样的数据就加树高度，导致性能降低

*相对Hash   不能范围-不能排序


 

索引分类

主键索引，唯一索引，常规索引，全文索引（查找文中的关键字）
 

innodb索引的存储形式
1:聚集索引（必须有 且一个）（主键）
结构：（叶子节点挂的就是row数据）！！！！！！！！！！！！！！！！！！

2:二级索引 (多个)
结构：（叶子节点挂的就是id）！！！！！！！！！！！！！！！！！！

select * from aaa where  name= 666( 先二级查询找到id，再根据id聚集查询找到数据)
（回表查询）

聚集索引选取规则
*优先主键
*第一个唯一索引
*自动生成一个隐藏的

Innodb主键索引的B+tree高度为多高？？？！！！！！！！！！！！！！
*每个节点(包含key,指针（6字节）)落在磁盘的页（16K）当中
*假设：
一行数据大小为1k ,一页可以存16行，指针占用6byte,  bigint主键（key值）占用8byte
高度为2
第一层 n*8 +(n+1)*6 =16*1024  计算n=1170   n就是ket的数量
第二层 1171*16 = 18730   一万八
如果是三层 1171*1171*16 = 2千1百万

 

SQL分析

*查询SQL执行各种操作的频率 show global status like  'Com____'
*查询慢sql日志 （默认关闭的） 打开并 设置时间
*查看sql执行各个阶段耗时   profile ，（先查看是否支持）
*执行计划explain

explain
*id 越大越优先执行，相同就从上到下执行
*type 连接类型：null ,system ,const(主键查询),ref（一般查询） ,all
* possible_key 可能用到的索引
 *key 实际用到的索引
*key_len索引长度 越短越好
*rows查询行数
*filterd 结果和读取比例  越大100%越好   
*extra 额外信息
 

索引使用

避免回表- 避 避免回表免回表 避免回表 避免回表  避免回表  避免回表  避免回表

失效的情况

*最左前缀法则 ：联合索引 最左的字段一定要存在 不然就失效，跳过的也失效
*范围查询失效：联合索引 >< 范围查询失效    ， 用>= <= 解决
*不要再索引列进行sub等运算 会失效（在hwhere 里面）
*字符串不加引号 索引失效
*模块查询头不配匹就会失效
*使用or 两边都要有索引 才会生效
*MYSQL评估 走全文比索引快  就不会走索引

SQL提示（选择走哪个索引）

背景：同一个联合索引和一般索引(自动选择 不固定)，可能会先走联合索引
*use index    建议使用这个索引
*ignore index  不走
*force index   必须走
例子：     select * from  table use index(id)   where id = 11

覆盖索引

（返回的数据 尽量包含索引 ，少用select* 很容易回表）
*查询返回减少无用字段 多余的字段会导致回表查询（索引信息没有包含全部数据）
ps-尽量在索引就能回去所有数据
 

前缀索引 

*对大字段部分长度做索引 减少索引体积空间
*选择长度越长越好  最好唯一

单列索引（多个，只会有快的那一个）
联合索引（存在多个查询条件 建议使用）  考虑建立索引的顺序
 

设计原则

*数据量大
*查询频繁
*针对 在 where ,order by, group by 的字段
*选择区分度高的 例如id 唯一的
*如果是大字符串的  建议前缀索引
*尽量联合索引 减少空间，减少回表，尽量覆盖索引