大数据开发面试经验总结1（慢慢学习补充）

字节一面

1.介绍项目的时候，把自己项目中的数据特点说一下，比如多少字段，多少数据量，大约什么类型，以及输出的‘数据类型和要求，中间进行哪些操作，一步步怎么进行的

2.会问到数据库索引

数据库索引：官方介绍索引是帮助MySQL高效获取数据的数据结构。更通俗的说，数据库索引好比是一本书 前面的目录，能加快数据库的查询速度。 一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往是存储在磁盘上的文件中 的（可能存储在单独的索引文件中，也可能和数据一起存储在数据文件中）。 我们通常所说的索引，包括聚集索引、覆盖索引、组合索引、前缀索引、唯一索引等，没有特 别说明，默认都是使用B+树结构组织（多路搜索树，并不一定是二叉的）的索引。

在项目中用到什么索引，这个以后做了项目之后再补充

3.会一些索引题，怎么命中的索引

最左匹配原则 

1)、先定位该sql的查询条件，有哪些，哪些是等值的，哪些是范围的条件。 

2)、等值的条件去命中索引最左边的一个字段，然后依次从左往右命中，范围的放在最后。

详细的步骤这里不写了，但是联合索引那块还是没有搞懂

4.数据库的锁机制

传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做 操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

5.乐观锁和悲观锁

乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。 乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。 在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候 都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

乐观锁的实现方式：1）使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。

2）java中的Compare and Swap即CAS ，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。 CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。

CAS缺点： 1. ABA问题：比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出 A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行 CAS操作发现内存中仍然是A，然后one操作成功。尽管线程one的CAS操作成功，但可能存在 潜藏的问题。从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决 ABA问题。 2. 循环时间长开销大：对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大， 从而浪费更多的CPU资源，效率低于synchronized。 3. 只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。

6.怎么实现数据修改在x<2的，而不修改x>2的，怎么加锁（暂时空着，不会）

7.索引的底层实现

先明白B树，B+树是什么东西，以及他们各自的索引

B树，又称多路平衡树，B树中所有结点的孩子个数的最大值称为B树的阶，通常用m表示。一棵m阶B树或为空树，或为满足如下特性的m叉树：

1）树中每个结点至多有m棵子树，即至多含有m-1个关键字。

2）若根节点不是终端结点，则至少有两棵子树。

3）除根节点外的所有非叶节点至少有m/2向上取整棵子树，即至少含有m/2向上取整-1个关键字。

4）所有的叶节点都出现在同一层次上，并且不带信息（可以视为外部结点或类似于折半查找判定树的查找失败结点，实际上这些结点不存在，指向这些结点的指针为空）

1、MyISAM 索引实现

索引的引擎在如下，在这里用MyISAM引擎来进行底层实现，MyISAM 引擎使用 B+Tree 作为索引结构,叶节点的 data 域存放的是数据记录的地址。主索引与辅助索引的区别（对某列建立索引）：在结构上没有任何区别,只是主索引要求 key 是唯一的,而辅助索引的 key 可以重复主索引（聚集索引）也就是表的主键，是建表时指定的，并且是唯一的辅助索引（非聚集索引）是对表有其他需要可以添加创建的。

下图是 MyISAM 索引的原理图：

大概就是B树的索引结构,但我也不懂为什么他说是B+树的索引结构

索引过程：

MyISAM 中索引检索的算法为首先按照 B+Tree 搜索算法搜索索引,如果指定的 Key 存在,则取出其data 域的值,然后以 data 域的值为地址,读取相应数据记录。

2、 InnoDB索引实现

1、InnoDB 的数据文件本身就是索引文件。从上文知道,MyISAM 索引文件和数据文件是分离的,索引文件仅保存数据记录的地址。

而在InnoDB 中,表数据文件本身就是按 B+Tree 组织的一个索引结构,这棵树的叶点data 域保存了完整的数据记录。这个索引的 key 是数据表的主键,因此 InnoDB 表数据文件本身就是主索引。

