我有两张桌子，我经常加入。为了简化这一点，连接返回了我在另一个（复杂）查询中使用的一系列 ID，作为IN.
所以我一直这样做是为了取回特定的 ID。
需要明确的是，查询并不是非常慢。大约需要2分钟。但由于我通过网页调用此查询，因此延迟很明显。
作为一个具体的例子，假设我要加入的表是一个供应商表和一个包含供应商配备特定日期的仓库的表。基本上，我得到了在特定日期为特定仓库提供服务的供应商的 ID。
它本身的查询无法改进，因为它是两个索引表之间的简单连接，但由于存在日期范围，这使事情变得复杂。
我有以下想法，我不确定它是否有意义。
由于我正在查询的数据（尤其是以前的日期）没有改变，如果我创建另一个表，该表具有作为主键、我的 where 中的列和作为值的 ID 列表（逗号分隔），该怎么办。
这样，它是 1 行的简单 SELECT。
即这样我“预存储”了我需要的供应商ID。
我知道这甚至不是第一个正常的正式形式，但它有意义吗？还有另一种方法吗？
在没有更多了解您的应用程序的情况下，不可能说这是否是正确的方法 - 但是收集和考虑大量信息超出了这里的问题范围。
基本上，我得到了在特定日期为特定仓库提供服务的供应商的 ID。
虽然还不清楚为什么您实际上需要 2 个表，也不清楚非规范化数据是否会使结果查询更快，但需要注意的一点是，您的数据在捕获后不太可能发生变化，因此保持当前结构以及物化视图将具有最小的开销。您首先需要通过将子查询结果放入正确索引的表中来测试查询性能。如果您获得显着的性能优势，那么您需要考虑如何维护新表 - 您可以用新表上的视图替换现有表之一，还是保留原始表并将数据填充到通过批处理或触发器创建新表。
试一试看看有什么用并不难——你会得到比这里任何人都能给你的更好的答案。
作为一种非规范化设计来加速您拥有的特定类型的查询是有意义的。
虽然如果您的日期范围发生变化，它不会导致一组不同的 id 吗？
另一种方法是真正将非规范化条目视为键/值缓存中的条目，如 memcached 或 redis。将真实数据存储在规范化表中，并定期更新缓存的非规范化表格。
回复您的评论：
是的，通常将 id 列表存储在字符串中是违反关系数据库设计的。请参阅我对在数据库列中存储分隔列表真的那么糟糕吗？
但另一方面，非规范化在某些情况下是合理的，例如作为您经常运行的查询的优化。
请注意非规范化的缺点：数据完整性失败的风险、其他查询的性能不佳、限制轻松更新数据的能力等。