mySQL UPDATE TEXT vs INT字段类型(速度性能)

时间:2014-06-20 18:12:46

标签: php mysql

我需要在mySQL表中更新一个未确定的数字(最大值:32个)随机int / float数。

在PHP中,我将它们放在一个数组中:

$array['numbers'][1]=5.5;
$array['numbers'][2]=2;
$array['numbers'][3]=43;
(...)

mySQL场景1:

+----+-----------------------------------+
| id | numbers(Text)                     |
+----+-----------------------------------+
|  1 | a:3:{i:1;d:5.5;i:2;i:2;i:3;i:43;} |
+----+-----------------------------------+

mySQL场景2:

+----+------------+------------+------------+---
| id | no1(int)   | no2(int)   | no3(int)   |  
+----+------------+------------+------------+---
|  1 | 5.5        | 2          | 43         |
+----+------------+------------+------------+---

要在两个场景中更新这些字段,我知道id(这是INT auto_increment)所以我将包含WHERE id = $ known_id

如果我序列化这些并更新方案1,它在 UPDATE 速度方面是否有任何区别?或者情景2是否明显更快,请记住它可能是12,13,14或更多字段?

注意:我也可以用空格分隔它们并使用implode()/ explode(),但问题仍然是一样的。另外,我专注于UPDATE,这意味着我没有为SELECT等寻找速度性能。

修改

数据库来自同一主机服务器,我希望每10秒左右更新大约5到50行。另外,让我们将随机int数的数量减少到12,这样我们就可以用512到1024个字符来修复序列化字符串。

1 个答案:

答案 0 :(得分:1)

无论是存储序列化数组还是多列,它都可能无法在性能上产生显着差异,除非您拥有非常高的流量和长字符串。

它会产生任何可衡量的差异的情况是当您的数组太长以至于序列化字符串不适合单个数据库页面时。 InnoDB自动找到额外的页面来存储字符串的其余部分,但这意味着更多的页面加载,更多的磁盘搜索等。为了避免溢出页面,序列化字符串必须是768字节或更少(参见{{3完整的解释)。

另一个考虑因素是当你有一个非常长的字符串,你需要发布整个字符串只是为了更新数组的单个成员。这些字节必须以某种方式通过网络传播,并且当您使用序列化数组方法时,无法仅发布子字符串。字符串越长,执行UPDATE的开销就越大。最终,如果您同时执行大量这些更新,则可能会耗尽所有网络带宽。

例如,千兆网络(1000Mbit / s)的吞吐量约为112 MB / s。如果您的字符串平均为100KB,并且每秒有1125个并发更新,则即使在快速专用网络上也是如此。这甚至不计算同一网络上的其他流量。


重新评论和更新:

听起来像更新次数和平均字符串长度非常适中。这不足以成为瓶颈。如果使用环回TCP / IP接口(127.0.0.1)进行连接,则不必担心带宽。