目录
1.MYSQL整体逻辑结构
2.InnoDB和MyISAM存储引擎的区别
3.性能下降、SQL慢执行时间长、等待时间长原因分析
4.常见通用的join连接
5.mysql 索引
一、MYSQL整体逻辑结构学习
1.连接层
最上面一层服务，包括本地的socket通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。主要完成一些类似于链接处理、授权认证，以及相关的安全方案。
2.服务层
第二层主要完成大多数的核心服务功能，如Sql接口,并完成缓存的查询，SQL的分析和优化以及部分内置函数的执行。所有跨存储引擎的功能也在这层实现，如过程，函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成优化如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是select操作，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能
3.引擎层
存储引擎层，存储引擎真正的职责是mysql中数据的存储和提取，服务层通过API与存储引擎层进行通信。不同的存储引擎具有的功能不同，这样我们可以根据我们的业务需要进行选择
如INNODB,MYISAM
4.存储层
数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互
PS:查看命令
检查当前mysql支持的存储引擎： show engines
检查当前mysql默认使用的存储引擎：show variables like '%storage_engine%'
二、InnoDB和MyISAM存储引擎的区别：
| 对比项 | MYISAM | INNODB |
|---|---|---|
| 主外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 行表锁 | 表锁，即使操作一条记录也会锁住整个表，不适合高并发操作 | 行锁，操作时只锁住某一条，不对其他行有影响，适合高并发操作 |
| 缓存 | 只缓存索引，不缓存真实数据 | 不仅缓存索引而且缓存真实数据，对内存要求较高，而且内存大小 对性能有决定性的影响 |
| 表空间 | 小 | 大 |
| 关注点 | 性能 | 事务 |
| 默认安装 | Y | Y |
三、性能下降、SQL慢执行时间长、等待时间长原因分析
-
查询语句写的烂
-
索引失效
-
单值
-
复合
-
-
关联查询太多join(设计缺陷或不得已的需求)
-
服务器调优及各个参数设置(缓冲线程数等)
四、常见通用的join连接
1.SQL执行顺序
-
手写
-
机读
-
总结
五、mysql 索引
索引是什么？
-
mysql中的索引，是一种帮助mysql高效查询的数据结构；
-
可以简单理解为“排好序的快速查找数据结构
-
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
下图就是一种可能的索引方式示例：
-
左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址
-
为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。
-
二叉树弊端之一：二叉树很可能会发生两边不平衡的情况。
-
B-TREE: (B:balance) 会自动根据两边的情况自动调节，使两端无限趋近于平衡状态。可以使性能最稳定。(myisam使用的方式)
-
B-TREE弊端：(插入/修改操作多时，B-TREE会不断调整平衡，消耗性能)从侧面说明了索引不是越多越好。
-
B+TREE:Innodb 所使用的索引
-
总结：数据本身之外，数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种数据结构就是索引。
-
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上
-
我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。
B树检索原理
【初始化介绍】
一颗b树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
【查找过程】
如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。
真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。
四、索引适用条件
适合建立索引的情况 ：
-
主键自动建立唯一索引
-
频繁作为查询的条件的字段应该创建索引
-
查询中与其他表关联的字段，外键关系建立索引
-
频繁更新的字段不适合创建索引
-
Where条件里用不到的字段不创建索引
-
单间/组合索引的选择问题，who？（在高并发下倾向创建组合索引）
-
查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
-
查询中统计或者分组字段
不要创建索引的情况
-
表记录太少
-
经常增删改的表
-
数据重复且分布平均的表字段，因此应该只为经常查询和经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
------------恢复内容开始------------
目录
1.MYSQL整体逻辑结构
2.InnoDB和MyISAM存储引擎的区别
3.性能下降、SQL慢执行时间长、等待时间长原因分析
4.常见通用的join连接
5.mysql 索引
一、MYSQL整体逻辑结构学习
1.连接层
最上面一层服务，包括本地的socket通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。主要完成一些类似于链接处理、授权认证，以及相关的安全方案。
2.服务层
第二层主要完成大多数的核心服务功能，如Sql接口,并完成缓存的查询，SQL的分析和优化以及部分内置函数的执行。所有跨存储引擎的功能也在这层实现，如过程，函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成优化如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是select操作，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能
3.引擎层
存储引擎层，存储引擎真正的职责是mysql中数据的存储和提取，服务层通过API与存储引擎层进行通信。不同的存储引擎具有的功能不同，这样我们可以根据我们的业务需要进行选择
如INNODB,MYISAM
4.存储层
数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互
PS:查看命令
检查当前mysql支持的存储引擎： show engines
检查当前mysql默认使用的存储引擎：show variables like '%storage_engine%'
二、InnoDB和MyISAM存储引擎的区别：
| 对比项 | MYISAM | INNODB |
|---|---|---|
| 主外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 行表锁 | 表锁，即使操作一条记录也会锁住整个表，不适合高并发操作 | 行锁，操作时只锁住某一条，不对其他行有影响，适合高并发操作 |
| 缓存 | 只缓存索引，不缓存真实数据 | 不仅缓存索引而且缓存真实数据，对内存要求较高，而且内存大小 对性能有决定性的影响 |
| 表空间 | 小 | 大 |
| 关注点 | 性能 | 事务 |
| 默认安装 | Y | Y |
三、性能下降、SQL慢执行时间长、等待时间长原因分析
-
查询语句写的烂
-
索引失效
-
单值
-
复合
-
-
关联查询太多join(设计缺陷或不得已的需求)
-
服务器调优及各个参数设置(缓冲线程数等)
四、常见通用的join连接
1.SQL执行顺序
-
手写
-
机读
-
总结
五、mysql 索引
索引是什么？
-
mysql中的索引，是一种帮助mysql高效查询的数据结构；
-
可以简单理解为“排好序的快速查找数据结构
-
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
下图就是一种可能的索引方式示例：
-
左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址
-
为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。
-
二叉树弊端之一：二叉树很可能会发生两边不平衡的情况。
-
B-TREE: (B:balance) 会自动根据两边的情况自动调节，使两端无限趋近于平衡状态。可以使性能最稳定。(myisam使用的方式)
-
B-TREE弊端：(插入/修改操作多时，B-TREE会不断调整平衡，消耗性能)从侧面说明了索引不是越多越好。
-
B+TREE:Innodb 所使用的索引
-
总结：数据本身之外，数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种数据结构就是索引。
-
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上
-
我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引。其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。
B树检索原理
【初始化介绍】
一颗b树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
【查找过程】
如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。
真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。
四、索引适用条件
适合建立索引的情况 ：
-
主键自动建立唯一索引
-
频繁作为查询的条件的字段应该创建索引
-
查询中与其他表关联的字段，外键关系建立索引
-
频繁更新的字段不适合创建索引
-
Where条件里用不到的字段不创建索引
-
单间/组合索引的选择问题，who？（在高并发下倾向创建组合索引）
-
查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
-
查询中统计或者分组字段
不要创建索引的情况
-
表记录太少
-
经常增删改的表
-
数据重复且分布平均的表字段，因此应该只为经常查询和经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
------------恢复内容结束------------