java面试小结——数据库

MySql与Oracle的几个主要区别

一、并发性

并发性是oltp数据库最重要的特性，但并发涉及到资源的获取、共享与锁定。
·
mysql:
mysql以表级锁为主，对资源锁定的粒度很大，如果一个session对一个表加锁时间过长，会让其他session无法更新此表中的数据。
虽然InnoDB引擎的表可以用行级锁，但这个行级锁的机制依赖于表的索引，如果表没有索引，或者sql语句没有使用索引，那么仍然使用表级锁。
·
oracle:
oracle使用行级锁，对资源锁定的粒度要小很多，只是锁定sql需要的资源，并且加锁是在数据库中的数据行上，不依赖与索引。所以oracle对并发性的支持要好很多。

二、一致性

oracle:
oracle支持serializable的隔离级别，可以实现最高级别的读一致性。每个session提交后其他session才能看到提交的更改。oracle通过在undo表空间中构造多版本数据块来实现读一致性，
每个session查询时，如果对应的数据块发生变化，oracle会在undo表空间中为这个session构造它查询时的旧的数据块。
·
mysql:
mysql没有类似oracle的构造多版本数据块的机制，只支持read commited的隔离级别。一个session读取数据时，其他session不能更改数据，但可以在表最后插入数据。
session更新数据时，要加上排它锁，其他session无法访问数据。

三、事务

oracle很早就完全支持事务。
·
mysql在innodb存储引擎的行级锁的情况下才支持事务。

四、数据持久性

oracle 保证提交的数据均可恢复，因为oracle把提交的sql操作线写入了在线联机日志文件中，保持到了磁盘上，如果出现数据库或主机异常重启，重启后oracle可以考联机在线日志恢复客户提交的数据。
·
mysql默认提交sql语句，但如果更新过程中出现db或主机重启的问题，也许会丢失数据。

五、提交方式

oracle默认不自动提交，需要用户手动提交。
·
mysql默认是自动提交。

六、逻辑备份

oracle逻辑备份时不锁定数据，且备份的数据是一致的。
·
mysql逻辑备份时要锁定数据，才能保证备份的数据是一致的，影响业务正常的dml使用。

七、热备份

oracle有成熟的热备工具rman，热备时，不影响用户使用数据库。即使备份的数据库不一致，也可以在恢复时通过归档日志和联机重做日志进行一致的回复。
·
mysql: myisam的引擎，用mysql自带的mysqlhostcopy热备时，需要给表加读锁，影响dml操作。
innodb的引擎，它会备份innodb的表和索引，但是不会备份.frm文件。用ibbackup备份时，会有一个日志文件记录备份期间的数据变化，因此可以不用锁表，不影响其他用户使用数据库。但此工具是收费的。
innobackup是结合ibbackup使用的一个脚本，他会协助对.frm文件的备份。

八、sql语句的扩展和灵活性

mysql对sql语句有很多非常实用而方便的扩展，比如limit功能，insert可以一次插入多行数据，select某些管理数据可以不加from。
·
oracle在这方面感觉更加稳重传统一些。

九、复制

oracle:既有推或拉式的传统数据复制，也有dataguard的双机或多机容灾机制，主库出现问题是，可以自动切换备库到主库，但配置管理较复杂。
·
mysql:复制服务器配置简单，但主库出问题时，丛库有可能丢失一定的数据。且需要手工切换丛库到主库。

十、性能诊断

oracle有各种成熟的性能诊断调优工具，能实现很多自动分析、诊断功能。比如awr、addm、sqltrace、tkproof等
·
mysql的诊断调优方法较少，主要有慢查询日志。

十一、权限与安全

mysql的用户与主机有关，感觉没有什么意义，另外更容易被仿冒主机及ip有可乘之机。
·
oracle的权限与安全概念比较传统，中规中矩。

十二、分区表和分区索引

oracle的分区表和分区索引功能很成熟，可以提高用户访问db的体验。
·
mysql的分区表还不太成熟稳定。

十三、管理工具

oracle有多种成熟的命令行、图形界面、web管理工具，还有很多第三方的管理工具，管理极其方便高效。
·
mysql管理工具较少，在linux下的管理工具的安装有时要安装额外的包（phpmyadmin， etc)，有一定复杂性。

来源：http://blog.csdn.net/c332472988/article/details/52804078

---

复合索引

复合索引就是一个索引创建在两个列 或者多个列上。在搜索时，当两个或者多个列作为一个关键值时，最好在这些列上创建复合索引。当创建复合索引时，应该考虑这些规则：最多可以把16个列合并 成一个单独的复合索引，构成复合索引的列的总长度不能超过900字节，也就是说复合列的长度不能太长；在复合索引中，所有的列必须来自同一个表中，不能跨 表建立复合列；在复合索引中，列的排列顺序是非常重要的，因此要认真排列列的顺序，原则上，应该首先定义最唯一的列，例如在（COL1，COL2）上的索 引与在（COL2，COL1）上的索引是不相同的，因为两个索引的列的顺序不同；为了使查询优化器使用复合索引，查询语句中的WHERE子句必须参考复合 索引中第一个列；当表中有多个关键列时，复合索引是非常有用的；使用复合索引可以提高查询性能，减少在一个表中所创建的索引数量

