【问题标题】:Database Design Performance of Many Table vs One Table多表与一张表的数据库设计性能
【发布时间】:2017-01-09 22:53:42
【问题描述】:

假设我有一个 ANIMAL 表,

CREATE TYPE VALID_ANIMAL AS ENUM ('Dog', 'Cat', 'Pig');
CREATE TABLE IF NOT EXISTS ANIMAL (
  animal_type VALID_ANIMAL,
  name        TEXT,
  owner       TEXT,
  .... many more common fields
);

因此,如果此表非常大,有 100 万行混合了“Dog”、“Cat”和“Pig”,是否会减慢搜索包含“Dog”的行的速度?

或者我应该有 3 个单独的表,分别命名为 DOG、CAT 和 PIG。这样数据就已经分开了,在查询 DOG 时,我只会去 dog 表。我担心一张大表在搜索“Dog”时可能会出现过滤掉“Cat”和“Pig”的性能问题。

【问题讨论】:

  • 这不是你应该做的数据库设计。您不必担心关系数据设计期间的行数。
  • 我只是好奇哪种方法会更快,所以我可以在应用程序中实现:)
  • 首先正确进行数据设计会更快,然后您将有更多可行的选项进行性能调整。
  • @RBarryYoung hi 所以根据设计观点,一张桌子是好的设计?
  • 我想这取决于您要触发什么查询,如果您同时触发对狗、猫和其他动物的查询,那么一个表会更好,原因之一是您的查询不需要连接但如果您分别查询动物的数据,那么不同的表是有意义的

标签: sql database postgresql database-design


【解决方案1】:

如果您有 1,000,000 行,那么每个动物可能有大约 300,000 行。您真的无法加快获取三行之一的查询。

严格来说,这并不正确。你可以做两件事。您可以按动物类型对表格进行分区。一百万行表在分区的低端。

另一件事是您可以在动物类型上创建聚集索引。在 MySQL 中,您可以通过将具有动物类型的复合主键声明为第一个指定键来做到这一点。

【讨论】:

  • 感谢您的回复!您能否详细解释“您真的无法加快获取三行之一的查询”。查询名称为“Foo”的“Dog”的大表(假设我会得到 5000 条狗)与查询名称为“Foo”的 Dog 表相比,哪个会更快
  • @Zanko 。 . .使用name 上的索引,速度将基本相同。
  • 非常感谢!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-05
  • 2013-09-29
  • 2012-02-19
  • 1970-01-01
  • 2014-04-29
相关资源
最近更新 更多