【问题标题】:Mysql performance, one table or twoMysql性能,一表二
【发布时间】:2017-01-29 15:43:20
【问题描述】:

我使用 PHP 和 mysql。

假设我有一个包含 10 000 行的数据库表。下面哪种情况下性能最好?

案例一

两个表,productscategories

SELECT * FROM products INNER JOIN categories ON products.category_id = categories.id

产品

id
name
category_id

类别

id
name

案例 2

一个表,products,包含所有数据。

SELECT * FROM products

产品

id
name
category_name

问题

  • 这些案例中哪一个的性能最好?
  • 猜猜,获取具有类似结构的 10 000 行的数据需要很长时间吗?
  • 其中一种情况有什么陷阱吗?

在我看来,Case 1 是“正确”的做法,但使用Case 2 会节省一些开发时间。也许还有性能?

【问题讨论】:

  • 10k 行与正确的索引无关。即使有 1 亿条记录,也要使用单独的表!
  • 就我的知识和经验而言,case1 更好
  • 根据@juergend,您只需要在case1中使用适当的索引
  • 您应该始终选择 CASE 1。从长远来看,它更具可扩展性和可维护性。数据库针对这类事情进行了优化,所以完全不用担心性能。
  • 为了提高除其他 cmets 之外的性能,选择实际列而不是全部会有所帮助。如果您不需要全选,请仅选择需要的那些。不过,您可能应该在 db exchange 中发布此内容。

标签: php mysql sql performance select


【解决方案1】:

第一个是存储此数据的正确(即 SQLish)方式。它允许您执行以下操作:

  • 使用标准外键关系在插入和更新类别名称时对其进行验证。
  • 更改类别名称并使其影响所有产品。
  • 包括有关类别的其他信息,例如短名称、详细描述、添加日期等。

性能不是主要考虑因素。 SQL 引擎通过使用花哨的连接算法和索引来处理性能。这样做是为了让您可以以最合理和可维护的方式为您的应用程序构建数据。

也就是说,哪个表现更好取决于许多因素(类别名称的长度、有多少不同的名称、产品记录的范围)。两种方案之间的性能差异可能对于让应用程序以最佳方式工作并不重要。

【讨论】:

    【解决方案2】:

    案例 1 比案例 2 好,因为如果您实施案例 2,您最终会得到双重数据。通过双重数据,我的意思是您将在“category_name”字段中拥有多次相同的值。这很糟糕,有两个原因,首先是因为过多、不必要的数据(双数据)会降低性能。第二个原因是效率。假设您想更改一个类别名称,例如喝饮料,在第二种情况下比在第一种情况下需要更多的时间。 因此,要回答您的第一个问题,案例 1 就是这样做的方法。

    您可以通过阅读我对问题的回答来想象,案例 1 比案例 2 更快,因为案例 2 包含不必要的数据。

    您的最后一个问题,就像我在对问题一的回答中所解释的那样,案例 2 的一个陷阱是您想要更改类别名称,您最终会比案例 1 做更多的工作。案例 1 有我的知识没有陷阱。

    【讨论】:

      【解决方案3】:

      我认为问题 id database design 为中心。

      现在回答你的问题:

      1. 哪种情况下性能最好?

        答案 - 案例 1。

        为什么?

        • 它遵循Normalization 的基本SQL 规则,这将有助于您长期运行。如果将来您有超过10,000 行,那么在redundant data 的单个表中处理它会很乏味。
        • 如果您对key 列执行indexing,它将帮助您在大量行上更快地执行join 查询。
        • 两个单独的表将帮助您减少数据redundancy

        为什么不是案例 2?

        单个表将违反Normalization 规则。您的示例表明,单个表将违反这些规则。

      2. 用类似的结构获得 10,000 行需要很长时间吗?

        情况 1: 会比 Case 2 花费一点时间,因为会涉及到 join 查询。但是这个时间将是 negligible 并且可以通过使用来减少indexing 也是。

        情况 2:Case 1 花费的时间要少一些,但由于redundant data 或记录数量会增加,它的性能可能会有所欠缺。

      3. 可能的陷阱?

        使用案例 1 -

        • 您最终可能会为一些困难的场景编写复杂的 join 查询。

        使用案例 2 -

        • 数据冗余/重复
        • 长期运行时性能低下
        • 可读性差

      希望这对您有所帮助。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2013-03-05
        • 1970-01-01
        • 1970-01-01
        • 2016-12-10
        • 2011-09-12
        • 2017-04-30
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多