mysql索引原理以及查询优化：https://www.cnblogs.com/bypp/p/7755307.html

SQL优化的十大策略：

一、尽量全值匹配：当建立了索引列后，在where条件中使用索引的尽量使用

二、最佳左前缀法则：如果索引了多列，要遵守最左前缀法则，指的是查询从索引的最左前列开始并且不跳过索引中的列

三、不在索引列上做任何操作：在索引列上做任何操作（计算、函数（自动or手动）类型转换），会导致索引失效而转向全表扫描 （left、right）

四、范围条件放最后：中间有范围查询会导致后面的索引列全部失效

五、覆盖索引尽量用：尽量使用覆盖索引（只访问索引的查询：索引列和查询列一致），减少select *

六、不等于要慎用：mysql在使用不等于（！=或者<>）的时候无法使用索引会导致全表扫描，如果一定需要使用不等于，要使用覆盖索引

七、null/not有影响：自定义为not null，在字段定义为not null的情况下，使用is null或is not null会失效，解决方式，可以使用覆盖索引；自定义为null或者不定义，is not null的情况会导致索引失效，解决方式，可以使用覆盖索引

八、like查询要当心：like以通配符开头（'%abc...'）mysql索引失效会变成全表扫描的操作，解决方式，可以使用覆盖索引

九、字符类型加引号：字符串不加单引号索引失效，解决方式，加上引号

十、or改union效率高：解决方式，使用覆盖索引

 　　全职匹配我最爱，最左前缀要遵守；

带头大哥不能死，中间兄弟不能断；

索引列上少计算，范围之后全失效；

LIKE 百分写最右，覆盖索引不写*；

不等空值还有 OR，索引影响要注意；

VAR 引号不可丢， SQL 优化有诀窍。

三星索引：

　　对于一个查询而言，一个三星索引，可能是其最好的索引。如果查询使用三星索引，一次查询通常只需要进行一次磁盘随机读以及一次窄索引片的扫描，因此其相应时间通常比使用一个普通索引的响应时间少几个数量级。

　　三星索引概念是在《Rrelational Database Index Design and the optimizers》一书中提出来的。原文如下：

　　The index earns one star if it places relevant rows adjacent to each other,a second star if its rows are sorted in the order the query needs,and a final star if it contains all the columns needed for the query.

　　索引将相关的记录放到一起则获得一星；如果索引中的数据顺序和查找中的排列顺序一致则获得二星；如果索引中的列包含了查询中需要的全部列则获得三星。

　　二星（排序星）：

　　在满足一星的情况下，当查询需要排序，group by、order by，如果查询所需的顺序与索引是一致的（索引本身是有序的），是不是就可以不用再另外排序了，一般来说排序可是影响性能的关键因素。

　　三星（宽索引星）：

　　在满足了二星的情况下，如果索引中所包含了这个查询所需的所有列（包括where 子句 和 select 子句中所需的列，也就是覆盖索引），这样一来，查询就不再需要回表了，减少了查询的步骤和 IO 请求次数，性能几乎可以提升一倍。

　　一星按照原文稍微有点难以理解，其实它的意思就是：如果一个查询相关的索引行是相邻的或者至少相距足够靠近的话，必须扫描的索引片宽度就会缩至最短，也就是说，让索引片尽量变窄，也就是我们所说的索引的扫描范围越小越好。

　　这三颗星，哪颗最重要？第三颗星。因为将一个列排除在索引之外可能会导致很多磁盘随机读（回表操作）。第一和第二颗星重要性差不多，可以理解为第三颗星比重是 50%，第一颗星为 27%，第二颗星为 23%，所以在大部分的情况下，会先考虑第一颗星，但会根据业务情况调整这两颗星的优先度。

　　三星索引：https://zhuanlan.zhihu.com/p/140815969

 

索引在查询中的作用到底是什么？在我们的查询中发挥着什么样的作用呢？

1、一个索引就是一个 B+树，索引让我们的查询可以快速定位和扫描到我们需要的数据记录上，加快查询的速度。

2、一个 select 查询语句在执行过程中一般最多能使用一个二级索引，即使在 where 条件中用了多个二级索引。

 

查看数据库表和索引占空间大小：http://www.maomao365.com/?p=9938

select CONCAT(sum(index_length/(1024*1024)) ,'MB') as 'indexTotal'  from information_schema.TABLES WHERE table_schema LIKE '数据库名称';

select CONCAT(sum(data_length/(1024*1024)) ,'MB') as 'indexTotal'  from information_schema.TABLES WHERE table_schema LIKE '数据库名称';

 

hashmap数据结构：链表+数组（jdk1.7），链表+数组+红黑树（jdk1.8）

数组默认长度：16

hashmap初始值是16，扩容*2

链表转成红黑树：链表的长度大于等于8，数组的长度大于等于64

hash算法：

二叉树查询数据次数是根据树的高度决定的，所以数据过多的时候查询次数多

平衡二叉树缺点：（1）io次数过多，以页为单位（2）page是16kb，目标数据过少，io浪费

 

使用B-Tree代替：

B-Tree划分区间是左开右闭，
5,20
无穷小，5 开区间
5
5,20 开区间
20
20，无穷大 开区间
查找关键字的时候，直接查找数据区去返回 io1次


B+Tree划分区间是左闭右开
1,28,66
[1,28)
[28,66)
[66,无穷大）
查找关键字的时候，还需要查找数据区 io3次


B-Tree和B+Tree的区别
1、关键字个数：路数=1:1
2、只有叶子节点有数据区
3、数据区间划分有所区别

 

聚集索引B+Tree叶子节点包含了行的全部数据，二级索引的叶子节点除了索引列值，还存这一列对应的主键值。

InnoDB聚集索引B+Tree叶子节点存储了整个表的数据，而不是只有索引列，每个叶子节点包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列（col2），二级索引的叶子节点中存储的不是“行指针”，而是主键值，并以此作为指向行的“指针”。

 

Linux安装rocketmq：https://www.cnblogs.com/dalaoyang/p/10165976.html

mysql索引数据结构：https://www.cnblogs.com/yuanrw/p/10225659.html

 

 

mysql join类型

inner join、left join、right join、full outer join

https://baijiahao.baidu.com/s?id=1721012097132441462&wfr=spider&for=pc

 

 

mysql根据id递归查询该节点及所有父节点名称

select group_concat(t2.catalog_name order by t1.lvl desc separator '>') as directorys from
(select @r as _id,(select @r:=parent_id from data_api_catalog where data_api_catalog_id = _id) as parent_id,@l:=@l+1 as lvl from (select @r:=23,@l:=0) vars,data_api_catalog h where @r<>0)
#      叶子节点id       赋值变量 r为父id                                                                                                   叶子节点id 编号
#              即查询表中parentId赋值给变量r，r又是叶子节点，然后将它的父节点赋值给该变量，直到找到节点父id为0时结束
#   　　边查询边赋值，直到最顶层节点，最后使用group_concat将所有查询结果使用分隔符'>'连接起来

t1
join data_api_catalog t2
on t1._id = t2.data_api_catalog_id

最后查询结果：

参考：https://wenku.baidu.com/view/76efaae10ba1284ac850ad02de80d4d8d15a010f.html