MySQL 最佳字段内存使用

Question

我面临的情况是，我正在尝试以最佳方式（就内存存储使用而言）来表示不同商店在不同时间点持有的库存。设置如下：

表格：商店

一个表，它是不同商店的列表：

• 商店 ID (PK)
• 商店名称
• ...其他详细信息

表格：库存

• 库存编号 (PK)
• 股票名称
• ...其他详细信息

表格：Store Stock Holdings

• 商店 ID
• 库存编号
• 日期
• 数量

（Store Id、Stock Id 和 Date 作为联合主键，Store Id 和 Stock Id 作为外键）

另外，我想将持有的股票存储为 json 字符串：

表格：Store Stock Holdings

• 商店 ID
• 日期
• 持股

例如，假设商店 1 在 2011 年 1 月 1 日有 50 个柠檬（代码 = 1）、100 个橙子（代码 = 2）和 20 个芒果（= 3），那么这三个设置将表示为：

选项 1：

Store Id, Stock Id, Date, Quantity

1 , 1, 2011-01-01, 50
1 , 2, 2011-01-01, 100
1 , 3, 2011-01-01, 20

选项 2：

Store Id, Date, Stock Holdings

1 , 1, 2011-01-01, \{1,50;2,100;3,20\}

选项 3：

将通过将选项 1 拆分为两个表来减少存储日期的复制，如下所示：

Index, Store Id, Date

1, 1, 2011-01-01

Index, Stock Id, Stock Holdings

1, 1, 50
1, 2, 100
1, 3, 20

所以问题是：

1. 对于不同的实现，我的速度和存储考虑因素是什么。我的想法是选项 3 和选项 2 可能是更好的选择，因为没有复制日期信息。

2. 对于选项 2，存储 JSON 字符串的内存是否是动态分配的？我的意思是 JSON 字符串可能非常大，因此需要允许它。那么新条目会占用总分配量还是仅占用基于 JSON 字符串所需的内存量？我的理解是使用 varchar 会动态分配内存。你会建议使用 varchar 吗？

Answer 1

MySQL 是一个关系型数据库管理系统，因此被设计为对规范化的关系型数据进行操作。

这意味着它不能有效地索引JSON 字符串：你不能说，通过stockId 有效地搜索，运行按股票分组的聚合查询等。

您唯一能够快速完成的事情就是在给定商店 ID 的情况下检索所有商店内容（无论您是否需要）。

所以选项2 仅在您使用MySQL 作为纯键值存储时才可行。市场上有许多更适合此目的的系统。

至于在选项1 和选项3 之间进行选择，后者只是将自然复合键(storeId, date) 替换为代理项（index）。

整数比INT + DATE 组合的大小更短，因此当此选项更好时可能会出现边缘情况（特别是如果您的日期很少且每个日期的条目非常多，并且您不需要查询所有商店或给定股票的所有日期）。但是，将所有内容保存在一个表中可以让您在 storeId、stockId 和 date 的任意组合上创建复合索引，这可能对性能至关重要。

为了帮助您在两者之间进行选择，我们需要知道您将运行哪种查询，但 option 1（storeId、stockId 和 date 在一张表中）绝对是模型选择。