面试-数据库与nosql

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线程读取中继日志中更新的数据库事件并应用；

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 （检查的文档个数）

mongodb的索引注意事项？

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

mongodb是怎么实现高可用

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
 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节点完成故障转义，并同时把这个故障通知到应用方；

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

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

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

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