标签：conf fas 加载 redo log b+tree 请求 调度 优化技巧 plain
1. Mysql查询时limit offset比较大时的性能问题 https://blog.csdn.net/fdipzone/article/details/72793837
优化方案：先根据索引查询出主键id，然后根据主键id关联出数据
知识点：
a. mysql一级索引、二级索引，以及innodb与myisam的索引区别
2. Mysql索引原理 https://www.jianshu.com/p/d90f6b028d0e
索引：索引是数据库管理系统中的一个排序的数据结构（通常使用B+Tree）
Mysql引擎：Innodb和MyISAM，两种引擎的索引都是B+Tree数据
Innodb索引与MyISAM索引区别：
a. Innodb索引是聚集索引，数据文件本身就是主键索引，叶节点保存了完整的数据记录。MyISAM索引是非聚集索引，索引和数据分离
b. Innodb辅助索引叶节点data域 存储相应数据的主键值
3. MyISAM与Innodb的区别
1）InnoDB支持事务，MyISAM不支持。
2）MyISAM适合查询以及插入为主的应用，InnoDB适合频繁修改以及涉及到安全性较高的应用。
3）InnoDB支持外键，MyISAM不支持。
4）从MySQL5.5.5以后，InnoDB是默认引擎。
5）MyISAM支持全文类型索引，而InnoDB不支持全文索引。
6）InnoDB中不保存表的总行数，select count(*) from table时，InnoDB需要扫描整个表计算有多少行，但MyISAM只需简单读出保存好的总行数即可。 注：当count(*)语句包含where条件时MyISAM也需扫描整个表。
7）对于自增长的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中可以和其他字段一起建立联合索引。
8）清空整个表时，InnoDB是一行一行的删除，效率非常慢。MyISAM则会重建表。MyisAM使用delete语句删除后并不会立刻清理磁盘空间，需要定 时清理，命令：OPTIMIZE table dept;
9）InnoDB支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like ‘%lee%’）
10）Myisam创建表生成三个文件：.frm 数据表结构 、 .myd 数据文件 、 .myi 索引文件，Innodb只生成一个 .frm文件，数据存放在ibdata1.log
现在一般都选用InnoDB，主要是MyISAM的全表锁，读写串行问题，并发效率锁表，效率低，MyISAM对于读写密集型应用一般是不会去选用的。
应用场景：
MyISAM不支持事务处理等高级功能，但它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
InnoDB用于需要事务处理的应用程序，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。
4. 数据库3范式
第一范式：属性的原子性约束，即要求字段不可拆分
第二范式：满足第一范式前提下，非主键字段要完全依赖主键字段，而不是依赖主键字段的一部分（常见于复合主键的情况）
第三范式：满足第二范式前提下，非主键字段不能出现传递依赖（比如某个字段a依赖于主键，而一些字段依赖字段a）
5. 事务四大特性
原子性：一个事务内的一组操作要么都成功，要么都失败
一致性：一个事务使数据从一种正确状态变更到另一种正确状态
隔离性：事务之间彼此隔离互不影响
持久性：事务一旦提交，其结果将是永久的，即便发生系统故障也能恢复
6. 事务隔离级别
读未提交：允许脏读，可以读取到其他事务未提交的数据
读已提交：只能读取到事务已经提交的数据（数据库默认级别）
可重复读：无论其他事务是否已经提交，当前事务读取的数据不受其他事务影响
串行化：事务串行化执行，读写操作会互相阻塞
注意：MySql数据库（Innodb引擎）默认使用可重复读
7. Mysql中的锁
MyISAM支持表锁，InnoDB支持表锁和行锁，默认为行锁
表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低
行级锁：开销大，加锁慢，会出现死锁。锁力度小，发生锁冲突的概率小，并发度最高
8. Mysql死锁的原因及解决方法
解决方法：多个session加锁的顺序约定一致
9. delete、drop、truncate的区别
a. truncate和delete只删数据不删表结构，drop删除表结构和数据
b. delete数据DML，需要事务管理，commit后才生效。truncate和drop属于DDL，不需要事务管理，不可回滚
c. 删除速度：drop > truncate > delete
10. 多版本并发控制（MVCC）--乐观锁的一种实现方式
a. 每行数据都存在一个版本，每次数据更新都更新该版本
b. 修改时copy出数据随意更改，各事务之间无干扰
c. 保存时比较版本号，成功则commit；否则，rollback
注意：mvcc只适用innodb中的读已提交(RC)和可重复读(RR)
mvcc实现策略：每一行隐藏两个列（行创建时的版本号和删除时的版本号）
11. 如何进行SQL优化
a. 选择正确的数据库引擎（MyISAM、Innodb）
MyISAM：查询多、支持全文检索、不支持事务、表锁（update性能低，update时阻塞读）
Innodb：不支持全文检索、支持事务、行锁（update性能高）、数据安全性高
b. 优化字段的数据类型
原则：越小的列会越快（smallint比int小，date比datetime小）
c. 为搜索字段添加索引
d. 避免适用select *查询
e. 使用ENUM而不是varchar
f. 固定长度的表会更快。如果表中的所有字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。固定长度容易计算偏移量
12. SQL优化技巧：
a. where表之间的连接必须写在其他where条件之前，可以过滤掉大量数据的条件必须写在where子句末尾
b. 用exists代替in、用not exists代替not in
c. 避免在索引列上使用函数计算
d. 避免在索引列上使用is null、is not null
13. exist和in
in是把外表和表作hash join；exist对外表作loop循环，每次循环对表进行查询
如果内表较大则exist效率高；如果内表较小，则in效率较高；如果两个表数据量差不多，则效率差不多
14. char和varchar的区别
a. char是固定长度的，varchar是可变长度的
b. char(M)表示每个值要占固定M个字节，如果长度小于M，Mysql会自动用空格不足
varchar(M)每个值只占用刚好够用的字节再加上一个用来记录其长度的字节
15. MySql主从复制原理 https://blog.csdn.net/Marmara01/article/details/89570522
a. 主：binlog线程——记录下所有改变来了数据库数据的语句，放进master上的binlong日志中
b. 从：io线程——在使用start slave之后，负责从master上拉取binlog内容，放进自己的relay log中
c. 从：sql执行线程——执行relay log中的语句；
16. Mysql复制线程有几个，以及它们之间的关联
a. Master上面的binlog dump线程
b. Slave上面的IO线程，从master上拉取binlog日志，bin写入到relay log中
c. Slave上的Sql线程，读取relay log日志内容，并执行sql语句
d. 如果是多线程复制，Sql线程只做coordinator（调度），即读取relay log中的内容交给worker线程执行。
17. 事务是如何通过日志实现的
因为事务在修改页时，要先记 undo，在记 undo 之前要记 undo 的 redo， 然后修改数据页，再记数据页修改的 redo。 Redo（里面包括 undo 的修改） 一定要比数据页先持久化到磁盘。 当事务需要回滚时，因为有 undo，可以把数据页回滚到前镜像的
状态，崩溃恢复时，如果 redo log 中事务没有对应的 commit 记录，那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录，就用 redo 前滚到该事务完成时并提交掉
18. Mysql数据库cpu达到500%如何处理？
当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等
19. 主从一致性校验工具：checksum、mysqldiff、pt-table-checksum
20. Mysql中innodb的行锁是加在什么上实现的？
InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
f
for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,
如果 id 不是索引键那么InnoDB将完成表锁,并发将无从谈起
21. explain出来的各种item的意义
id:每个被独立执行的操作的标志，表示对象被操作的顺序。一般来说， id 值大，先被执行；如果 id 值相同，则顺序从上到下。
select_type：查询中每个 select 子句的类型（SIMPLE、PRIMARY、UNION、UNION RESULT、SUBQUERY）
table:名字，被操作的对象名称，通常的表名(或者别名)，但是也有其他格式。
partitions:匹配的分区信息。
type:连接类型（）。
possible_keys：列出可能会用到的索引。
key:实际用到的索引。
key_len:用到的索引键的平均长度，单位为字节。
ref:表示本行被操作的对象的参照对象，可能是一个常量用 const 表示，也可能是其他表的
key 指向的对象，比如说驱动表的连接列。
rows:估计每次需要扫描的行数。
filtered:rows*filtered/100 表示该步骤最后得到的行数(估计值)。
extra:重要的补充信息
######################################################################################
一.jdk8新特性
1. 接口新增默认方法和静态方法。默认方法加上default修饰符，并且有方法体；静态方法使用static声明
2. 函数式接口。接口类上标记@FunctionInterface
2.1
二. 锁
1. synchronized与Lock的区别
a. synchronized是一个关键词，Lock是一个接口
b. 出现异常时synchronized自动释放锁，Lock不能自动释放
c. synchronized不能知道是否已经加过锁，Lock.tryLock能判断是否已经加锁
d. synchronized采用的是CPU悲观锁，即线程获得是独占锁。很多线程阻塞时，会导致CPU频繁切换上下文，效率很低。
Lock采用的是乐观锁，如果有冲突时，会进行重试直到成功。乐观锁的机制是CAS
e. Lock可以让等待锁的线程响应中断，而synchronized则不行
lock.lockInterruptibly(); //允许在等待时由其他线程调用Thread对象的interrupt()方法中断等待锁的线程r
2. Condition的使用
当满足一定条件时，调用condition的await()方法使当前线程休眠进行等待，调用Condition的signalAll()方法唤醒因await()进入等待的线程。
典型的生产-消费模型中可以使用：
ReentrantLock lock = new ReentrantLock();
consummerCond = lock.newCondition();
providerCond = lock.newCondition();
List<String> pool = new ArrayList<String>();
int maxSize = 100;
consummer(){
lock.lock();
try{
//如果池中数据为空，则线程等待
if(pool.size() == 0){
consummerCond.await();
}
pool.get();//从池中消费
providerCond.signalAll();//唤醒所有等待的生产者
}catch(){}
finally{
lock.unlock();
}
}
斐波那契：f(1) = 1 f(2) =1 f(n)=f(n-1)+f(n-2)
####################################################################
1. 为什么要用springboot?
a. 独立运行：内嵌各种servlet容器、tomcat、jetty等
b. 简化配置
c. 自动配置
2. springboot核心配置：
1. bootstrap.yml 优先加在，不能被application.yml覆盖
2. application.yml
3. springboot核心注解
@SpringBootApplication用于启动类上，包含@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan
4. 自动配置的原理
5. springboot启动时运行特定代码
通过实现ApplicationRunner或CommandLineRunner接口
CommandLineRunner获取命令行参数？？
ApplicationRunner获取应用启动的参数
6. springboot读取配置文件的方式
a. @ConfigurationProperties(prefix="info") //用于类上
b. @Value //用于属性上
c. @PropertySource(value={"xxx.properties"}) + @Value //不能支持yml配置
d. @PropertySource(value={"xxx.properties"}) + @ConfigurationProperties(prefix="info")
e. @Autowired
private Enviroment env; //上述的所有配置都可以通过注入Enviroment对象获取
7. springboot支持的日志框架：log4j2、logback(默认)
8. springboot热部署的方式
a. 依赖spring-boot-devtools
9. 多环境配置：启动参数spring.profiles.active
10. 单元测试
@RunWith(SpringRunner.class)
@SpringBootTest //启动测试
//==========================SpringCloud=============================
1. eureka自我保护机制：当eureka server短时间内丢失了过多的实例连接时，节点会进入自我保护模式，保护注册数据，不再删除注册数据；当故障恢复时，自动退出自我保护模式。
2. 什么是熔断？什么是服务降级？
隔离方式：线程池、信号量（默认10）
线程池隔离：请求对象与执行请求的对象解耦，通过线程实现隔离
信号量隔离：控制并发的请求量，防止线程大面积阻塞
熔断：当服务出现某个异常时，直接熔断整个服务，而不是一直等到服务线程超时
回退降级：
a. 执行run时抛出异常
b. 熔断器打开
c. 线程池或信号量超额
d. 命令执行超时
回退降级的方式：
a. fast fail(快速失败)：直接抛异常
b. fast silent(无声失败)：getFallback返回null或空集合
c. Fallback static：getFallback返回静态默认值
d. Fallback Stubbed: getFallback返回复合对象
3. Hystrix 底层的执行流程和步骤
a. 创建Command（HystrixCommand或HystrixObservableCommand）
b. 调用Command执行方法
hystrixCommand.execute() //同步调用
hystrixCommand.queue() //异步调用，获取Future返回结果
hystrixObservableCommand.observer()
hystrixObservableCommand.toObserver()
c. 检查是否开启缓存。如果开启了缓存并且缓存中有数据，则直接返回；否则，下一步。
d. 检查线程池/信号量是否已满
e. 执行Command
f. 断路健康监测
g. 调用fallback降级
https://blog.csdn.net/qq_25484147/article/details/83375225
https://blog.csdn.net/oldshaui/article/details/90675149
4. 雪崩效应解决方案
a. 硬件故障：多机房容灾、异地多活
b. 流量激增：服务自动扩容、流量控制
c. 缓存穿透：缓存预加载、缓存异步加载
d. 同步等待：资源隔离、MQ解耦
#############################################################################
1. RabbitMq的好处：解耦、异步、削峰
2. RabbitMq中的Broker是什么？
broker是一个或多个erlang node的逻辑分组，并且node上运行着rabbitmq应用
3. 交换器种类：
direct:完全根据routingKey进行路由
fanout:交换器收到消息，广播到所有帮顶的队列上（与routingKey无关）
topic:可以使不同源头的消息路由到同一队列，routingKey支持通配符
header:可以根据数据中的key进行路由
4. 元数据：队列、交换机、绑定关系、vhost的定义
https://www.cnblogs.com/doit8791/p/10328402.html
5. 集群节点类型
磁盘节点：配置信息和元数据信息存储在磁盘上
内存节点：配置信息和元数据信息存储在内存中，性能远大于磁盘
注意：
a. 单节点系统必须是磁盘节点
b. rabbitmq要求集群中至少有一个磁盘节点，否则集群重启后元数据全都会丢失
如果磁盘节点全崩溃后：
a. 不能创建队列、交换器、绑定关系
b. 不能添加用户、更改权限
c. 不能添加和删除集群节点
6. 普通队列与镜像队列
普通队列：消息实体只存在于集群的一个节点上，其他节点上只存储队列的元数据
镜像队列：消息实体存在于集群的所有节点上，并且元数据存在于集群的所有节点；消息实体会主动在镜像队列之间进行同步
#########################################################################
1.Rabbitmq接收到不正确的数据报文时，不断的抛出异常
2.Mysql分页查询时，分页页数比较大时的性能问题
标签：conf fas 加载 redo log b+tree 请求 调度 优化技巧 plain
原文地址：https://www.cnblogs.com/wuan90/p/12109984.html
