Redis查询那些事儿，怎么查又怎么用才顺手

Redis查询那些事儿，怎么查又怎么用才顺手

很多人把Redis当成一个简单的“缓存盒子”，但真要查得顺手、用得溜，还得摸清它的脾气，它不是像MySQL那样的表格数据库，你没法用SQL语句去“SELECT * FROM ... WHERE ...”，它的查询，本质上是“通过钥匙找对应的值”，钥匙就是那个key，值就是存放在里面的数据，第一要义就是：设计好你的钥匙（key），别乱起名，最好有个统一的格式，比如业务名:对象名:ID（像user:info:1001），这样一目了然，也方便管理,这是来自Redis官方最佳实践和无数开发者总结的经验。

查单个数据，最基本的就是GET命令，但前提是这个key存的是字符串，如果你存的是列表、哈希（hash）、集合这些，那就要用对应的命令，查哈希里的某个字段用HGET，查列表的一段元素用LRANGE。怎么查，取决于你当初怎么存，你不能用GET命令去取一个哈希结构的数据，那会报错,这就好比你不能用开门的钥匙去开抽屉。

想批量查多个key，可以用MGET命令，一次把多个key的值取回来，这比一个个GET要高效得多，减少了网络来回的时间,这是提升查询效率的一个小窍门。

但有时候，你可能会忘记某个key的全名，或者想找某一类key，Redis提供了基于模式的KEYS命令，比如KEYS user:*，就能找出所有以“user:”开头的key。千万要小心！ 在生产环境的大型数据库里，这个命令可能会阻塞其他操作，因为它会遍历所有key，导致服务短暂卡顿，根据Redis官方文档的明确警告，不建议在生产环境使用KEYS，那怎么办呢？更顺手的做法是使用SCAN命令，它像是一个游标，分批慢慢地扫，不会一下子堵死，对服务影响小，虽然用法稍微麻烦一点，但为了系统稳定,这是必须养成的习惯。

光会查还不够，用得“顺手”才是关键,这里有几个实实在在的建议：

1. 别把它当数据库：Redis的核心优势是速度，数据主要放在内存里，那些需要持久保存、不能丢的核心数据，别只放在Redis里，它应该是“缓存”或“临时工作区”，源头数据还得在MySQL这类数据库中,这是架构设计的基本常识。
2. 给数据设个“保质期”：用EXPIRE命令给key设置一个存活时间（TTL），很多临时数据，比如短信验证码、会话信息，用完就该自动消失，防止无用数据占满内存,这是内存管理的关键。
3. 选择合适的数据结构：这是Redis强大也最容易用错的地方，要存一个用户的个人信息（姓名、年龄、城市），用哈希（hash）就比用多个独立的key要高效得多，因为哈希可以一次取多个字段，而且更省内存，如果要存用户的好友列表，并且需要判断两人是否互为好友，集合（set）及其交集、并集操作就非常合适，根据Antirez（Redis创始人）在多篇博客中的阐述,正确使用数据结构是发挥Redis性能潜力的核心。
4. 活用管道（Pipeline）：如果你需要连续执行好几个命令，比如先GET再SET再INCR，不要一个个发，使用管道功能，可以把多个命令打包一次发送，大大减少网络延迟的总时间，这在需要连续操作时,效果提升非常明显。
5. 记得处理“没有”的情况：查询一个不存在的key，Redis会返回一个nil（空），你的程序代码里一定要处理好这种空值，避免出现异常，一个常见的顺手做法是：缓存查不到时，去数据库查，再回填到缓存，这也就是所谓的“缓存穿透”防护策略之一。

用顺Redis的查询，核心在于三点：心里有数（清楚数据结构）、手上有谱（使用合适的命令）、眼里有全局（考虑性能和稳定性），它不是个黑盒子，你按照它的规则来，它就能给你飞一样的速度，多在实际项目里练练，遇到内存满了、命令慢了之类的问题，查查文档和社区，慢慢就摸出门道了，它是一把锋利的瑞士军刀，用对了地方事半功倍,乱用则可能伤到自己。