这是一个创建于 2472 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前用 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