用于最快查找的最佳 MySQL 表结构答案

【问题标题】：Optimum MySQL Table Structure for Fastest Lookups用于最快查找的最佳 MySQL 表结构
【发布时间】：2011-05-19 03:03:40
【问题描述】：

对于 100% 读取（不写入）的表，哪种结构更好，为什么？

[我的表格有很多列，但为了简单起见，我在这里做了一个 4 列的示例]

选项 1：一张多列的表格

ID | Length   | Width    | Height
-----------------------------------------
1  | 10       | 20       | 30
2  | 100      | 200      | 300

选项2：两张表；一个存储列标题，另一个存储值

表 1：

ID | Object_ID | Attribute_ID | Attribute_Value
------------------------------------------
1  | 1         | 1            | 10
2  | 1         | 2            | 20
3  | 1         | 3            | 30
4  | 2         | 1            | 100
5  | 2         | 2            | 200
6  | 2         | 3            | 300

表 2：

ID | Name
-------------------
1  | Length
2  | Width
3  | Height

【问题讨论】：

标签： php mysql query-optimization

【解决方案1】：

您的第二个选项是 EAV 反模式的未优化实现：

Entity-Attribute-Value Model

为什么它不好已经在这个网站和其他地方争论死了。

你会从第一次获得更好的结果。

【讨论】：

【解决方案2】：

我先说我是 SQL 和数据库表的新手；但是，这并不意味着我不了解我的基础知识。

除非您的示例过于简单，否则您确实应该使用第一个示例。它不仅查询更快、更容易，而且更有意义。

在此示例中，您根本不需要拆分表；您的“属性 ID”由表头充分表示。此外，这些值本身并没有真正的意义，因此它们实际上不需要在另一个表中。

如果您有另一个单独存在的对象，您通常会拆分一个新表并引用它，该对象与您的对象具有一对多关系。

这是一个在博客条目上使用博客条目和 cmets 的示例（实际上来自我在 O'Reilly 服务器上的数据库）：

mysql> select * from blog_entries;
+----+--------------+-------------+---------------------+
| id | poster       | post        | timestamp           |
+----+--------------+-------------+---------------------+
|  1 | lunchmeat317 | blah blah   | 0000-00-00 00:00:00 |
|  2 | Yongho Shin  | yadda yadda | 0000-00-00 00:00:00 |
+----+--------------+-------------+---------------------+
2 rows in set (0.00 sec)

mysql> select id, blog_id, poster, post, timestamp from blog_comments;
+----+---------+--------------+----------------+---------------------+
| id | blog_id | poster       | post           | timestamp           |
+----+---------+--------------+----------------+---------------------+
|  1 |       1 | lunchmeat317 | humina humina  | 0000-00-00 00:00:00 |
|  2 |       1 | Joe Blow     | huh?           | 0000-00-00 00:00:00 |
|  3 |       2 | lunchmeat317 | yakk yakk yakk | 0000-00-00 00:00:00 |
|  4 |       2 | Yongho Shin  | lol            | 0000-00-00 00:00:00 |
+----+---------+--------------+----------------+---------------------+
4 rows in set (0.00 sec)

mysql>

从逻辑的角度考虑；当不需要时，没有理由人为地将复杂性注入到这个设计中。在您的示例中，长度、宽度和高度并不是真正独立的对象，它们都与您在表格行中描述的对象的尺寸有关。此外，length width 和 height 在给定时间只有一个值。

我希望这是有道理的 - 如果我的教学法有点迂腐，我深表歉意。但是，如果其他人偶然发现了这个问题，希望这个示例对他们有所帮助。

祝你好运。

编辑：我刚刚意识到您的问题专门针对性能。这更深入一点，也许基于您使用的数据库引擎？不过，一般来说，考虑到非规范化是一种常用的提高性能的方法，我认为查询表而不进行任何连接会稍微快一些。

【讨论】：