2020 Java面试题最新(九数据存储篇)

对于数据存储,数据库问题也有很多,列出一些大厂数据库的规范,以及一些面试官可能问到的问题

1.大厂MySQL规范

基础规范

• 表存储引擎必须使用 InnoDB

• 表字符集默认使用 utf8，必要时候使用 utf8mb4
  1.通用，无乱码风险，汉字 3 字节，英文 1 字节
  2.utf8mb4 是 utf8 的超集，有存储 4 字节例如表情符号时，使用它

• 禁止使用存储过程，视图，触发器，Event
  1.对数据库性能影响较大，互联网业务，能让站点层和服务层干的事情，不要交到数据库层
  调试，排错，迁移都比较困难，扩展性较差

• 禁止在数据库中存储大文件，例如照片，可以将大文件存储在对象存储系统，数据库中存储路径

• 禁止在线上环境做数据库压力测试

• 测试，开发，线上数据库环境必须隔离

命名规范

• 库名，表名，列名必须用小写，采用下划线分隔
  abc，Abc，ABC 都是给自己埋坑

• 库名，表名，列名必须见名知义，长度不要超过 32 字符
  tmp，wushan 谁 TM 知道这些库是干嘛的

• 库备份必须以 bak 为前缀，以日期为后缀

• 从库必须以 -s 为后缀

• 备库必须以 -ss 为后缀

表设计规范

• 单实例表个数必须控制在 2000 个以内
• 单表分表个数必须控制在 1024 个以内
• 表必须有主键，推荐使用 UNSIGNED 整数为主键
• 禁止使用外键，如果要保证完整性，应由应用程式实现
• 建议将大字段，访问频度低的字段拆分到单独的表中存储，分离冷热数据

列设计规范

• 根据业务区分使用 tinyint/int/bigint，分别会占用 1/4/8 字节
• 根据业务区分使用 char/varchar
• 必须把字段定义为 NOT NULL 并设默认值
• 使用 INT UNSIGNED 存储 IPv4 ，不要用 char(15)
• 使用 varchar(20) 存储手机号，不要使用整数
• 使用 TINYINT 来代替 ENUM

SQL 规范

• 禁止使用 select *，只获取必要字段
• insert 必须指定字段，禁止使用 insert into T values()
• 隐式类型转换会使索引失效，导致全表扫描
• 禁止在 where 条件列使用函数或者表达式
• 禁止负向查询以及 % 开头的模糊查询
• 禁止大表 JOIN 和子查询

2.说说MySQL 索引使用的注意事项

• 索引不会包含有 NULL 的列 只要列中包含有 NULL 值，都将不会被包含在索引中，复合索引中只要有一列含有 NULL 值，那么这一列对于此符合索引就是无效的
• 使用短索引 对串列进行索引，如果可以就应该指定一个前缀长度
• 不要在列上进行运算
• 不使用 NOT IN 、<>、！=操作，但 < , <= ，= ，> , >= , BETWEEN , IN 是可以用到索引的
• 索引要建立在经常进行select操作的字段上 这是因为，如果这些列很少用到，那么有无索引并不能明显改变查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求
• 索引要建立在值比较唯一的字段上
• 在 where 和 join 中出现的列需要建立索引
• where 的查询条件里有不等号 (where column != …) , MySql 将无法使用索引

说说反模式设计

简单的来说，反模式是指在对经常面对的问题经常使用的低效，不良，或者有待优化的设计模式/方法。甚至，反模式也可以是一种错误的开发思想/理念。在这里我举一个最简单的例子：在面向对象设计/编程中，有一条很重要的原则， 单一责任原则(Single responsibility principle)。其中心思想就是对于一个模块，或者一个类来说，这个模块或者这个类应该只对系统/软件的一个功能负责，而且该责任应该被该类完全封装起来。当开发人员需要修改系统的某个功能，这个模块/类是最主要的修改地方。相对应的一个反模式就是上帝类(God Class)，通常来说，这个类里面控制了很多其他的类，同时也依赖其他很多类。整个类不光负责自己的主要单一功能，而且还负责了其他很多功能，包括一些辅助功能。很多维护老程序的开发人员们可能都遇过这种类，一个类里有几千行的代码，有很多功能，但是责任不明确单一。单元测试程序也变复杂无比。维护/修改这个类的时间要远远超出其他类的时间。很多时候，形成这种情况并不是开发人员故意的。很多情况下主要是由于随着系统的年限，需求的变化，项目的资源压力，项目组人员流动，系统结构的变化而导致某些原先小型的，符合单一原则类慢慢的变的臃肿起来。最后当这个类变成了维护的噩梦(特别是原先熟悉的开发人员离职后)，重构该类就变成了一个不容易的工程

说说分库与分表设计

垂直分表

垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中。在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎

垂直分库

垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。系统层面的“服务化”拆分操作，能够解决业务系统层面的耦合和性能瓶颈，有利于系统的扩展维护。而数据库层面的拆分，道理也是相通的。与服务的“治理”和“降级”机制类似，我们也能对不同业务类型的数据进行“分级”管理、维护、监控、扩展等。

众所周知，数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段

水平分表

水平分表也称为横向分表，比较容易理解，就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这样来降低单表数据量，优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分。水平分表，能够降低单表的数据量，一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中，所以库级别还是会有IO瓶颈。所以，一般不建议采用这种做法

