java面试宝典

struct``sdshdr{
//等于SDS保存字符串的长度
intlen;
//记录buf数组中未使用字节的数量
intfree;
//字节数组，用于保存字符串
charuf[];
}

读写分离，提高效率

数据热备份，提供多个副本

主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预

主节点的存储能力和写能力受到限制（只有一个主节点）

全量同步可能会造成毫秒或者秒级的卡顿现象

全量复制

增量复制

主节点会维护一个**backlog**记录所有从节点同步的**replica offset**和master的**run id**

每个从节点也会记录一份自己的**replica offset**和**master**的**run id**方便下次增量复制

如果一个master被标记为主观下线，那么正在监视这个master的所有Sentinel节点，要以每秒一次的频率确认该主服务器是否的确进入了主观下线状态。

如果有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个该主服务器被标记为客观下线。

使用Raft算法，第一个哨兵向其他哨兵发送请求，如果超过半数同意则他成为为领头哨兵

当有多个哨兵参选，则会出现没有任何节点当选的可能，此时每个参选节点将等待一个随即时间重新发起竞选，直到选举成功。

所有先线的从数据库中，选择优先级最高的，优先级可以通过slave-priority来设置；

如果有多个一样优先级的从数据库，则复制的命令偏移量越大，越优先(与down掉的主数据库最接近)；

如果还有多个备选，则选择运行ID较小的(运行ID不会重复)；

选择好节点后，领头哨兵将想这个节点发送slaveofnoone，升级他为主数据库。

原来的主节点何去何从

单节点写操作，限制了写的能力，如果master挂了，切换节点过程中，则不提供写能力

缺点

优点

基本概念

数据完善

文件大数据恢复速度慢

针对淘汰机制的处理

可通过配置文件设置快照生成速度

生成标准规则

存储数据不及时

消耗cpu

针对淘汰机制的处理

含义

优点

缺点

含义

优点

缺点

含义

优点

缺点

难点

定时删除和定期删除为主动删除：Redis会定期主动淘汰一批已过去的key

惰性删除为被动删除：用到的时候才会去检验key是不是已过期，过期就删除

惰性删除为redis服务器内置策略

定期删除可以通过：

-第一、配置redis.conf的hz选项，默认为10（即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大）

-第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略

含义

机制

常量池

有多个线程，线程中有多个栈帧（详解）

新生区

老年区

永久区

默认的，新生代(Young)与老年代(Old)的比例的值为1:2，可以通过参数–XX:NewRatio配置

默认的，Edem:from:to=8:1:1(可以通过参数–XX:SurvivorRatio来设定)

Survivor区中的对象被复制次数为15(对应虚拟机参数-XX:+MaxTenuringThreshold)

可达性算法

通过一个类的全限定名来获取定义此类的二进制字节流

将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

确保被加载的类的正确性

确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全

文件格式验证：验证字节流是否符合Class文件格式的规范，如：是否以模数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围内等等。

元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求；如：这个类是否有父类，是否实现了父类的抽象方法，是否重写

了父类的final方法，是否继承了被final修饰的类等等

字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，如：操作数栈的数据类型与指令代码序列能配合工作，保证方法中的类型转换有效等等

符号引用验证：确保解析动作能正确执行；如：通过符合引用能找到对应的类和方法，符号引用中类、属性、方法的访问性是否能被当前类访问等等

验证阶段是非常重要的，但不是必须的。可以采用-Xverify:none参数来关闭大部分的类验证措施

为类的静态变量分配内存，并将其赋默认值

为类变量分配内存并设置类变量初始值，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

只对static修饰的静态变量进行内存分配、赋默认值（如0、0L、null、false等）

对final的静态字面值常量直接赋初值（赋初值不是赋默认值，如果不是字面值静态常量，那么会和静态变量一样赋默认值）

将常量池中的符号引用替换为直接引用（内存地址）的过程

符号引用就是一组符号来描述目标，可以是任何字面量。属于编译原理方面的概念如：包括类和接口的全限定名、字段的名称和描述符、方法的名称和描述符

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。如指向方法区某个类的一个指针

为类的静态变量赋初值，只有对类的主动使用才会导致类的初始化

在编译生成class文件时，编译器会产生两个方法加于class文件中，一个是类的初始化方法clinit,另一个是实例的初始化方法init

执行了System.exit()方法

程序正常执行结束

程序在执行过程中遇到了异常或错误而异常终止

