数据库mysql

mysql:

1.索引的结构原理，事务隔离级别：

• B+树的磁盘读写代价更低，因为B+树的所有非叶子节点只会存放索引信息，而真正的数据信息都只存放在叶子节点中，这样一来，每个非叶子节点存放的索引信息就更多，一次磁盘IO就可以读取更多的索引信息到内存中，可以减少磁盘IO的次数。
• B+树的查询效率更加稳定，由于非叶子节点只存索引信息，而没有真正的数据信息，所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
• B+树更加适合在区间查询的情况，由于B+树的数据都存储在叶子结点中，非叶子结点均为索引，只需要扫一遍叶子结点即可得到所有数据信息，但是B树因为其非叶子结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

 

• B+Tree的特性：

　　(1)由图能看出，单节点能存储更多数据，使得磁盘IO次数更少。

　　(2)叶子节点形成有序链表，便于执行范围操作。

　　(3)聚集索引中，叶子节点的data直接包含数据；非聚集索引中，叶子节点存储数据地址的指针。

• MySQL中MyISAM与InnoDB区别及选择 ：

MyISAM：支持全文索引;不支持事务;它是表级锁;会保存表的具体行数，不带where时，直接返回保存的行数。
InnoDB：5.6以后才有全文索引;支持事务；外键，它是行级锁;不会保存表的具体行数，扫描表来计算有多少行

InnoDB，DELETE 表时，是一行一行的删除。    DELETE 表时，先drop表，然后重建表
InnoDB中必须包含AUTO_INCREMENT类型字段的索引    MyISAM中可以使AUTO_INCREMENT类型字段建立联合索引

一般：不用事务的时候,count计算多的时候适合myisam引擎。对可靠性要求高就是用innodby引擎。推荐用InnoDB引擎.

加了索引之后能够大幅度的提高查询速度，但是索引也不是越多越好，一方面它会占用存储空间，另一方面它会使得写操作变得很慢。通常我们对查询次数比较频繁，值比较多的列才建索引。
例如：select * from user where sex = "女"， 这个就不需要建立索引，因为性别一共就两个值，查询本身就是比较快的。
　　　select * from user where user_id = 1995 ,这个就需要建立索引，因为user_id的值是非常多的。

 

事务隔离级别：

MySQL的默认隔离级别的实现依赖于MVCC和锁，准确点说就是一致性读和锁

 

mysql与redis做二级缓存

• 对于访问量比较大的数据我们为了能够更快的获取到数据需要对数据库中获取的数据进行数据缓存。
• 在项目当中使用Redis缓存流程
  1. 查询时先从缓存当中查询
  2. 缓存当中如果没有数据再从数据库查询，并将数据保存进缓存当中
  3. 如果缓存中查询到了数据直接返回，不再需要查询数据库

  数据缓存应该考虑同步问题：如果对数据进行了缓存，当查询数据时，如果缓存中有数据则直接返回缓存数据不会查询数据库，当数据库数据改变的时候就有可能出现数据库不一致的问题。可以考虑在每次修改数据库的时候同时将对应的缓存数据删除，这样重新查询的时候就会查询数据库并缓存

• 乐观锁和悲观锁

在关系数据库管理系统中，悲观并发控制（悲观锁，PCC）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作的每行数据应用了锁，那只有当这个事务锁释放，其他事务才能够执行与该锁冲突的操作

乐观并发控制也是一种并发控制的方法。
假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据，在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没其他事务修改该数据，如果有则回滚正在提交的事务

 

2.sql优化：

1）选择正确的存储引擎
以 MySQL为例，包括有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。
MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。

InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。但是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用，比如：事务。

（2）优化字段的数据类型

记住一个原则，越小的列会越快。如果一个表只会有几列罢了（比如说字典表，配置表），那么，我们就没有理由使用 INT 来做主键，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更经济一些。如果你不需要记录时间，使用 DATE 要比 DATETIME 好得多。当然，你也需要留够足够的扩展空间。

（3）为搜索字段添加索引

索引并不一定就是给主键或是唯一的字段。如果在你的表中，有某个字段你总要会经常用来做搜索，那么最好是为其建立索引，除非你要搜索的字段是大的文本字段，那应该建立全文索引。

(4)避免使用Select *从数据库里读出越多的数据，那么查询就会变得越慢。并且，如果你的数据库服务器和WEB服务器是两台独立的服务器的话，这还会增加网络传输的负载。即使你要查询数据表的所有字段，也尽量不要用*通配符，善用内置提供的字段排除定义也许能给带来更多的便利。

(5)使用 ENUM 而不是 VARCHAR

ENUM 类型是非常快和紧凑的。在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来做一些选项列表变得相当的完美。例如，性别、民族、部门和状态之类的这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。

(6)尽可能的使用 NOT NULL

除非你有一个很特别的原因去使用 NULL 值，你应该总是让你的字段保持 NOT NULL。 NULL其实需要额外的空间，并且，在你进行比较的时候，你的程序会更复杂。 当然，这里并不是说你就不能使用NULL了，现实情况是很复杂的，依然会有些情况下，你需要使用NULL值。

(7)固定长度的表会更快

如果表中的所有字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。 例如，表中没有如下类型的字段： VARCHAR，TEXT，BLOB。只要你包括了其中一个这些字段，那么这个表就不是“固定长度静态表”了，这样，MySQL 引擎会用另一种方法来处理。

固定长度的表会提高性能，因为MySQL搜寻得会更快一些，因为这些固定的长度是很容易计算下一个数据的偏移量的，所以读取的自然也会很快。而如果字段不是定长的，那么，每一次要找下一条的话，需要程序找到主键。

并且，固定长度的表也更容易被缓存和重建。不过，唯一的副作用是，固定长度的字段会浪费一些空间，因为定长的字段无论你用不用，他都是要分配那么多的空间。

 

3.redis的内存

 

 

4.OAuth2实现原理   JWT认证机制

OAuth是一个关于授权的开放网络标准，目前的版本是2.0。通过这个网络标准，一个第三方应用(客户端)可以获取资源所有者(用户)在服务提供商(为用户提供服务的服务商)保存的特定资源。在这个标准中，第三方应用不能直接登录服务提供商，资源所有者只负责做是否授权以及授权哪些资源的决策，根据决策结果，第三方应用可以获得有时效、有授权范围的令牌，并通过令牌从服务供应商那里获得特定的资源。

 

 

5.es的原理，端口 9200

倒排索引（反向索引）、分析（分词，标准化处理）、相关性排序

 

6.git

远程关联项目，创建分支，提交

 

7.docker的使用，常见命令？镜像，容器，仓库

#查看所有容器:
docker ps -a 
#查看所有镜像:
docker image ls
#删除所有的容器:
docker rm xxxx

 

8.nginx的使用：反向代理，负载均衡