水平分库

水平分库分表与上面讲到的水平分表的思想相同，唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多大型互联网公司所选择的做法。某种意义上来讲，有些系统中使用的“冷热数据分离”（将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上，通常默认只提供热点数据的查询），也是类似的实践。在高并发和海量数据的场景下，分库分表能够有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入的硬件成本也会更高。同时，这也会带来一些复杂的技术问题和挑战（例如：跨分片的复杂查询，跨分片事务等）

3.说说MySQL 遇到的死锁问题

产生死锁的四个必要条件：

1. 互斥条件：一个资源每次只能被一个进程使用。
2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺
4. 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系

这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。 下列方法有助于最大限度地降低死锁：

1. 按同一顺序访问对象。
2. 避免事务中的用户交互。
3. 保持事务简短并在一个批处理中。
4. 使用低隔离级别。
5. 使用绑定连接。

4.数据库索引的意义

数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 BTree 及其变种 B+Tree

5.说说聚集索引与非聚集索引的区别

• 聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个
• 聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续
• 集索引：物理存储按照索引排序；聚集索引是一种索引组织形式，索引的键值逻辑顺序决定了表数据行的物理存储顺序
• 非聚集索引：物理存储不按照索引排序；非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引，不影响整个表的物理存储顺序
• 索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块

6.如何选择合适的数据存储方案

关系型数据库 MySQL

MySQL 是一个最流行的关系型数据库，在互联网产品中应用比较广泛。一般情况下，MySQL 数据库是选择的第一方案，基本上有 80% ~ 90% 的场景都是基于 MySQL 数据库的。因为，需要关系型数据库进行管理，此外，业务存在许多事务性的操作，需要保证事务的强一致性。同时，可能还存在一些复杂的 SQL 的查询。值得注意的是，前期尽量减少表的联合查询，便于后期数据量增大的情况下，做数据库的分库分表

内存数据库 Redis

随着数据量的增长，MySQL 已经满足不了大型互联网类应用的需求。因此，Redis 基于内存存储数据，可以极大的提高查询性能，对产品在架构上很好的补充。例如，为了提高服务端接口的访问速度，尽可能将读频率高的热点数据存放在 Redis 中。这个是非常典型的以空间换时间的策略，使用更多的内存换取 CPU 资源，通过增加系统的内存消耗，来加快程序的运行速度。

在某些场景下，可以充分的利用 Redis 的特性，大大提高效率。这些场景包括缓存，会话缓存，时效性，访问频率，计数器，社交列表，记录用户判定信息，交集、并集和差集，热门列表与排行榜，最新动态等。

使用 Redis 做缓存的时候，需要考虑数据不一致与脏读、缓存更新机制、缓存可用性、缓存服务降级、缓存穿透、缓存预热等缓存使用问题

文档数据库 MongoDB

MongoDB 是对传统关系型数据库的补充，它非常适合高伸缩性的场景，它是可扩展性的表结构。基于这点，可以将预期范围内，表结构可能会不断扩展的 MySQL 表结构，通过 MongoDB 来存储，这就可以保证表结构的扩展性。

此外，日志系统数据量特别大，如果用 MongoDB 数据库存储这些数据，利用分片集群支持海量数据，同时使用聚集分析和 MapReduce 的能力，是个很好的选择。

MongoDB 还适合存储大尺寸的数据，GridFS 存储方案就是基于 MongoDB 的分布式文件存储系统

列族数据库 HBase

HBase 适合海量数据的存储与高性能实时查询，它是运行于 HDFS 文件系统之上，并且作为 MapReduce 分布式处理的目标数据库，以支撑离线分析型应用。在数据仓库、数据集市、商业智能等领域发挥了越来越多的作用，在数以千计的企业中支撑着大量的大数据分析场景的应用

全文搜索引擎 ElasticSearch

在一般情况下，关系型数据库的模糊查询，都是通过 like 的方式进行查询。其中，like “value%” 可以使用索引，但是对于 like “%value%” 这样的方式，执行全表查询，这在数据量小的表，不存在性能问题，但是对于海量数据，全表扫描是非常可怕的事情。ElasticSearch 作为一个建立在全文搜索引擎 Apache Lucene 基础上的实时的分布式搜索和分析引擎，适用于处理实时搜索应用场景。此外，使用 ElasticSearch 全文搜索引擎，还可以支持多词条查询、匹配度与权重、自动联想、拼写纠错等高级功能。因此，可以使用 ElasticSearch 作为关系型数据库全文搜索的功能补充，将要进行全文搜索的数据缓存一份到 ElasticSearch 上，达到处理复杂的业务与提高查询速度的目的。

ElasticSearch 不仅仅适用于搜索场景，还非常适合日志处理与分析的场景。著名的 ELK 日志处理方案，由 ElasticSearch、LogStash 和 KibAna 三个组件组成，包括了日志收集、聚合、多维度查询、可视化显示等

这一章节内容不少 ,许多也是我在网上找到的资源,择优而写的,如果哪一点有错误的希望大家帮忙指出,也希望可以帮到各位

前几期系列有心态篇,基础篇,集合篇,线程篇,锁机制篇,Spring框架篇,分布式篇,微服务篇

本系列总共所涉及Java基础,集合,线程,锁机制,spring框架,分布式,微服务,数据存储,缓存使用,消息队列,安全,性能调优,设计模式以及需求分析