mysql、redis面试相关知识

1、mysql引擎

1. innodb：
   支持事务；
   支持索引；
   行锁；
2. myisam：
   不支持事务；
   不支持索引；
   表锁；
3. memory：
   对表大小有要求，数据量不能过大；
   处理速度快，但是安全性不高；
   MySQL中使用该引擎作为临时表，存放查询的中间结果；
4. archive：
   适合存储大量独立的、作为历史记录的数据，适合存储归档数据，如记录日志信息；
   提供了压缩功能，拥有高效的插入速度；
   不支持索引，查询性能较差一些；
   本身不是事务安全的；

2、mysql、redis使用哪种数据结构存储

mysql的innodb：b+树
mysql的myisam：b树

redis：红黑树

3、redis持久化存储（rdb、rof、混合持久化）

RDB：
优点：

• 经过压缩的二进制文件，占用空间很小，适合用于做备份；

• RDB 非常适用于灾难恢复，它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心；

• RDB 可以最大化 redis 的性能。父进程在保存 RDB 文件时唯一要做的就是 fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快；

缺点：

• RDB 在服务器故障时容易造成数据的丢失。

• RDB 保存时使用 fork 子进程进行数据的持久化，如果数据比较大的话，fork 可能会非常耗时，造成 Redis 停止处理服务N毫秒，甚至更长。

• Linux fork 子进程采用的是 copy-on-write 的方式。在 Redis 执行 RDB 持久化期间，如果 client 写入数据很频繁，那么将增加 Redis 占用的内存，最坏情况下，内存的占用将达到原先的2倍。刚 fork 时，主进程和子进程共享内存，但是随着主进程需要处理写操作，主进程需要将修改的页面拷贝一份出来，然后进行修改。极端情况下，如果所有的页面都被修改，则此时的内存占用是原先的2倍。

AOF：
优点：

• AOF 比 RDB可靠。你可以设置不同的 fsync 策略：no、everysec 和 always。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

• AOF文件是一个纯追加的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等）， 我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。

• 当 AOF文件太大时，Redis 会自动在后台进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写是绝对安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。

• AOF 文件有序地保存了对数据库执行的所有写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

缺点：

• 对于相同的数据集，AOF 文件的大小一般会比 RDB 文件大。

• 根据所使用的 fsync 策略，AOF 的速度可能会比 RDB 慢。通常 fsync 设置为每秒一次就能获得比较高的性能，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快。

• AOF 在过去曾经发生过这样的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug ） 。虽然这种 bug 在 AOF 文件中并不常见， 但是相较而言， RDB 几乎是不可能出现这种 bug 的。

混合持久化（暂无介绍）