由于操作系统出现错误而导致Java虚拟机进程终止

创建类对象

使用类的静态域

创建子类对象

使用子类的静态域

在JVM启动时，BootStrapLoader会加载一些JVM自身运行所需的class（父类未nul，因为jvm是C语言编写java无法表示l）

在JVM启动时，ExtClassLoader会加载指定目录下一些特殊的class

在JVM启动时，AppClassLoader会加载classpath路径下的class，以及main函数

ClassLoader.loadClass(className)，只加载和连接、不会进行初始化

Class.forName(Stringname,booleaninitialize,ClassLoaderloader);使用loader进行加载和连接，根据参数initialize决定是否初始化。

有or必全有索引

复合索引未用左列字段

like以%开头

需要类型转换

where中索引列有运算

where中索引列使用了函数

如果mysql觉得全表扫描更快时（数据少）

通过命令查看慢查询最长时间，一般默认10s

SHOWVARIABLESLIKE'long_query_time'

可以看到，slow_query_log  默认是  OFF，我们必须要打开它

SETGLOBALslow_query_log=ON

打开Mysql安装位置,找到my.ini文件并打开，查找datadir对应的目录，日志文件就放在该目录下

showstatuslike'slow_queries'//显示慢查询次数

查看他是否走预期的索引，和sql执行级别

redolog是重做日志，提供前滚操作

redolog通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能

恢复到最后一次提交的位置)

InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(BufferPool)

，BufferPool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库读取数据时，会首先从BufferPool中读取，如果BufferPool中

没有，则从磁盘读取后放入BufferPool；当向数据库写入数据时，会首先写入BufferPool，BufferPool中修改的数据会定期刷新到磁盘中（这一过程称

为刷脏）

BufferPool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时BufferPool中修改的数据还没有刷新到磁盘，就会导致

数据的丢失，事务的持久性无法保证

于是，redolog被引入来解决这个问题：当数据修改时，除了修改BufferPool中的数据，还会在redolog记录这次操作；当事务提交时，会调用fsync接

口对redolog进行刷盘。如果MySQL宕机，重启时可以读取redolog中的数据，对数据库进行恢复。redolog采用的是WAL（Write-aheadlogging，预

写式日志），所有修改先写入日志，再更新到BufferPool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求

既然redolog也需要在事务提交时将日志写入磁盘，为什么它比直接将BufferPool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因：

（1）刷脏是随机IO，因为每次修改的数据位置随机，但写redolog是追加操作，属于顺序IO。

（2）刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redolog中只包含真正需要写入的部分，

无效IO大大减少

undolog是回滚日志，提供回滚操作

undo用来回滚行记录到某个版本。undolog一般是逻辑日志，根据每行记录进行记录。

redolog保证数据持久性，undo log保证数据原子性

undolog，实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。InnoDB实现回滚，靠的是undolog：当事务对数据库进行

修改时，InnoDB会生成对应的undolog；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undolog中的信息将数据回滚到

修改之前的样子

undolog属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undolog的内容做与之前相反的工作：对于每个insert，回

滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相反的update，把数据改回去

当事务执行update时，其生成的undolog中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时

便可以使用这些信息将数据还原到update之前的状态

要执行的事务是一个独立的操作单元，要么全部执行，要么全部不执行

事务的一致性是指事务的执行不能破坏数据库的一致性，一致性也称为完整性。一个事务在执行后，数据库必须从一个一致性状态转变为另一个一致性状态

多个事务并发执行时，一个事务的执行不应影响其他事务的执行，SQL92规范中对隔离性定义了不同的隔离级别

隔离级别

脏读，幻读，不可重复读，丢失修改

redo log保证数据持久性

数据库事务可以包含一个或多个数据库操作，但这些操作构成一个逻辑上的整体

要么全部执行要么全部不执行要么全部产生影响要么全不产生

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的3个隐式字段，undo日志，ReadView

来实现的。所以我们先来看看这个三个point的概念

隐藏列：InnoDB中每行数据都有隐藏列，隐藏列中包含了本行数据的事务id、指向undolog的指针等。

基于undolog的版本链：前面说到每行数据的隐藏列中包含了指向undolog的指针，而每条undolog也会指向更早版本的undolog，从而形成一条版本链。

ReadView：通过隐藏列和版本链，MySQL可以将数据恢复到指定版本；但是具体要恢复到哪个版本，则需要根据ReadView来确定。所谓ReadView，

