Springboot2+Vue+Shiro云管理系统项目实战

 

第一点上文已经解释了，我们来看下第二点和第三点先来看第二点，假设我们不用索引，试想运行如下语句

1	SELECT * FROM user order by age desc;

则 MySQL 的流程是这样的，扫描所有行，把所有行加载到内存后，再按 age 排序生成一张临时表，再把这表排序后将相应行返回给客户端，更糟的，如果这张临时表的大小大于 tmp_table_size 的值（默认为 16 M），内存临时表会转为磁盘临时表，性能会更差，如果加了索引，索引本身是有序的 ，所以从磁盘读的行数本身就是按 age 排序好的，也就不会生成临时表，就不用再额外排序 ，无疑提升了性能。再来看随机 IO 和顺序 IO。先来解释下这两个概念。相信不少人应该吃过旋转火锅，服务员把一盘盘的菜放在旋转传输带上，然后等到这些菜转到我们面前，我们就可以拿到菜了，假设装一圈需要 4 分钟，则最短等待时间是 0（即菜就在你跟前），最长等待时间是 4 分钟（菜刚好在你跟前错过），那么平均等待时间即为 2 分钟，假设我们现在要拿四盘菜，这四盘菜随机分配在传输带上，则可知拿到这四盘菜的平均等待时间是 8 分钟（随机 IO），如果这四盘菜刚好紧邻着排在一起，则等待时间只需 2 分钟（顺序 IO）。

上述中传输带就类比磁道，磁道上的菜就类比扇区（sector）中的信息，磁盘块（block）是由多个相邻的扇区组成的，是操作系统读取的最小单元，这样如果信息能以 block 的形式聚集在一起，就能极大减少磁盘 IO 时间,这就是顺序 IO 带来的性能提升，下文中我们将会看到 B+ 树索引就起到这样的作用。

 

 

而如果信息在一个磁道中分散地分布在各个扇区中，或者分布在不同磁道的扇区上（寻道时间是随机IO主要瓶颈所在），将会造成随机 IO，影响性能。我们来看一下一个随机 IO 的时间分布：

 

 

1. seek Time: 寻道时间，磁头移动到扇区所在的磁道
2. Rotational Latency：完成步骤 1 后，磁头移动到同一磁道扇区对应的位置所需求时间
3. Transfer Time 从磁盘读取信息传入内存时间

目录：springboot2 Vue shiro云管理系统项目实战
      ┣━━资料源码文档
      ┣━━01 Activiti7工作流引擎
      ┣━━02 SAAS-HRM系统概述与搭建环境
      ┣━━03 SAAS-HRM-数据库设计与前端框架
      ┣━━04 SAAS-HRM系统用户权限设计概述
      ┣━━05 权限分配与jwt概述
      ┣━━06 JWT的权限控制与Shiro入门
      ┣━━07 Shiro高级 及SaaS-HRM的认证授权
      ┣━━08 员工管理及POI
      ┗━━09 图片上传与Jasper

下载地址：百度云盘