提高性能的表布局（多查询 vs 单大查询）

Question

我有一个直截了当的问题。

我正在做一个使用 MySQL 的 Web 应用程序，我目前正在设计它。我只是有一个关于性能的小问题。

我想知道什么更有效：

场景 #1：

Table: Restaurant
    -Name
    -City
    -Province
    -Country
    -Continent

sql =~ select * from restaurant where id = something.

或

场景 #2：

Table: Restaurant   
    -Name
    -City
Table: City
    -Name
    -Province
Table: Province
    -Name
    -Country
Table: Country
    -Name
    -Continent
Table: Continent
   -Name

sql =~ [insert multiple sql queries that will output the name and the city,
        with the corresponding province, country, and continent]

从逻辑上讲，我认为场景 #1 更好（查询更少），但有些人向我发誓要不然。

Answer 1

没错，但问题是哪个选项性能更好。在这种情况下，毫无疑问：选项 #1 将执行得更好，因为查询不必与任何其他表进行 JOIN。 Randolph 确实有一个很好的观点，只要有可能，您就应该规范化您的数据库结构。

Answer 2

如果您没有数据库设计经验，我建议您始终使用规范化版本。在大多数情况下，这是正确的做法。在某些情况下，您可能希望对数据库进行非规范化，但是您应该确切地知道为什么要这样做。

请注意，在第二种情况下，它不是多个查询。这只是一个查询，所有表都连接在一起。例如：

SELECT *
FROM restaurant
    JOIN city ON city.id=restaurant.city
    JOIN province ON province.id=city.province
    ...

是的，写入需要更长的时间，但它比数据库中的数据不一致要好（维护非规范化的数据库要困难得多）。你也可以使用 ORM 为你做这些事情。

Answer 3

第二个选项是规范化结构，这意味着您的数据冗余更少，出错的机会更少等。我总是投票支持规范化数据，除非您遇到性能问题。

顺便说一句，SELECT * FROM [Table] 无论如何都不是好习惯。您需要输入列名。

Answer 4

谢谢你们的意见。 “规范化数据库设计”是这里的关键。我用谷歌搜索了它，快速阅读它，虽然它的性能有点差，但专业人士真的很值得。

再次感谢。 （顺便说一句，那真的很快！） http://en.wikipedia.org/wiki/Database_normalization

Wikipedia 指出非规范化具有更好的性能，但我认为我只是变得自大并认为我可以处理大型非规范化数据库。

我会坚持风险较小的方案。如果大便击中风扇，我将更换硬件 =)。

再次感谢各位。

Answer 5

如果您使用第一种方案，您会遇到空间使用增加的问题（对于所有重复的省、国家、大陆），如果您需要更改城市/国家的名称，则需要在所有行中更改它它被使用了。

为方便起见，我将使用第二种情况。我认为这两种场景之间不会有很大的性能差异（在第一种场景中，您只触摸一个表，但从磁盘读回更多数据，在第二种情况下，您从磁盘读取的数据较少，但从多个表中读取）。这真的取决于你那里有什么样的数据。

编辑：解释我上面的观点：如果你将所有数据保存在一个大表中，那么你需要实际从磁盘读取所有行，即使读取的大部分数据是相同的（即城市、省、国家、大陆）。即使 SQL 尽可能缓存数据，它也无济于事，因为它无法知道其他行的数据是否相同。

如果您规范化数据库并从餐厅表中读取，您将获得城市的 ID。现在，如果您在多行上具有相同的 ID，SQL 服务器将缓存读取的城市数据，并且不会再次访问磁盘，因此速度会有所提高。这将被访问新表的需要所抵消，但城市 ID 上的正确索引不应该太多。

这就是为什么我说大型数据库的性能差异不容易评估，最好使用适当的规范化数据库。

是的，如果您使用规范化数据库（第二种情况），您可以在一个地方更改城市名称，因为城市只有一行。这同样适用于其他人（省、国家、大陆）。