数据库
为什么用自增列作为主键
如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销。同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构。
Mysql会默认使用主键作为聚集索引，如果没有索引，InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引。
为什么说B+比B树更适合实际应用中操作系统的文件索引和数据库索引？
1、B+的磁盘读写代价更低。
B+的内部结点并没有指向关键字具体信息的指针，因此其内部结点相对B树更小。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2、B+-tree的查询效率更加稳定。
所有的记录都存储在叶子节点上面。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
3、叶子节点都是有序链表存储的，更利于范围存储
MySQL InnoDB、Mysaim的特点？
Innodb是聚集索引，支持事务，支持外键 ，支持行锁，必须有唯一索引，适合修改删除多的，回表查询指的是innodb里面非聚集索引的查询。
Myisam是非聚集索引，叶子节点保存指向数据的指针。不支持事务。
Mysql默认隔离级别
可重复读（RR），由于之前mysql的binlog同步模式为statement，RC会产生数据不一致。当前binlog已经支持row的格式，可以选择RC+ROW，作为mysql的隔离级别和日记格式
数据库隔离级别是什么？
A原子性（undo log）、C一致性（AID来保证）、I隔离性（加锁、mvcc）、D持久性（redo log）
读已提交（脏读）、可重复读（读未提交）、序列化（幻读）
MySQL主备同步的基本原理。 当slave连接到master的时候，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，binlog dump线程会通知slave，并将相应的binlog内容发送给slave
如何优化数据库性能（索引、分库分表、批量操作、分页算法、升级硬盘SSD、业务优化、主从部署）
SQL什么情况下不会使用索引（不包含，不等于，函数）
MVCC
InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读
通过readview 机制和 undo log 实现了读不被阻塞，而且在一定程度上实现RC和RR，并且RR级别在大部分时候可以解决幻读
数据库事务的几种粒度
表锁、行锁（通过索引来加锁）只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁
如何解决高并发减库存问题
如何从一张表中查出name字段不包含“XYZ”的所有行？
not in where name LIKE "%XYZ%"
mysql主从同步延时分析 1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.使用比主库更好的硬件设备作为slave，mysql压力小，延迟自然会变小。
加锁原则
拿MySql的InnoDB引擎来说，对于insert、update、delete等操作。会自动给涉及的数据加排他锁；
对于一般的select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。
共享锁：SELECT ... LOCK IN SHARE MODE;
排他锁：SELECT ... FOR UPDATE;
Spring Cloud
Eureka的源码分析服务注册和服务发现以及心跳机制和保护机制，对比eureka与zookeeper，什么是CAP原则？
Ribbon源码分析和客服端负载均衡，客户端负载均衡？服务端负载均衡？ Ribbon核心组件IRule以及重写IRule
Fegin源码分析和声明式服务调用，Fegin负载均衡，Fegin如何与Hystrix结合使用？ 有什么问题？
Hystrix实现服务限流、降级，大型分布式项目服务雪崩如何解决？ 服务熔断到底是什么？一线公司的解决方案
HystrixDoashboard如何实现自定义接口降级、监控数据、数据聚合等等
Zuul统一网关详解、服务路由、过滤器使用等，从源头来拦截掉一些不良请求
分布式配置中心Config详解，如何与github或是其他自定义的git平台结合、比如gitlab
分布式链路跟踪详解，串联调用链，,让Bug无处可藏，如何厘清微服务之间的依赖关系？如何跟踪业务流的处理顺序？