我需要在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或更多字段?注意:我也可以用空格分隔它们并使用内爆()/爆炸(),但问题仍然是一样的。此外,我专注于UPDATE,这意味着我不寻找SELECT等的速度性能。
编辑:数据库来自同一主机服务器,我希望每10秒左右更新大约5到50行。此外,让我们将随机int数的数量减少到12,这样我们就可以将序列化字符串固定为512到1024个字符。
存储序列化数组还是多列可能不会对性能产生显著影响,除非您有非常高的流量和长字符串。
当你的数组太长以至于序列化的字符串不能放在一个数据库页面上时,它会产生任何可测量的差异。InnoDB自动找到额外的页面来存储字符串的剩余部分,但这意味着更多的页面加载,更多的磁盘搜索等。为了避免溢出页,序列化字符串必须小于等于768字节(请参阅Innodb中的Blob存储以获得完整的解释)。另一个需要考虑的问题是,当你有一个很长的字符串,你需要发布整个字符串,只是为了更新数组的一个成员。这些字节必须以某种方式在网络中传播,并且在使用序列化数组方法时无法仅发布子字符串。字符串越长,UPDATE的开销就越大。最终,如果您同时执行大量这些更新,您可能会耗尽所有网络带宽。
例如,千兆网络(1000Mbit/s)的吞吐量约为112mb/s。如果您的字符串平均为100KB,并且每秒有1125个并发更新,那么即使在快速的专用网络上,这也是您的全部带宽。这还不包括同一网络上的其他流量。
你的评论和更新:
听起来更新的次数和平均字符串长度相当适中。这还不足以成为瓶颈。如果您使用环回TCP/IP接口(127.0.0.1)连接,那么您不必担心带宽。