redis的keys命令類似於Mysql的like命令，無非就是模糊匹配相近的字元資料。
KEYS 的速度非常快，但在一個大的資料庫中使用它仍然可能造成效能問題，如果你需要從一個資料集中查詢特定的 key ，最好還是用 Redis 的集合結構(set)來代替，我們在實際生產環境中請求併發比較多的地方還是最好忽略掉，如果僅僅為我們開發人員所用到的地方，可以偷偷用一下。因為Keys會引發Redis鎖，並且增加Redis的CPU佔用，情況是很惡劣的，如果資料龐大的話可能需要幾秒或更長。
如果有這種需求的話可以自己對鍵值做索引，比如把各種鍵值存到不同的set裡面，分類建立索引，這樣就可以很快的得到資料，但是這樣也存在一個明顯的缺點，就是浪費寶貴的空間，要知道這可是記憶體空間啊，所以還是要合理考慮，當然也可以想辦法，比如對於有規律的鍵值，可以儲存他們的始末值等等。
雖然redis只提供了五種型別，但是用起來不一定就只有五種，比如string型別，你可以儲存任何你自己定義的型別，所以思想不能侷限，靈活的設定資料結構。還有就是雖然redis存取很快，但是正常生產環境，redis伺服器肯定和web伺服器不是在一起，有時候甚至是在不同的地區，所以網路通訊延遲就很重要了，所以要減少存取次數，一次存取完成更多的工作，否則你會發現做同樣的事redis還沒有關係型資料庫快，所以redis存的時候一定要有技巧，儘可能減少存取次數。
從redis的官方文件上看，2.8版本之後SCAN命令已經可用，允許使用遊標從keyspace中檢索鍵。對比KEYS命令，雖然SCAN無法一次性返回所有匹配結果，但是卻規避了阻塞系統這個高風險，從而也讓一些操作可以放在主節點上執行。
需要注意的是，SCAN 命令是一個基於遊標的迭代器。SCAN 命令每次被呼叫之後， 都會向使用者返回一個新的遊標，使用者在下次迭代時需要使用這個新遊標作為 SCAN 命令的遊標引數， 以此來延續之前的迭代過程。同時，使用SCAN，使用者還可以使用keyname模式和count選項對命令進行調整。SCAN相關命令還包括SSCAN 命令、HSCAN 命令和 ZSCAN 命令，分別用於集合、雜湊鍵及有續集等。
另一方面，使用redis的時候一定要注意控制key，對於key的命令要制定一個完善的方案，這樣才能對redis裡面的資料可控，避免出現沒用資料長時間佔據資料庫這種情況，也可以避免上面說的這種查詢鍵值的操作。
還可以看下這篇文章：https://blog.csdn.net/hcmony/article/details/78648368
KEYS 的速度非常快，但在一個大的資料庫中使用它仍然可能造成效能問題，如果你需要從一個資料集中查詢特定的 key ，你最好還是用 Redis 的集合結構(set)來代替