面试-数据库与nosql

迈不过友情╰ 2022-04-02 10:46 208阅读 0赞

# mysql #

## mysql面试题 ##

**1. 各个数据库存储引擎区别**  
mysql的存储引擎是针对表进行设置的，一个库的不同表可以设置不同的存储引擎， mysql默认支持多种存储引擎，以适用不同领域的数据库应用需要，主要的几个数据库引 擎如下：  
**MyISAM存储引擎**  
5.5之前默认的存储引擎，不支持事务、不支持外键，表级锁，内存和硬盘空间占用率 低，其优势是访问速度快，对事务完整性没有要求，以select、insert为主的应用基本上都 可以使用这个引擎；  
**InnoDB存储引擎**  
5.5之后默认的存储引擎，提供了具有提交、回滚和奔溃恢复能力的事务安全，支持外  
键并提供了行级锁，其劣势在于写的处理效率相对较低，并且会占用更多的磁盘空间以保 留数据和索引  
**MEMORY存储引擎**  
使用存于内存中的内容来创建表，MEMORY类型的表数据存于内存访问非常的快，默 认使用HASH索引，一旦数据库服务重启或关闭，表中的数据就会丢失；  
**MERGE存储引擎**  
MERGE存储引擎是一组MyISAM表组合，这些MyISAM表结构完全相同。MERGE表 本身没有数据，对MERGE表的CRUD操作都是通过内部的MyISAM表进行的  
**2. 提高sql语句效率的技巧**  
**大批量插入数据**  
大批量数据插入空表，可将表设置成为MyISAM，并通过disable keys将唯一索引 关闭；  
大批量数据插入非空Innodb表，可采取如下措施提高效率：  
1.导入数据时按照主键顺序排列  
2.导入数据前使用set UNIQUE\_CHECKS=0,关闭唯一性校验，导入后恢复  
3.如果使用了自动提交，建议在导入前执行SET AUTOCOMMIT=0，关闭自动 提交，导入后恢复;  
**优化INSERT语句**  
1.尽量使用多个值表的insert语句，降低连接、关闭的消耗  
2.将索引文件和数据文件分在不同的磁盘上存放  
3.从一个文本文件装入一个表时，使用LOAD DATA INFLIE ,比一般的insert语句快 20倍；  
**查询优化**  
1.尽量减少额外的排序，通过索引直接返回有序数据；where条件和order by使用相 同的索引，并且order by的顺序与索引顺序相同，并且order by的字段都是升序或 者都是降序；  
2.尽量只选择必要的字段，提高sql性能；  
3.能用关联查询的不要用子查询  
4.对于包含or的查询语句，如果要利用索引，则or之间的每个条件都必须用到索引， 否则应该考虑增加索引；  
5.优化分页  
1.在索引上完成排序分页的操作，然后根据主键关联回原表查询所需的其他列  
select [a.name][], a.description from person a innner join(select pid from person order by birthdat limit 50,5)  
先根据主键索引分页了然后再关联;  
2.把limit查询转换为某个位置的查询  
select [a.name][], a.description from person where pid>7788 order by birthday limit 50,5>//升序排序应该是大于  
**注意不使用索引的情况**  
1.如果MySQL估计使用索引比全表扫描更慢，则不使用索引  
2.用or分隔开的条件，如果or前的条件中的列有索引，而后面的列没有索引，那么涉 及到的索引都不会被用到  
3.复合索引，如果索引列不是复合索引的第一部分，则不使用索引（即不符合最左 前缀;  
4.如果like是以’%’开始的，则该列上的索引不会被使用  
5. 如果列为字符串，则where条件中必须将字符常量值加引号，否则即使该列上存在 索引，也不会被使用;  
6. not in 、 not exists 、 （<> 不等于 ！=）这些操作符不走索引  
7. 不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系 统将可能无法正确使用索引；  
**3. 怎么样做执行计划分析**  
通过explain命令获取mysql如何执行select语句的信息，包括在select语句执行过程中表 如何连接和连接的顺序；explain分析后的结果解析:  
**1.select\_type**  
查询的类型，主要是用于区分普通查询、联合查询、子查询等复杂的查询  
SIMPLE(simple)：简单的select查询，查询中不包含子查询或者union  
PRIMARY(primary)：查询中包含任何复杂的子部分，最外层查询则被标记为primary  
SUBQUERY(subquery):在select 或 where列表中包含了子查询  
UNION(union):若第二个select出现在union之后，则被标记为union；若union包含在from 子句的子查询中，外层select将被标记为derived  
**2.type**  
访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：  
system > const > eq\_ref > ref > range > index > ALL  
**一般来说，好的sql查询至少达到range级别，最好能达到ref；**  
**system：** 表只有一行记录（等于系统表），这是const类型的特例，平时不会出现， 可以忽略不计  
**const：** 表示通过索引一次就找到了，const用于比较primary key 或者 unique索引  
**eq\_ref：** 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配（1对1）；  
**ref：** 非唯一性索引扫描，返回匹配某个单独值的所有行。  
**range：** 索引范围扫描  
**index：** 索引全扫描；  
**ALL：** 全表扫描；  
**3.possible\_keys**  
查询涉及到的字段上存在索引，则该索引将被列出，但不一定被查询实际使用  
**4.key**  
实际使用的索引，如果为NULL，则没有使用索引。  
**5.key\_len**  
表示索引中使用的字节数，查询中使用的索引的长度（最大可能长度），并非实 际使用长度，理论上长度越短越好;  
**6.ref**  
显示索引的哪些列  
**7.rows**  
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数  
**8.Extra**  
不适合在其他字段中显示，但是十分重要的额外信息  
***优化目标 Tips:***  
1.根据需求建立索引  
2.每个查询都要使用索引以提高查询效率,至少达到range级别，最好能达到ref；  
3.追求key\_len和rows最小；