InnoDB 要求表必须有主键(MyISAM 可以没有),如果没有显式指定,则 MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL 自动为 InnoDB 表生成一个隐含字段作为主键,类型为长整形

2、第二个与 MyISAM 索引的不同是 InnoDB 的辅助索引 data 域存储相应记录主键的值而不是地址。换句话说,InnoDB 的所有辅助索引都引用主键作为 data 域。

辅助索引搜索需要检索两遍索引:首先检索辅助索引获得主键,然后用主键到主索引中检索获得记录。

3、主键过长导致：

因为所有辅助索引都引用主索引,过长的主索引会令辅助索引变得过大。

8.数据库的引擎有哪些，怎么实现的（上面问题已经大致解答）

InnoDB,MyISAM,Memory,Merge,Example,Archive,csv,blackhole,federated

MYISAM：全表锁，拥有较高的执行速度，不支持事务，不支持外键，并发性能差，占用空间 相对较小，对事务完整性没有要求，以select、insert为主的应用基本上可以使用这引擎

Innodb:行级锁，提供了具有提交、回滚和崩溃回复能力的事务安全，支持自动增长列，支持 外键约束，并发能力强，占用空间是MYISAM的2.5倍，处理效率相对会差一些

Memory:全表锁，存储在内容中，速度快，但会占用和数据量成正比的内存空间且数据在 mysql重启时会丢失，默认使用HASH索引，检索效率非常高，但不适用于精确查找，主要用于 那些内容变化不频繁的代码表

MERGE：是一组MYISAM表的组合

注：InnoDB与MyISAM的区别

1.InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

3. InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。 但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该 过大，因为主键太大，其他索引也都会很大。而MyISAM是非聚集索引，数据文件是分离的， 索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

4. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用 一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

5. Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；

9.平衡二叉树、搜索树

平衡二叉树我记得是左子树和右子树的高度相差不能超过1，具体调平看之前王道笔记。

二叉搜索树是满足顺序性的二叉树

任一节点r的左右子树中，所有的节点（若存在）均不大于（不小于）r 为回避边界情况，暂定假设所有节点不想等，因此可以简化为 任意节点r的左（右）子树中，所有的节点（若存在）均小于（大于）r

从本章开始，讨论的重点将逐步转向查找技术，实际上在之前的章节已经就此做过一些讨论，比如在vector和list等结果中，已经给出了对应的ADT结构，但是遗憾的是这种接口的效率无法令人满意。

比如vector向量模版，针对无序和有序向量的查找提供了find()和search（）接口。前者的实现策略是将目标对象与向量存放的对象逐个对比，硬刺需要O(n)时间，后者利用二分查找策略可以确保O(logN)时间内完成单次查找，但是一旦向量本身需要修改，无论是插入还是删除，在最坏情况下每次需要O（n）的时间。

所以对于线性结构来说，既要求对象集合的组成可以高效率地 动态调整，同时也要求能够高效率查找，lInear data structure很难胜任，那么高效率的动态修改和高效率的静态查找能否同时兼顾，如有可能又应该采用什么样的数据结构？

之后两章希望逐步了解其中的故事，涉及到的数据结构种类比较多，按照基本和高级两章分别进行讲解

本章首先介绍树式查找的总体构思、基本算法以及数据结构，通过对二分查找策略的抽象与推广来定义并实现二叉搜索树（Binary search tree)结构，虽然在最坏情况下渐进时间复杂度与之前并无实质性改变，但是这给出来一种基于半线性的树形结构。 之后提出理想平衡和适度平衡等概念，并相应引入和实现AVL树这种典型的平衡二叉搜索树（Balanced binary search tree)，借助精巧的平衡调整算法，AVL树可以保证即使在最坏情况下，单次动态修改和静态查找也可以在O(logN)的时间内完成，在之后的选择中给出balanced m-way search trees

10.操作系统的一些内容（之后再慢慢补充）

11.问计算机网络知道些什么（之后再补充）

12.反问，问对面试官的建议