Redis 键值设计问题？

作为一个小白，最近学习 Redis 缓存，心中有一个疑问：
假如在 mysql 中有一张 user 表用于保存用户的相关信息，表的主要字段有：id,username,password,email,nick,born,sex,status等等，现在想将 user 数据表中的所有数据全部缓存到 redis 数据库服务器中，请问 redis 的键值应该怎么设置呢？
是设为类似于：

user:[id]:username username_value
user:[id]:password password_value
user:[id]:email email_value
user:[id]:nick nick_value
...

还是设置为这样的形式呢：

user:[id] json_string
// json_string 是将一条用户信息的二维数组转换成json字符串

请问这两种形式哪种更好一些？哪种更节约内存一些？
希望各位大婶能解答一下我的疑问，对此表示万分感谢 =.=

回复内容：

作为一个小白，最近学习 Redis 缓存，心中有一个疑问：
假如在 mysql 中有一张 user 表用于保存用户的相关信息，表的主要字段有：id,username,password,email,nick,born,sex,status等等，现在想将 user 数据表中的所有数据全部缓存到 redis 数据库服务器中，请问 redis 的键值应该怎么设置呢？
是设为类似于：

user:[id]:username username_value
user:[id]:password password_value
user:[id]:email email_value
user:[id]:nick nick_value
...

还是设置为这样的形式呢：

user:[id] json_string
// json_string 是将一条用户信息的二维数组转换成json字符串

请问这两种形式哪种更好一些？哪种更节约内存一些？
希望各位大婶能解答一下我的疑问，对此表示万分感谢 =.=

存hash呢 用户id加个前缀设为key.比如user:888
hash集合里存常用用户属性.
另外不推荐全部用户无脑存缓存...这样有点本末倒置了..mysql会一脸懵逼的(要我何用←_←)...可以试着建立一个简单的热度统计 热用户存缓存

实在不行你就给hash设一个超时 每个用户信息第一次登录后就存一段时间....省的你劳神费心...

没研究过不同数据类型与内存的关系
从业务逻辑角度来讲，具体怎么设计存储看需求来定
比如缓存只是为了查询方便与信息展示，选第二种，mysql或者mongodb有相关操作再更新相应缓存
如果需要赋予登录、数据CURD等逻辑，同楼上，建议用hash，比如用HMSET，而非String类型

第一种好些吧，可以查到某一个，不需要编码

个人认为第1种比较好，方便单个获取和修改，如果是后者，每次获取或者修改单个属性都要获取全部，而且解析json获取其他序列化和反序列化的形式都会带来额外的消耗。
大部分情况，查询不需要查询所有的字段，修改的话，大部分都是只修改1个字段

我也碰到过数据表缓存的问题，我的解决方案是使用多种数据类型来配合完成

首先每条数据记录存成一个字典，用表名+ID然后md5加密后作为字典的名字
然后使用有序集合来存储每一条记录的字典名称与排序权重（我这里是有排序的需求，所以使用有序集合，否则的话使用集合或者列表都是可以的）

PS:redis中无法进行where查询之类的操作，所以如果有需要可以将在代码层进行筛选然后再按分类存进redis，比如我就是对数据进行筛选后存进几个不同的有序集合，然后再将这些有序集合的名字维护到一个列表中

后者。
操作方便，并且可以避免无底洞现象。

缓存无底洞现象

不要用json，看似取值方便，但是多处同时更新缓存数据的时候简直是不可描述。写程序没有方便不方便，只有你写的东西可不可靠。

没有必要全部缓存，比如性别就不需要，只有经常访问的才需要缓存。

redis下用json怎么说呢。。不是说不可能，只是没有充分利用redis的价值 开心就好

使用hash结构。推荐第二种，数据存缓存的第一个意义是加快浏览速度，而对一些会修改的数据我正常是多建一个缓存来存储要修改的数据，实际展示的数据会是正常缓存+修改缓存的数据。

一般业内的做法就是
值存储成二进制的形式,而不是字符串,这样是省内存的,效率也高,缺点就是通过redis-cli没法看明文,因为已经是二进制形式了
比如你这个
key=user:[id]
value=这个user对象转成的二进制形式

那么下次你用java读这个value后, 会自动转为你那个对象, 多简单, 不用一个一个属性set了

不过你要注意一旦涉及成这样,就无法通过user的其他属性进行搜索了,前提是你要了解你的业务, 如果有其他字段的搜索你要加一组其他的key value, 在nosql中数据冗余很常见

nosql都是这样, 写程序的一定要了解业务, 否则数据结构设计的会不好, 虽然nosql的使用门槛很低,但是设计门槛还是有的