心疼楼主...还有这么多人说走全表，一定要坚持有自己的观点呀^_^特别是你觉得有足够的东西支撑观点的时候

这个查询毫无疑问（正常情况下）会走你的(c1, c2)索引，前提是你的表可能得不止有 id, c1, c2 这 3 个字段，理由是主键索引的每个页能够存放下的数据行比(c1, c2)索引每个页能存放下的数据行更少，如果扫描主键获取结果，需要扫过更多的数据页，如果扫(c1, c2)索引，尽管没有用上"索引"的查询特性，但是可以通过扫更少的页得到正确结果。

性能的差距 = 主键索引体积 vs (c1, c2)索引体积，当你的表字段越多，越大的时候，差距越明显；反例则是如果表只有 id, c1, c2 三个字段的时候，扫描的时间理论上应该是非常接近的，并且优化器在选择上两个索引都有可能选择使用

...大小写错了不觉得看起来很碍眼么。。。

@wangyanrui 哨兵仅仅是 Redis 高可用的方案之一，而 Cluster 是同时做了高性能和高可用的方案，并不是只是组集群发挥更高性能而已，所以~建议下次指点别人之前确认自己的理解是正确的，不然就，hhh 蛮尴尬^_^

@wangyanrui 你理解得不对，是不是以为 Redis Cluster 是几台机器组起来的集群，然而其实并不是，典型的架构是例如起 3 主 3 从的 Redis Cluster，这里面会包括有了当主节点挂掉的时候，从节点接替继续工作的 Feature，而不是挂了其中之一就挂掉，所以这两者是有可比性并且哨兵确实就是落后的。

多捞啊...书都不能拿纸笔写写画画了，我为啥还要买你这书

1 楼正解，BloomFilter 处理超大数据量天然优势

@ClericPy 为什么要 ignore missing imports...

再安利最近写的 Redis 6.0 一些新功能的实现的文章：

Redis 6.0 ACL 基于 Bitmap 实现： https://blog.2014bduck.com/archives/343
Redis 6.0 多线程 IO 的实现： https://blog.2014bduck.com/archives/326

文章在 V2EX 上也能找到~不过安利博客大概可以流量+1

我是 小黄鸭 @Shopee ^_^

@hello2060 拿纸写完拍照更麻烦呀，人家现在这个时间问，肯定是因为疫情远程面试，不然谁买板子

@b821025551b 是不是有啥文字表达的误会 2333 我看 youtube 上的 up 主（放心我看的不是印度的小哥）也是这样年的呀 steam

想深入了解的话，github 上 pingcap 的一个 awesome database 的 repo （名字大概有点偏差）

@AyoCross 个人认为因为简单才符合 redis 各项功能设计的理念

@index90 单元测试覆盖率达到 100%印象中好像并不是什么推荐的实践？不过不太记得出处了，大意就是强制要求 100%实际上好像，比如说其实说明业务代码可能有一些 edge case 没有覆盖到的情况下就容易测试覆盖率 100%，当业务代码对各种边界条件处理都很完善的时候，想要 100%就很难了

是否 TCP 连接建立之后，所有的传输都必定抵达，必定能够组合回原来的内容？

@whileFalse 400GB 内存成本不是无脑开的，而且 qps 并不太高，为什么一定要将钱砸进去，不选择其他更好的方案。当然您也可以坚持有钱什么都能做的理念开够 400 内存的集群

第一种情况需要做 1 主多从，架设负载均衡将 QPS 摊到各台机器

第二种情况数据太多了，内存放不下的，但是如果成本足够的话使用去中心化的 Redis Cluster 处理，其实更好的方案应该是不使用 Redis，内存代价太高了

建议了解一下 redis-cell，现成的东西不要造轮子了

@tingyunsay 小项目去重应该直接 set()精确, 大项目才应该用 BloomFilter ?