## mysql复制的原理 ##

Mysql的复制原理大致如下：  
1.主库在数据提交时会把数据变更作为事件记录在二进制日志文件Binlog中；可通过  
sync\_binlog控制binlog日志刷新到磁盘的频率；  
2.主库推送二进制日志文件binlog中的事件到从库的中继日志Relay Log，之后从库  
根据中继日志RelayLog重做数据变更操作，通过逻辑复制达到主从库的数据一致；  
3.MySQL通过3个线程来完成主从库之间的数据同步，其中binlog dump线程跑在主  
库上，I/O线程和sql线程跑在从库上。 当从库启动复制时，首先创建I/O线程连接主库，主库随后创建binlog dump线程读 取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志 replay log中去，之后从库上的sql线程读取中继日志中更新的数据库事件并应用；  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70]

# mongodb #

## mongodb与mysql的区别？ ##

mongodb的本质还是一个数据库产品，3.0以上版本其稳定性和健壮性有很大提 升。它与mysql的区别在于它不会遵循一些约束，比如：sql标准、ACID属性，表 结构等。其主要特性如下  
 面向集合文档的存储：适合存储Bson（json的扩展）形式的数据；  
 格式自由，数据格式不固定，生产环境下修改结构都可以不影响程序运行；  
 强大的查询语句，面向对象的查询语言，基本覆盖sql语言所有能力；  
 完整的索引支持，支持查询计划；  
 支持复制和自动故障转移；  
 支持二进制数据及大型对象（文件）的高效存储；  
 使用分片集群提升系统扩展性；  
 使用内存映射存储引擎，把磁盘的IO操作转换成为内存的操作；

## mongoDB主要使用在什么应用场景？ ##

MongoDB 的应用已经渗透到各个领域，比如游戏、物流、电商、内容管理、社交、 物联网、视频直播等，以下是几个实际的应用案例：  
 游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的 形式存储，方便查询、更新  
 物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。  
 社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理 位置索引实现附近的人、地点等功能  
 物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息， 并对这些信息进行多维度的分析  
 视频直播，使用 MongoDB 存储用户信息、礼物信息等  
 …

## 3. 怎么样做mongodb查询优化 ##

**第一步 找出慢速查询**  
1.开启内置的查询分析器,记录读写操作效率 : db.setProfilingLevel(n,\{m\}),n的取值可选0,1,2；  
 0是默认值表示不记录；  
 1表示记录慢速操作,如果值为1,m必须赋值单位为ms,用于定义慢速查询时间的阈值；  
 2表示记录所有的读写操作；  
