Mysql 通过非规范化和更小的行优化数据库

在SELECT或UPDATE查询过程中，列数较多的表是否比列数较少的表花费更多的时间？（行数相同，在这两种情况下，我将更新/选择相同数量的列）

示例：我有一个数据库来存储用户详细信息并存储他们最后的活动时间戳。在我的网站中，我只需要显示活动用户及其姓名

比如说，一个名为

userinfo

的表有以下列：（

id、f\u name、l\u name、email、mobile、verified\u status

）。将上次活动时间也存储在同一个表中是否是一个好主意？或者制作一个单独的表（比如，

user\u active

）来存储最后的活动时间戳更好

我问的原因是，如果我创建两个表，

userinfo

表将仅在新注册期间访问（以插入新用户行），我将使用

user\u active

表（列数较少的表）更新时间戳并频繁选择活动用户

---

但是创建两个表所需的成本是数据重复，因为

user\u active

表列将是（

id、f\u name、timestamp

）。

当返回和解析一行时，列的数量不太可能产生明显的差异。但是，搜索和扫描具有较小行的表要比具有较大行的表快

当使用索引进行搜索时，MySQL使用二进制搜索，因此在任何明显的速度损失之前，它需要大量的行（和许多行）

扫描是另一回事。扫描时，它会读取所有行的所有数据，因此对于较大的行，会有1:1的性能损失。然而，有了适当的索引，你不应该做太多的扫描

但是，在这种情况下，请将日期与用户信息保持在一起，因为它们将一起被查询，并且存在1对1的关系，并且具有较大行的表仍然比联接快

---

只有在性能成为实际问题且您无法以任何其他方式（添加索引、改进硬件等）解决问题时，才进行非规范化优化。

您的问题的答案是，在一个表中拥有更多的列并不比拥有更少的列来访问一行花费更多的时间。这似乎有悖常理，但您需要了解数据是如何存储在数据库中的

表的行存储在数据页上。查询的成本在很大程度上取决于查询过程中需要读取和写入的页数。解析数据页中的行通常不是一个重要的性能问题

现在，更宽的行确实有一个非常轻微的性能劣势，因为更多的数据（大概）将返回给用户。对于适合单个页面的行，这是一个非常次要的考虑因素

在更复杂的查询中，较宽的行具有更大的性能劣势，因为对于给定数量的行，需要读取和写入更多的数据页。但是，对于一行，一个页面正在被读取和写入——假设您有一个索引来查找该行（在本例中很可能是这样）

至于你剩下的问题。第二张表的结构不正确。您（通常）不会在两个表中包含

fname

——这是数据冗余，会导致其他各种问题。您是否应该存储一个包含所有活动的表并将该表用于显示目的，这是一个合理的问题，但这不是您要问的问题

---

最后，对于您正在讨论的数据量，拥有几个额外的列不会对任何合理的事务量产生明显的影响。如果每个实体有一个属性，并且没有令人信服的理由不这样做，请使用一个表。

任何性能差异都可能无关紧要。首先设计易于使用/维护，仅在需要时进行优化。记住Knuth的格言：“过早优化是万恶之源。”我想知道更多关于“是否应该存储一个包含所有活动的表，并将该表用于显示目的”。非常感谢。