通过非规范化和较小的行进行数据库优化

时间:2015-03-26 10:38:20

标签: mysql database

在SELECT或UPDATE查询期间,具有多列的表是否比具有较少列的表占用更多时间? (行数相同,我将在两种情况下更新/选择相同数量的列)

示例:我有一个数据库来存储用户详细信息并存储其上一个活动时间戳。在我的网站中,我只需要显示活跃用户及其姓名。

比如说,一个名为userinfo的表具有以下列:(id,f_name,l_name,email,mobile,verified_status)。将最后活动时间也存储在同一个表中是一个好主意吗?或者最好制作一个单独的表(比如user_active)来存储最后一个活动时间戳?

我问的原因,如果我制作了两个表,userinfo表只会在新注册时被访问(要INSERT新用户行),我将使用user_active表(表少列)经常更新时间戳和SELECT活跃用户。

但是,我必须为创建两个表而支付的费用是数据重复,因为user_active表格列将是(id, f_name, timestamp)。

2 个答案:

答案 0 :(得分:1)

你的问题的答案是,近似地说,在表格中有更多的列并不比用更少的列访问单行花费更多的时间。这可能看似违反直觉,但您需要了解数据如何存储在数据库中。

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

现在,更宽的行确实具有非常轻微的性能劣势,因为(可能)会将更多数据返回给用户。对于适合单个页面的行,这是一个非常小的考虑因素。

在更复杂的查询中,更宽的行具有更大的性能劣势,因为需要针对给定数量的行读取和写入更多数据页。但是,对于单行,正在读取和写入一个页面 - 假设您有一个索引来查找该行(在这种情况下看起来非常可能)。

至于你的其余问题。第二个表的结构不正确。您不会(通常)在两个表中包含fname - 即数据冗余并导致所有其他问题。您是否应该存储所有活动表并使用该表作为显示目的存在一个合理的问题,但这不是您要问的问题。

最后,对于您正在讨论的数据量,在任何合理的交易量上,添加一些额外的列将没有明显的差异。如果每个实体有一个属性,并且没有令人信服的理由,则使用一个表。

答案 1 :(得分:0)

返回并解析单行时,列数不太可能产生显着差异。但是,搜索和扫描具有较小行的表比具有较大行的表更快。

当使用索引进行搜索时,MySQL使用二进制搜索,因此在任何速度惩罚明显之前,它将需要更大的行(和许多行)。

扫描是另一回事。扫描时,它会读取所有行的所有数据,因此对于较大的行,性能会受到1对1的影响。然而,使用适当的索引,你不应该做很多扫描。

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

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