例如:db.setProfilingLevel(1,300)  
2. 查询监控结果  
监控结果保存在一个特殊的盖子集合system.profile里,这个集合分配了128kb的空间,要确保监控分 析数据不会消耗太多的系统性资源；盖子集合维护了自然的插入顺序,可以使用KaTeX parse error: Expected '\}', got 'EOF' at end of input: ….find().sort(\{'natural’:-1\}).limit(5)

**第二步 分析慢速查询**  
找出慢速查询的原因比较棘手,原因可能有多个:应用程序设计不合理、不正确的数据模型、硬件配置问 题,缺少索引等；接下来对于缺少索引的情况进行分析:  
**使用explain分析慢速查询**  
例如:db.orders.find(\{‘price’:\{’$lt’:2000\}\}).explain(‘executionStats’) explain的入参可选值为:  
 “queryPlanner” 是默认值,表示仅仅展示执行计划信息；  
 “executionStats” 表示展示执行计划信息同时展示被选中的执行计划的执行情况信息；  
 “allPlansExecution” 表示展示执行计划信息,并展示被选中的执行计划的执行情况信息,还展 示备选的执行计划的执行情况信息；  
**第三步 解读explain结果**  
queryPlanner（执行计划描述）  
winningPlan（被选中的执行计划）  
stage（可选项:COLLSCAN 没有走索引；IXSCAN使用了索引） rejectedPlans(候选的执行计划)  
executionStats(执行情况描述)  
nReturned （返回的文档个数）  
executionTimeMillis（执行时间ms）  
totalKeysExamined （检查的索引键值个数） totalDocsExamined （检查的文档个数）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 1]

## mongodb的索引注意事项？ ##

1.  索引很有用,但是它也是有成本的——它占内存,让写入变慢；
2.  mongoDB通常在一次查询里使用一个索引,所以多个字段的查询或者排序需要复合索引才能  
    更加高效；
3.  复合索引的顺序非常重要
4.  在生成环境构建索引往往开销很大,时间也不可以接受,在数据量庞大之前尽量进行查询优化和  
    构建索引；
5.  避免昂贵的查询,使用查询分析器记录那些开销很大的查询便于问题排查；
6.  通过减少扫描文档数量来优化查询,使用explai对开销大的查询进行分析并优化；
7.  索引是用来查询小范围数据的，不适合使用索引的情况：  
     每次查询都需要返回大部分数据的文档，避免使用索引  
     写比读多

## mongodb是怎么实现高可用 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 2]

# redis #

## 1.结合项目经验，说下 redis 应用场景 ##

 缓存：合理使用缓存加快数据访问速度，降低后端数据源压力  排行榜：按照热度排名，按照发布时间排行，主要用到列表和有序集合  
 计数器应用：视频网站播放数，网站浏览数，使用redis计数  
 社交网络：赞、踩、粉丝、下拉刷新  
 消息队列：发布和订阅

## 2. redis 支持数据类型？各有什么特点 ##

 String（字符串） string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片 或者序列化的对象 。string类型是Redis最基本的数据类型，一个redis中字符串value 最多可以是512M  
 Hash（哈希） Redis hash 是一个键值对集合。Redis hash是一个string类型的field和value的映 射表，hash特别适合用于存储对象。类似Java里面的Map<String,Object>  
 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列 表的头部（左边）或者尾部（右边），它的底层实际是个链表  
 Set（集合） Redis的Set是string类型的无序集合。它是通过HashTable实现实现的，  
 zset(sorted set：有序集合) Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的 是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进 行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。

## 有什么持久化策略？各有什么特点 ##

**策略：支持RDB和AOF两种持久化机制，可以避免因进程退出造成数据丢失，特点如下：**  
 RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，持久化结束后， 用这个临时文件替换上次持久化的文件，达到数据恢复。 优点在于使用单独子进程来 进行持久化，主进程不会进行任何IO操作，保证了redis的高性能；缺点在于RDB是间 隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种 方式更适合数据要求不严谨的时候；有手动触发和自动触发，手动触发有save和 bgsave两命令 ；  
 save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大 会造成长时间阻塞，线上环境不建议用它  
 bgsave命令：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时 间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如 果没有开启AOF持久化，自动执行bgsave; 显然bgsave是对save的优化

 AOF：针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写 入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操 作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作 过程  
**开启：** redis.conf设置：appendonly yes (默认不开启，为no)  
\*\*默认文件名： \*\*appendfilename “appendonly.aof”

## 介绍下哨兵机制 ##

redis sentinel是一个分布式架构，其中包含了若干个sentinal节点和Redis节点，每个 sentinel节点会对数据节点和sentinel节点进行监控，当它发现节点不可达是，会对节点做 下线标识。如果大部分sentinal节点认为主节点不可达，sentinal节点之间会进行“协商” ， 选举出来一个sentinal节点完成故障转义，并同时把这个故障通知到应用方；  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 3]

## 介绍 redis 集群方案？以及其原理 ##

RedisCluster是redis的分布式解决方案，在3.0版本后推出的方案，有效地解决 了Redis分布式的需求，当遇到单机内存、并发等瓶颈时，可使用此方案来解决这些 问题，一个 redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个数据都属 于这16384个哈希槽中的一个。集群使用公式(CRC16\[key\]&16383)函数来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 5]

## redis能做读写分离吗？同步策略是怎么实现的 ##

redis提供了主从复制和哨兵机制来提高redis服务的健壮性和高可用，但是从严 格意义上来讲，redis并没有实现读写分离，主从复制架构中，主节点用于响应  
读写请求，从节点用于数据备份，如果需要实现读从从节点读，应用需要对客  
户端进行改造；但在真实场景下一般不需要做此方案，读写分离主要应用在磁 盘IO比较大的场景，而redis是缓存级别的  
**同步策略：**  
redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制  
a) 全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）  
b) 部分复制：网络出现问题，从节占再次连主时，主节点补发缺少的数据，每 次数据增加同步

[a.name]: http://a.name
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70]: /images/20220402/f65997366e754a659fd0c5013cd8ef11.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 1]: /images/20220402/7f634b57b9fe4fccbbec2b4c47c5f331.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 2]: /images/20220402/d1601cd649224e10a85df759220cafde.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 3]: /images/20220402/1eb24e33e84346fc8f4791d5d86ee42d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 4]: /images/20220402/0b2498ef25724768ad741af288585c23.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODE1MTIy_size_16_color_FFFFFF_t_70 5]: /images/20220402/ec0493e4f4ad49b79a84542bed536e9c.png