lc-1.2数据库

1.sql优化有哪些？如何创建索引？创建索引的原则是什么？索引的优缺点？

1、在表中建立索引，优先考虑where、group by

2、减少使用 * ，用列名代替

3、避免在开头使用模糊查询（%）

该查询数据库引擎会放弃索引进行全表扫描。

 

4、需要删除所有记录的时候，用truncate

5、避免使用in和not in，会导致全表扫描

6、如果表名或列名过长，就使用别名

 

索引的数据结构？

非关系型数据库MongoDB使用B树作为数据库索引。

大部分关系型数据库，比如Mysql，则使用B+树作为索引。

B+树是基于B-树的一种变体，有着比B-树更高的查询性能。

B+树和B-树有一些共同点，但是B+树也具备一些新的特征。

在B+树中，只有叶子节点才真正存储数据，非叶子节点不存储数据。

使用B+树做索引的好处主要体现在查询性能上。

B+树和B-树的区别： 

B+树中间节点没有存储数据，只有叶节点存放数据，其余节点用来索引，所以同样大小的磁盘页可以容纳更多的节点元素，而B-树是每个索引节点都会有Data域。这就意味着，数据量相同的情况下，B+树的结构比B-树更加“矮胖”，因此查询是IO次数也更少。这就决定了B+树更适合用来存储外部数据，也就是所谓的磁盘数据。

B-树的查询性能并不稳定（最好情况是只查根节点，最坏情况是查到叶子节点）。而B+树每一次查找都是稳定的。

B+树相比B-树的优势有三个：

1.单一节点存储更多的元素，使得查询的IO次数更少。

2.所有查询都要查找到叶子节点，查询性能稳定。

3.所有叶子节点形成有序链表，便于范围查询。

数据库索引为什么用B+树而不用B-树？

数据库索引采用B+树的主要原因是B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作（或者说效率太低）。

那么MongoDB为什么使用B-树而不是B+树？

至于MongoDB为什么使用B-树而不是B+树，可以从它的设计角度来考虑，它并不是传统的关系性数据库，而是以Json格式作为存储的nosql，目的就是高性能，高可用，易扩展。首先它摆脱了关系模型，上面所述的范围查询的优点就没那么强烈了，其次Mysql由于使用B+树，数据都在叶节点上，每次查询都需要访问到叶节点，而MongoDB使用B-树，所有节点都有Data域，只要找到指定索引就可以进行访问，无疑单次查询平均快于Mysql（但侧面来看Mysql至少平均查询耗时差不多）。

总体来说，Mysql选用B+树和MongoDB选用B-树还是以自己的需求来选择的。

使用B+树而不是用其他结构的原因就是为了减少磁盘IO的次数，减少数的高度，而B+树就很好的做到了这一点。

 

B+树

每一个结点放到一个page中，一次连续的加载到内存

 

 MyISAM VS Innodb

  一个表有三个文件：

 .frm   表的定义文件：表结构

.MYD   数据文件

.MYI    index文件

Innodb :

  .frm

  .ibd: 聚集索引

索引失效的情况？

1.随着表的增长，where条件出来的数据太多，大于15%，使得索引失效

2.统计信息失效 需要重新搜集统计信息

3.索引本身失效 需要重建索引

 

replace()和replaceAll()的区别

相同点

都是全部替换,即把源字符串中的某一字符或字符串全部换成指定的字符或字符串,如果只想替换第一次出现的,可以使用 replaceFirst(),这个方法也是基于规则表达式的替换,但与replaceAll()不同的是,只替换第一次出现的字符串; 
另外,如果replaceAll()和replaceFirst()所用的参数据不是基于规则表达式的,则与replace()替换字符串的效果是一样的,即这两者也支持字符串的操作; 
还有一点注意:执行了替换操作后,源字符串的内容是没有发生改变的.

区别

replace的参数是char和CharSequence,即可以支持字符的替换,也支持字符串的替换(CharSequence即字符串序列的意思,说白了也就是字符串); 
replaceAll的参数是regex,即基于规则表达式的替换,比如,可以通过replaceAll(“\d”, “*”)把一个字符串所有的数字字符都换成星号;

 

如何创建索引？

 

建表时创建：

create table 表名（

字段名  数据类型  [完整性约束条件]，

.......,

[unique |  fulltext  |  spatial]  index | key [索引名] （字段名1 [(长度)] [asc | desc]）[using 索引方法]

）；

 

建表后创建：

alter table 表名 add[unique | fulltext | spatial] index | key [索引名] (字段名1[长度][asc|desc])[using 索引方法]；

或

create[unique | fulltext | spatial] index 索引名 on 表名（字段名）[using 索引方法];

 

创建索引的方法 
   创建索引有多种方法，这些方法包括直接创建索引的方法和间接创建索引的方法。
第一，   直接创建索引，例如使用CREATE INDEX语句或者使用创建索引向导。
第二，   间接创建索引，例如在表中定义主键约束或者唯一性键约束时，同时也创建了索引。
虽然，这两种方法都可以创建索引，但是，它们创建索引的具体内容是有区别的。
   使用CREATE INDEX语句或者使用创建索引向导来创建索引，这是最基本的索引创建方式，并且这种方法最具有柔性，可以定制创建出符合自己需要的索引。在使用这种方式创建索引时，可以使用许多选项，例如指定数据页的充满度、进行排序、整理统计信息等，这样可以优化索引。使用这种方法，可以指定索引的类型、唯一性和复合性，也就是说，既可以创建聚簇索引，也可以创建非聚簇索引，既可以在一个列上创建索引，也可以在两个或者两个以上的列上创建索引。
   通过定义主键约束或者唯一性键约束，也可以间接创建索引。主键约束是一种保持数据完整性的逻辑，它限制表中的记录有相同的主键记录。在创建主键约束时，系统自动创建了一个唯一性的聚簇索引。虽然，在逻辑上，主键约束是一种重要的结构，但是，在物理结构上，与主键约束相对应的结构是唯一性的聚簇索引。换句话说，在物理实现上，不存在主键约束，而只存在唯一性的聚簇索引。同样，在创建唯一性键约束时，也同时创建了索引，这种索引则是唯一性的非聚簇索引。因此，当使用约束创建索引时，索引的类型和特征基本上都已经确定了，由用户定制的余地比较小。
   当在表上定义主键或者唯一性键约束时，如果表中已经有了使用CREATE INDEX语句创建的标准索引时，那么主键约束或者唯一性键约束创建的索引覆盖以前创建的标准索引。也就是说，主键约束或者唯一性键约束创建的索引的优先级高于使用CREATE INDEX语句创建的索引。