是指事务（记做事务A）在某一时刻给整个事务系统（trx_sys）打快照，之后再进行读操作时，会将读取到的数据中的事务id与trx_sys快照比较，从而

判断数据对该ReadView是否可见，即对事务A是否可见

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

https://www.cnblogs.com/kismetv/p/10331633.html

行锁

表锁

全局锁

共享/排它锁(SharedandExclusiveLocks)

意向锁(IntentionLocks)

记录锁(RecordLocks)

间隙锁(GapLocks)

临键锁(Next-keyLocks)

插入意向锁(InsertIntentionLocks)

自增锁(Auto-incLocks)

参考博客

最左原则：B+Tree排序规则：按照从左到右字段排序，先比较第一个字段，如果第一个字段相同再比较第二个字段....以此类推

如果不遵守直接从第二个索引条件开始查询，则不走索引，因为第二索引，只有在第一个索引的基础上才会有序

概念

利用hash存储的话需要将所有的数据文件添加到内存，比较耗费内存空间，其不太支持范围查询

包含主键索引和对应的实际数据，索引的叶子节点就是数据节点，也就是说找到了索引也就找到了数据

索引的存储和数据的存储是分离的，也就是说找到了索引但没找到数据，需要根据索引上的值(主键)再次回表查询,非聚簇索引也叫做辅助索引

二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据

连接建立完成后，你就可以执行select语句了。执行逻辑就会来到第二步：查询缓存。

MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以key-value对的形式，被直接

缓存在内存中。key是查询的语句，value是查询的结果。如果你的查询能够直接在这个缓存中找到key，那么这个value就会被直接返回给客户端。

如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL不需要执

行后面的复杂操作，就可以直接返回结果，这个效率会很高。

**但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。**

查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更

新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配

置表，那这张表上的查询才适合使用查询缓存。

好在MySQL也提供了这种“按需使用”的方式。你可以将参数query_cache_type设置成DEMAND，这样对于默认的SQL语句都不使用查询缓存。而对于你确

定要使用查询缓存的语句，可以用SQL_CACHE显式指定，像下面这个语句一样：

mysql>selectSQL_CACHE*fromTwhereID=10；

需要注意的是，MySQL8.0版本直接将查询缓存的整块功能删掉了，也就是说8.0开始彻底没有这个功能了

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL需要知道你要做什么，因此需要对SQL语句做解析。

分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条SQL语句，MySQL需要识别出里面的字符串分别是什么，代表什么。

MySQL从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名T”，把字符串“ID”识别成“列ID”。

做完了这些识别以后，就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。

如果你的语句不对，就会收到“YouhaveanerrorinyourSQLsyntax”的错误提醒，比如下面这个语句select少打了开头的字母“s”。

mysql>elect*fromtwhereID=1;

ERROR1064(42000):YouhaveanerrorinyourSQLsyntax;checkthemanualthatcorrespondstoyourMySQLserverversion

fortherightsyntaxtousenear'elect*fromtwhereID=1'atline1

一般语法错误会提示第一个出现错误的位置，所以你要关注的是紧接“usenear”的内容。

经过了分析器，MySQL就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。

优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。比如你执行下面这样的

语句，这个语句是执行两个表的join：

mysql>select*fromt1joint2using(ID)wheret1.c=10andt2.d=20;

既可以先从表t1里面取出c=10的记录的ID值，再根据ID值关联到表t2，再判断t2里面d的值是否等于20。

也可以先从表t2里面取出d=20的记录的ID值，再根据ID值关联到t1，再判断t1里面c的值是否等于10。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。

优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错

等等，没关系，我会在后面的文章中单独展开说明优化器的内容。

MySQL通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。

开始执行的时候，要先判断一下你对这个表T有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示。

select*fromTwhereID=10;

ERROR1142(42000):SELECTcommanddeniedtouser'b'@'localhost'fortable'T'

如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

比如我们这个例子中的表T中，ID字段没有索引，那么执行器的执行流程是这样的：

调用InnoDB引擎接口取这个表的第一行，判断ID值是不是10，如果不是则跳过，如果是则将这行存在结果集中；

调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。

执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此，这个语句就执行完成了。

对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是

引擎中已经定义好的。

你会在数据库的慢查询日志中看到一个rows_examined的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据

行的时候累加的。

在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此**引擎扫描行数跟rows_examined并不是完全相同的。**我们后面会专门有一篇文章来

讲存储引擎的内部机制，里面会有详细的说明。