我只是想看看其他人对这个问题的看法。我有一个项目,其中包含每个用户的大量独特信息。现在,鉴于没有冗余并且有大量用户 - 将数据拆分成更小的表会使其更快吗?
我确实尝试了一个包含 1000 个查询的测试,其中一个有 87 列,另一个只有登录信息单独存储。在一个我得到 1372 毫秒,另一个 879 毫秒;乍一看似乎更快,但可能有人比我有更多的经验并且可以就此发表他们的观点?
我只是想看看其他人对这个问题的看法。我有一个项目,其中包含每个用户的大量独特信息。现在,鉴于没有冗余并且有大量用户 - 将数据拆分成更小的表会使其更快吗?
我确实尝试了一个包含 1000 个查询的测试,其中一个有 87 列,另一个只有登录信息单独存储。在一个我得到 1372 毫秒,另一个 879 毫秒;乍一看似乎更快,但可能有人比我有更多的经验并且可以就此发表他们的观点?
在您的测试中,如果您使用“SELECT *”从大表和小表中查询以返回所有列,那么是的,当然较大的表需要更长的时间,因为它必须返回更多数据。但是,在生产应用程序中,应用程序中的查询应该是有针对性的,只返回您需要的列。
如果每个表都具有相同的索引和要过滤的数据,并且每个表都返回相同的选定列,则结果集可能会在大致相同的时间返回。但是,我应该补充一点,在考虑性能测试时,时间可能会产生很大的误导。数据库服务器有很多因素不断变化,与您正在运行的查询无关,但绝对会影响它们的运行时间。尝试查看逻辑读数,而不是时间作为衡量标准。
至于您的设计问题,无论哪种方式在技术上都是可行的。但是,您可能需要考虑需要多长时间访问特定数据才能帮助开发团队的其他成员。如果您有 20% 的列在 80% 的时间内被查询,您可能需要考虑将这些列放在自己的表中。这应该有助于避免新开发人员在您的团队中花费大量时间,因为他们必须筛选大量通常不重要的数据列来确定他们想要查询的内容。
此外,从物理设计的角度来看,如果成本是一个问题,您可以将需要频繁访问的 20% 表放在性能较高的磁盘驱动器上,而将 80% 的数据放在性能较低的磁盘驱动器上。