大厂面试必备：java个人博客源码

梦里梦外; 2021-07-20 11:08 361阅读 0赞

# 摘要 #

**Apache Kafka**是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。

成千上万的企业都在使用Kafka，三分之一的世界500强公司也在其中，Kafka也是成长最快的开源项目之一，包括其生态系统也在蓬勃发展。Kafka正在成为管理和处理流式数据的利器。

Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。大家一起来跟着阿里专家学习Kafka吧。  
![892bcf819368e8f98c8128b038594a77.png][]

## 数据库 ##

### 1. MySQL 索引使用有哪些注意事项呢？ ###

可以从三个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景，索引规则

#### 索引哪些情况会失效 ####

*  查询条件包含or，可能导致索引失效
 *  如何字段类型是字符串，where时一定用引号括起来，否则索引失效
 *  like通配符可能导致索引失效。
 *  联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
 *  在索引列上使用mysql的内置函数，索引失效。
 *  对索引列运算（如，+、-、\*、/），索引失效。
 *  索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
 *  索引字段上使用is null， is not null，可能导致索引失效。
 *  左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
 *  mysql估计使用全表扫描要比使用索引快,则不使用索引。

#### 索引不适合哪些场景 ####

*  数据量少的不适合加索引
 *  更新比较频繁的也不适合加索引
 *  区分度低的字段不适合加索引（如性别）

#### 索引的一些潜规则 ####

*  覆盖索引
 *  回表
 *  索引数据结构（B+树）
 *  最左前缀原则
 *  索引下推

### 2. MySQL 遇到过死锁问题吗，你是如何解决的？ ###

我排查死锁的一般步骤是酱紫的：

*  查看死锁日志show engine innodb status;
 *  找出死锁Sql
 *  分析sql加锁情况
 *  模拟死锁案发
 *  分析死锁日志
 *  分析死锁结果

### 3. 日常工作中你是怎么优化SQL的？ ###

可以从这几个维度回答这个问题：

*  加索引
 *  避免返回不必要的数据
 *  适当分批量进行
 *  优化sql结构
 *  分库分表
 *  读写分离

### 4. 说说分库与分表的设计 ###

分库分表方案，分库分表中间件，分库分表可能遇到的问题

**分库分表方案:**

*  水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
 *  水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
 *  垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
 *  垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

**常用的分库分表中间件：**

*  sharding-jdbc（当当）
 *  Mycat
 *  TDDL（淘宝）
 *  Oceanus(58同城数据库中间件)
 *  vitess（谷歌开发的数据库中间件）
 *  Atlas(Qihoo 360)

**分库分表可能遇到的问题**

*  事务问题：需要用分布式事务啦
 *  跨节点Join的问题：解决这一问题可以分两次查询实现
 *  跨节点的count,order by,group by以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并。
 *  数据迁移，容量规划，扩容等问题
 *  ID问题：数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID
 *  跨分片的排序分页问题（后台加大pagesize处理？）

### 5. InnoDB与MyISAM的区别 ###

*  InnoDB支持事务，MyISAM不支持事务
 *  InnoDB支持外键，MyISAM不支持外键
 *  InnoDB 支持 MVCC(多版本并发控制)，MyISAM 不支持
 *  select count(\*) from table时，MyISAM更快，因为它有一个变量保存了整个表的总行数，可以直接读取，InnoDB就需要全表扫描。
 *  Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引）
 *  InnoDB支持表、行级锁，而MyISAM支持表级锁。
 *  InnoDB表必须有主键，而MyISAM可以没有主键
 *  Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小，。
 *  Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。
 *  InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与 MyISAM 比 InnoDB 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引

### 6. 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？ ###

可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？

**为什么不是一般二叉树？**

如果二叉树特殊化为一个链表，相当于全表扫描。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。

**为什么不是平衡二叉树呢？**

我们知道，在内存比在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块，但是平衡二叉树可是每个节点只存储一个键值和数据的，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。

**那为什么不是B树而是B+树呢？**

1）B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。

2）B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。

### 7. 聚集索引与非聚集索引的区别 ###

*  一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。
 *  聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
 *  索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
 *  聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；

**何时使用聚集索引或非聚集索引？**

![9f921778a922049d5cd8def7078c349b.png][]

### 8. limit 1000000 加载很慢的话，你是怎么解决的呢？ ###

#### 方案一：如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit ####

select id，name from employee where id>1000000 limit 10.

