Mysql 数据库表结构优化

我正在尽量减少MySQL数据库的查询时间。这是我的情况。。。。我有以下表格：

• 存储表
  • ID字段
  • 名称字段
  • 位置字段
• 架子桌
  • ID字段
  • 存储ID字段
  • 名称字段
• 货架
  • ID字段
  • 货架标识字段
  • 项目ID字段
  • 项目名称字段
  • 位置字段
  • 评级字段

当我的程序（内置于C++中）启动时，它会将数据库中的所有存储加载到它们自己的对象中，并将它们存储在一个列表中

然后，它将数据库中的所有工具架存储到它们自己的对象中（每个商店可以有0到10个工具架），并将它们分配给相应的商店对象

最后，它将DB中的所有ShelfItem加载到它们自己的对象中，并将它们指定给相应的Shelf对象。每个工具架对象可以容纳0到130个工具架

然后当软件关闭时，它会重新保存所有的商店，然后是所有的货架，然后是所有的货架

我的问题是，可能会同时发生大量的保存和加载请求，这会导致查询时间比预期的要长。因此，我正试图对此进行一些优化

将shelfs和shelf项序列化为字符串并将其作为列存储在Stores表中，读/写速度会更快吗

结果将使Stores表看起来更像这样

• 存储表
  • ID字段
  • 名称字段
  • 位置字段
  • 序列化的shelfs字段（将包含两个shelf及其ShelfItems）

---

这（以字符串形式存储）通常是一个坏主意，或者当它是一个好主意时——使用NoSQL解决方案往往是一个更好的主意。我不知道你的应用程序是如何使用的，但大概不需要一次考虑所有的ShelfItems，然后你通常会考虑延迟加载，只在需要时加载项目。这种方法的中间点是预加载经常使用的项目或批次。这可以通过使用缓存来实现，但这会带来一系列其他考虑，例如何时刷新数据。您还应该只更新已更改的项目，以防止某些保存…

关系数据库的整个意义在于，您不必一次写入所有内容。只写已经改变的东西，并且只写它们真正改变的时候。对于如何加载或保存，没有选择。我唯一能做的改变就是我上面提到的。。。我只是想知道它是否会更快。所以你只能修改数据库而不能修改应用程序？这真的没有意义，因为您必须更改应用程序，以便在建议的更改中使用新的数据库模式？系统已经在使用缓存，并且只有在需要更新时才进行更新。我想说的是，优化需要在DB级别上，，，，，你字面上说：“当软件关闭时，它会重新保存所有的商店，然后是所有的货架，然后是所有的货架。”。不，您提议的数据库更改不会提高性能，事实上这是一个坏主意。如果您的应用程序已经使用了缓存，并且只保存了更改过的字段，那么为什么您认为在DB中合并列会更快呢？因为对于上述图表的较小版本，我们有一个类似的系统，而瓶颈只有在我们达到这一点时才会发生。