5
我们生产环境key数量超过了20000了，在程序设置中只能设置20000，每次加载key都加载不完全，需要重新在手动加载全部，确实不方便。
Q
[qishibo/AnotherRedisDesktopManager]加载key的数量能否把上限提升或者去掉上限
A
回答
1
设计这个是为了防止key过多导致程序卡顿，也为了防止线上redis受到影响，不过很多人的需求都是要加载出全量key，看来需要重新审视一下了
你们实际key在什么量级，点加载全部的时候大概多久能加载出来呢
4
我觉得不加载全部key才是正确的，今天更新后发现居然增加了这个功能，要知道在线上执行scan这个命令，是有大问题的。我每次打开线上数据的时候都是小心翼翼的，特别是查找单个键的时候，一定优先点中精确查找，强烈建议作者设置默认搜索模式为精确查找。 这次增加的这个加载全部key我觉得太危险了，我已经准备换回老版本了。 因为人总是有失误手滑点错的时候，但线上可经不起这么折腾
8
我觉得不需要查找全部的键，想不到加载全部的键要干什么，这个软件之前的搜索已经很好用了，但是也很危险了，因为执行的是scan命令，我们的生产环境执行scan命令会瞬间把cpu打到90%以上。如果有很多人真的有这种加载全部键的需求， 可以在ui上做点功夫，把加载全部按钮做的小一点，点击的时候加一个二次确认的提示，提醒用户这是一个高危命令。再次建议搜索模式默认为精确搜索，有需要的话再手动开启模糊搜索，降低手误操作对线上环境产生影响的概率。感谢作者的辛苦付出！
3
我觉得不加载全部key才是正确的，今天更新后发现居然增加了这个功能，要知道在线上执行scan这个命令，是有大问题的。我每次打开线上数据的时候都是小心翼翼的，特别是查找单个键的时候，一定优先点中精确查找，强烈建议作者设置默认搜索模式为精确查找。 这次增加的这个加载全部key我觉得太危险了，我已经准备换回老版本了。 因为人总是有失误手滑点错的时候，但线上可经不起这么折腾
同意，刚升级了新版本，给我整麻了，我们线上key的数量大多都是千万以上级别的，打开直接就能卡死了，强烈建议改回加载数量限制
7
现在加载更多和加载全部是对整个DB的，能否针对列表中的某个key前缀进行加载更多和加载全部呀？ @qishibo