#### 方案二：在业务允许的情况下限制页数： ####

建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。

#### 方案三：order by + 索引（id为索引） ####

select id，name from employee order by id  limit 1000000，10

#### 方案四：利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联） ####

SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id

### 9. 如何选择合适的分布式主键方案呢？ ###

*  数据库自增长序列或字段。
 *  UUID。
 *  Redis生成ID
 *  Twitter的snowflake算法
 *  利用zookeeper生成唯一ID
 *  MongoDB的ObjectId

### 10. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？ ###

*  读未提交（Read Uncommitted）
 *  读已提交（Read Committed）
 *  可重复读（Repeatable Read）
 *  串行化（Serializable）

Mysql默认的事务隔离级别是可重复读(Repeatable Read)

### 11. 什么是幻读，脏读，不可重复读呢？ ###

*  事务A、B交替执行，事务A被事务B干扰到了，因为事务A读取到事务B未提交的数据,这就是**脏读**
 *  在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是**不可重复读**。
 *  事务A查询一个范围的结果集，另一个并发事务B往这个范围中插入/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不一样了，这就是**幻读**。

### 12. 在高并发情况下，如何做到安全的修改同一行数据？ ###

要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案~

#### 使用悲观锁 ####

悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之门外~ 比如，可以使用select…for update ~

select * from User where name=‘jay’ for update

以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。本次事务提交之前，别的线程都无法修改这些记录。

#### 使用乐观锁 ####

乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

### 13. 数据库的乐观锁和悲观锁。 ###

#### 悲观锁： ####

悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。

![e149e00778e0305ae1b3a357f29206cb.png][]

#### 乐观锁： ####

乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同时对数据进行变动。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

![ebdbd56cab8b825e37ab500568972b6d.png][]

#### 14. SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义。 ####

*  show status 命令了解各种 sql 的执行频率
 *  通过慢查询日志定位那些执行效率较低的 sql 语句
 *  explain 分析低效 sql 的执行计划（这点非常重要，日常开发中用它分析Sql，会大大降低Sql导致的线上事故）

### 15. select for update有什么含义，会锁表还是锁行还是其他。 ###

#### select for update 含义 ####

select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。

没用索引/主键的话就是表锁，否则就是是行锁。

# 最后 #

无论是哪家公司，都很重视基础，大厂更加重视技术的深度和广度，面试是一个双向选择的过程，不要抱着畏惧的心态去面试，不利于自己的发挥。同时看中的应该不止薪资，还要看你是不是真的喜欢这家公司，是不是能真的得到锻炼。

针对以上面试技术点，我在这里也做一些资料分享，希望能更好的帮助到大家。

**[戳这里免费领取以下资料][Link 1]**

![150001a528f86f16b83ffe4476a5adf8.png][]

![878bfec40cc8a7fdae4380374dca3e72.png][]

![b5c927eb5d91d4729166aeedc4a7c10c.png][]

还要看你是不是真的喜欢这家公司，是不是能真的得到锻炼。

针对以上面试技术点，我在这里也做一些资料分享，希望能更好的帮助到大家。

**[戳这里免费领取以下资料][Link 1]**

\[外链图片转存中…(img-jecQ4r1l-1622800483446)\]

\[外链图片转存中…(img-oPCiV50B-1622800483448)\]

\[外链图片转存中…(img-Flw7567B-1622800483449)\]

[892bcf819368e8f98c8128b038594a77.png]: /images/20210720/ad3d0b16d5944ab3ae791e25c5605c98.png
[9f921778a922049d5cd8def7078c349b.png]: /images/20210720/760a98565b6f4225a3fed53423388e60.png
[e149e00778e0305ae1b3a357f29206cb.png]: /images/20210720/f69ed3241e7f4bd392a476587ae2c539.png
[ebdbd56cab8b825e37ab500568972b6d.png]: /images/20210720/4373d9a32ae94b06b863b3ccbd48a47c.png
[Link 1]: https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB
[150001a528f86f16b83ffe4476a5adf8.png]: /images/20210720/292a95b3a4c348b183244aff68ba2efb.png
[878bfec40cc8a7fdae4380374dca3e72.png]: /images/20210720/cbafe4d181ea4e15ac107b8d2c6c4c67.png
[b5c927eb5d91d4729166aeedc4a7c10c.png]: /images/20210720/c87f46d94bb0481e925ce52c32c40d06.png