这是一个创建于 2096 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前用 MySQL 存储 Web 日志时想到的一个问题。
有些字段例如 method，总共才 GET、POST 等几种可能，因此能用 enum 类型。但像域名、路径这类，虽然存在大量重复的值，但由于是不固定的，显然不能用 enum 而只能存原始值。
不知数据库底层对于大量重复的值，会不会只存储一份，然后通过引用的方式存储？
还是只能通过人工来优化？比如新建一个表专门存放 <id, 域名>，然后原始表只存 id，这样倒是能让重复字段只占极小的字节，不过这个过程应该在数据库底层实现比较好吧。
有些字段例如 method，总共才 GET、POST 等几种可能，因此能用 enum 类型。但像域名、路径这类，虽然存在大量重复的值，但由于是不固定的，显然不能用 enum 而只能存原始值。
不知数据库底层对于大量重复的值，会不会只存储一份，然后通过引用的方式存储？
还是只能通过人工来优化？比如新建一个表专门存放 <id, 域名>，然后原始表只存 id，这样倒是能让重复字段只占极小的字节，不过这个过程应该在数据库底层实现比较好吧。
 |
1
xiangyuecn 2019-03-25 17:37:10 +08:00
我对 UA 就是这样干的，另外建了一个表做映射，大量的 UA 是一致的而且还长，就是多了一个转换步骤麻烦了点。
|
 |
2
saulshao 2019-03-25 18:24:45 +08:00
似乎不会用引用的方式存储，至少我接触过的数据库没有给我这种印象。即基本上表占用空间的增长可以根据字符串长度 X 行数算出来......
|
 |
3
YaYamilk 2019-03-25 18:35:41 +08:00
看业务需求，一种是你说的做映射，另外一种是重复字段存一条，非重复部分作为字符串存然后取的时候分隔。如果还有请告诉我，我也想知道这个
|
 |
4
RainyH2O 2019-03-25 18:51:40 +08:00
NoSQL
|
 |
5
opengps 2019-03-25 18:56:26 +08:00
这个情况，感觉没必要非得去省这部分空间。web 日志不是需要太高效率读出的数据，于其花大精力优化，不如直接多分几个表存下，读取时候麻烦点而已
|
 |
6
sun1991 2019-03-25 21:27:21 +08:00
从空间上来说, 浪费这一点点磁盘空间九牛一毛, 不值得花精力.
如果是查询返回数据量太大导致性能问题的话, 考虑垂直切分表, 把不太常用的划分到另外的表里去, 有需要时再链接. |
Select Language