---

非关系型数据库和关系型数据库区别，优势比较？

非关系型数据库的优势：
1. 性能NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。
2. 可扩展性同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。

关系型数据库的优势：
1. 复杂查询可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
2. 事务支持使得对于安全性能很高的数据访问要求得以实现。

关系型数据库和非关系型数据库在使用场景上差别比较大，所以并不存在孰强孰弱，只有结合自身的业务特点才能发挥出这两类数据库的优势，下面说说这两类数据库的一些特点：
首先一般非关系型数据库是基于CAP模型，而传统的关系型数据库是基于ACID模型的

1. 数据存储结构：
   首先关系型数据库一般都有固定的表结构，并且需要通过DDL语句来修改表结构，不是很容易进行扩展，而非关系型数据库的存储机制就有很多了，比如基于文档的，K-V键值对的，还有基于图的等，对于数据的格式十分灵活没有固定的表结构，方便扩展，因此如果业务的数据结构并不是固定的或者经常变动比较大的，那么非关系型数据库是个好的选择
2. 可扩展性
   传统的关系型数据库给人一种横向扩展难，不好对数据进行分片等，而一些非关系型数据库则原生就支持数据的水平扩展(比如mongodb的sharding机制)，并且这可能也是很多NoSQL的一大卖点，其实象Mysql这种关系型数据库的水平扩展也并不是难，即使NoSQL水平扩展容易但对于向跨分片进行joins这种场景都没有什么太好的解决办法，不管是关系型还是非关系型数据库，解决水平扩展或者跨分片Joins这种场景，在应用层和数据库层中间加一层中间件来做数据处理也许是个好的办法
3. 数据一致性
   非关系型数据库一般强调的是数据最终一致性，而不没有像ACID一样强调数据的强一致性，从非关系型数据库中读到的有可能还是处于一个中间态的数据，因此如果你的业务对于数据的一致性要求很高，那么非关系型数据库并不一个很好的选择，非关系型数据库可能更多的偏向于OLAP场景，而关系型数据库更多偏向于OLTP场景

学习网址;http://blog.csdn.net/longxingzhiwen/article/details/53896702 关系型和非关系型数据库的区别?
http://blog.csdn.net/oChangWen/article/details/53423301 关系型数据库和非关系型数据库区别、oracle与mysql的区别

---

使用redis有哪些好处？

(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

(2) 支持丰富数据类型，支持string，list，set，sorted set，hash

(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行

(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

redis相比memcached有哪些优势？

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

redis常见性能问题和解决方案：

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…

这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：

voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

Memcache与Redis的区别都有哪些？

1) 存储方式

Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。

Redis有部份存在硬盘上，这样能保证数据的持久性。

2) 数据支持类型

Memcache对数据类型支持相对简单。

Redis有复杂的数据类型。

3) 使用底层模型不同

它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。

Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4）value大小

redis最大可以达到1GB，而memcache只有1MB

Redis 常见的性能问题都有哪些？如何解决？

1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

redis 最适合的场景

Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1 、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2 、Redis支持数据的备份，即master-slave模式的数据备份。
3 、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
（1）、会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

（2）、全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。

此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

（3）、队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。

（4），排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

（5）、发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。

Redis提供的所有特性中，我感觉这个是喜欢的人最少的一个，虽然它为用户提供如果此多功能。

来源：http://blog.csdn.net/yajlv/article/details/73467865

---

redis主从是如何实现同步的

第一次、Slave向Master同步的实现是：
Slave向Master发出同步请求（发送sync命令），Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的写命令转发给Slave，初次同步完成。
第二次、以及以后的同步实现是：
Master将变量的快照直接实时依次发送给各个Slave。
但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。

redis主从中的哨兵是做什么的

Redis的哨兵模式就是对redis系统进行实时的监控，其主要功能有下面两点

1.监测主数据库和从数据库是否正常运行。

2.当我们的主数据库出现故障的时候，可以自动将从数据库转换为主数据库，实现自动的切换

如何提高redis命中率

在获取数据的时候,会判断key是否存在,如果存在keyspace_hits++,如果不存在keyspace_misses,命中率用这两个数就可以算出

提高redis命中率的方法：

①缓存的设计（粒度和策略）

缓存的粒度越小，命中率会越高，

②缓存容量

缓存的容量有限，则容易引起缓存失效和被淘汰

③其他因素

当缓存节点发生故障时，需要避免缓存失效并最大程度降低影响

谈谈redis的LRU算法

