Redis默认数据库那些事儿，咱们到底能用几个库其实挺有意思的

说到Redis,很多人可能都知道它是一个速度飞快的内存数据库，常被用来做缓存，但你可能没太留意一个细节：Redis是支持多个数据库的，这事儿说起来还挺有意思的，因为它和我们平常理解的关系型数据库（比如MySQL里一个个独立的数据库）不太一样。

（来源：Redis官方文档关于SELECT命令和数据库数量的说明）

咱们来回答最直接的问题：Redis默认到底有多少个数据库？答案是16个，如果你从官网下载一个标准版本的Redis，不做任何配置修改，直接启动服务，它就会为你准备好16个逻辑上隔离的数据库，这些数据库用数字来标识，分别是0号到15号数据库，你刚连接上Redis的时候，默认就待在0号库。

（来源：Redis配置文件redis.conf中的databases 16配置项）

这个数量并不是固定的,它其实是可以调整的，在Redis的核心配置文件redis.conf里，你能找到一行配置叫databases 16，如果你觉得16个不够用，或者觉得太多占内存，你可以修改这个数字，然后重启Redis服务，在绝大多数情况下，大家都会沿用这个默认值。

下一个问题来了：这16个库，我们是怎么用的呢？Redis提供了一个非常简单的命令——SELECT，你在命令行里输入SELECT 1，就切换到了1号数据库；输入SELECT 15，就切换到了15号数据库，每个数据库都有自己的键值对空间，也就是说，你在0号库存一个叫name的键，值设为“张三”，然后切换到1号库，你再查name这个键，是找不到的，除非你也在1号库里设置过一个name键，这种隔离方式非常简单粗暴。

（来源：对Redis多数据库设计理念的普遍理解和社区讨论）

这种设计在早期看起来挺方便的,好像可以帮我们做一些简单的数据隔离，有人可能会想：我可以把测试环境的数据放在0号库，生产环境的数据放在1号库；或者把用户数据放一个库，商品数据放另一个库，听起来是个不错的主意，对吧？但为什么现在很多专家和最佳实践都不推荐你这么用呢？这里面的“有意思”之处就来了。

Redis的作者在设计这个多数据库功能时,更多的是为了提供一个轻量级的命名空间隔离，而不是像MySQL那样真正的、重量级的数据库，它存在几个挺明显的“坑”：

第一,这些数据库并不是完全独立的，它们共享同一个Redis进程的资源，这意味着，如果你在15号库里执行了一个超级耗时的命令，导致Redis被阻塞了，那么对不起，0到14号库的所有操作也都得跟着一起排队等着，谁也跑不了，一个库“发了高烧”，所有库都得“跟着量体温”。

第二,缺乏跨数据库的操作，Redis几乎没有提供任何命令可以让你在不同的数据库之间操作数据，你想把0号库的某个键移动到1号库？没办法直接用一条命令完成，你得先在自己程序里从0号库读出来，然后再写到1号库去，这增加了复杂性和出错的概率。

第三,对于集群模式不友好，这是最关键的一点，当你需要用到Redis集群（Cluster）模式来扩展性能和容量时，Redis的多个数据库功能就完全失效了，Redis集群模式只允许使用0号数据库，这是因为集群的核心是把数据分片（就是把数据切成小块）分布到不同的服务器上，它需要精确计算每个键应该存放在哪个位置，如果支持多个数据库，会让分片逻辑变得异常复杂甚至不可行，一旦你的业务增长，需要从单机Redis升级到集群模式，如果你之前把数据分散在了多个库，那迁移起来就会非常头疼。

（来源：Redis集群模式设计规范，明确只支持database 0）

正因为这些原因,现在社区里一种非常主流的看法和最佳实践是：就把Redis当成一个只有单个数据库（0号库）的服务来用，如果你需要做数据隔离，更推荐的做法是直接起多个Redis实例（也就是多开几个Redis服务器进程），每个实例用不同的端口号，这样每个实例才是真正意义上的资源隔离，一个实例出问题不会影响另一个，而且也完美支持集群化扩展，虽然这会多占用一点内存（因为每个实例都有自己独立的内存分配），但带来的清晰度和可靠性是值得的。

总结一下“Redis默认数据库那些事儿”：Redis默认给了我们16个数据库，这个数字可以改，用SELECT命令切换，它像是一个历史遗留的“小彩蛋”，初衷是好的，但在实际的大型应用或分布式场景下，它反而可能成为绊脚石，理解了它的这些特性和局限性，我们就能更好地做出选择：在简单小应用里，你可以按喜好使用多个库；但在严肃的生产环境中，老老实实地待在那个默认的0号库，或者直接使用多个Redis实例，往往是更明智、更面向未来的做法，这大概就是它“挺有意思”的地方——一个看似方便的功能，背后却藏着这么多需要考虑的细节。