LRU即最近最久未使用，当内存达到限制时，Redis 具体的回收策略是通过 maxmemory-policy 配置项配置的。由以下多个选项：
noenviction：不清除数据，只是返回错误，这样会导致浪费掉更多的内存，对大多数写命令（DEL 命令和其他的少数命令例外）
allkeys-lru：从所有的数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰，以供新数据使用
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰，以供新数据使用
allkeys-random：从所有数据集（server.db[i].dict）中任意选择数据淘汰，以供新数据使用
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰，以供新数据使用
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰，以供新数据使用
当 cache 中没有符合清除条件的 key 时，回收策略 volatile-lru, volatile-random 和volatile-ttl 将会和 策略 noeviction 一样返回错误。选择正确的回收策略是很重要的，取决于你的应用程序的访问模式。

回收的过程是这么运作的非常的重要：
①一个客户端运行一个新命令，添加了新数据。
②Redis 检查内存使用情况，如果大于 maxmemory 限制，根据策略来回收键。
③一个新的命令被执行，如此等等

Redis的LRU算法不是一个严格的LRU实现。这意味着Redis不能选择最佳候选键来回收，也就是最久未被访问的那些键。

相反，Redis 会尝试执行一个近似的LRU算法，通过采样一小部分键，然后在采样键中回收最适合(拥有最久访问时间)的那个。

redis的数据类型？

五种 string 、hash、set、list、zset，我们实际项目中比较常用的是string，hash

来源：http://blog.csdn.net/sunqingzhong44/article/details/73866263

---

请用Redis和任意语言实现一段恶意登录保护的代码，限制1小时内每用户Id最多只能登录5次。具体登录函数或功能用空函数即可，不用详细写出。

用列表实现:列表中每个元素代表登陆时间,只要最后的第5次登陆时间和现在时间差不超过1小时就禁止登陆.用Python写的代码如下：

#!/usr/bin/env python3

import redis  
import sys  
import time

r = redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0)  
try:  
    id = sys.argv[1]
except:  
    print(‘input argument error’)
    sys.exit(0)

if r.llen(id) >= 5 and time.time() – float(r.lindex(id, 4)) <= 3600:  
    print(“you are forbidden logining”)
else:  
    print(‘you are allowed to login’)
    r.lpush(id, time.time())
    # login_func()

---

Redis和Memcached的异同。

Memcached

1. 可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS；
2. 只支持简单的key/value数据结构，不像Redis可以支持丰富的数据类型。
3. 无法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据全部丢失。
4. 无法进行数据同步，不能将MC中的数据迁移到其他MC实例中。
5. Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差异较大时会造成内存利用率降低，
   并引发低利用率时依然出现踢出等问题。需要用户注重value设计。

Redis

1. 支持多种数据结构，如string、 list、hash、set、zset等；
2. 支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段；
3. 支持通过Replication进行数据复制，通过master-slave机制，可以实时进行数据的同步复制来实现HA；
4. 单线程请求，所有命令串行执行，并发情况下不需要考虑数据一致性问题，但性能受限于CPU性能，故单实例CPU最高才可能达到5-6wQPS每秒；
5. 支持pub/sub消息订阅机制，可以用来进行消息订阅与通知；
6. Redis在string类型上会消耗较多内存，可以使用hash表压缩存储以降低内存耗用。

---

Redis作为分布式缓存可能会存在哪些问题，怎么解决？

• 缓存穿透预防及优化：缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中；缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义；解决方法：缓存空对象和布隆过滤器拦截；
• 缓存雪崩问题优化：由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况；预防和解决缓存雪崩问题，可以从以下三个方面进行着手：保证缓存层服务高可用性、依赖隔离组件为后端限流并降级、提前演练。
• 缓存热点key重建优化：开发人员使用缓存和过期时间的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但如果热点Key和重建缓存耗时两个问题同时出现，可能就会对应用造成致命的危害；解决方法：互斥锁（只允许一个线程重建缓存）、永远不过期（唯一不足的就是重构缓存期间会出现数据不一致的情况）。

---

学习网址

http://blog.csdn.net/wulantian/article/details/46724611 redis 数据类型详解 以及 redis适用场景场合

---

抽奖

http://blog.csdn.net/z69183787/article/details/52389113 抽奖-算法
http://blog.csdn.net/z69183787/article/details/52389126 抽奖-高并发

流程：

• 初始化-把抽奖活动和奖品数据都放到redis缓存
• 当有用户参与抽奖活动就从redis把奖品列表取出来调用之前提到的算法
• 如果中奖更新redis数据，同时提交任务到线程池，更新数据库中奖品的数量同时保存抽奖结果到数据库

为了利用redis的decr功能来保证修改奖品余量的一致性，每一个奖品的余量需要在redis中单独做缓存

效果：

对于每一个用户ID，把当前抽奖的次数记录到redis，每次抽奖之前到redis取数据检查，如果存在相应记录直接返回结果（在最一开始就拦截非法请求）

中奖的时候使用多线程异步处理结果，目的有两个：

• 让http请求尽快返回结果，释放连接数
• 达到任务队列的效果，减轻数据库压力