MySQL:高效起泡？

Question

我正在处理高达-我估计-约100千字节大小的气泡。数据已经被压缩了。

存储引擎: InnoDB on MySQL 5.1

前端: PHP (Symfony with Propel ORM)

一些问题：

• --我在某个地方读到过，更新blobs不好，因为它会导致重新分配、碎片化，从而导致性能下降。这是真的吗？this?
• Initially上的任何引用blobs都是通过附加数据块来构造的。每个块的大小可达16千字节。是否更有效地使用单独的块表，例如在下面的字段中使用？

parent_id, position, chunk

然后，为了得到整个blob，一个人会做如下的事情：

SELECT GROUP_CONCAT(chunk ORDER BY position) FROM chunks WHERE parent_id = 187

• 除了元数据所需的大小之外，还存在不同类型的blobs，这应该是可以忽略不计的。

Answer 1

如果要在表中创建和删除数据，则会得到表的数据结构的碎片。

我不认为您可以通过将blobs分割成块来获得任何东西--在DB碎片之前分割数据是不会得到任何东西的:)

您可以通过重新构建表的结构来对其进行碎片整理(OPTIMIZE TABLE in MySQL)。

我找不到MySQL如何在磁盘上存储blobs的信息。如果它将它们与其他行数据一起存储，那么您可以使用聚集索引( InnoDB中的PK，MyISAM中的ALTER TABLE ORDER BY )来要求表的数据文件中的特定数据顺序(例如，按受欢迎程度排序创建“热门”区域，这可能会改进缓存并减少查找)。

除了数据库本身的结构碎片外，还存在文件系统中表文件的碎片问题。

即使您只将数据插入到表本身为零碎片的表中，保存表文件的文件系统迟早也会在磁盘上将其碎片化。对于安全的文件系统来说，这是不可避免的，因为它们从不就地更新文件的数据。

如果碎片是一个问题，那么我会攻击它的最低水平可能。不要在数据库中存储blobs，只存储一些对磁盘上文件的引用。

文件系统更接近物理磁盘，因此它们可以比DB查询更好地处理碎片，而DB查询是上面几个抽象级别。一些文件系统会自动整理小文件的碎片，但会留下大文件的碎片。

或者，您可能只是在问题上抛出硬件--使用RAID，为磁盘/DB缓存添加大量的RAM，或者使用SSD。

当然，您已经仔细地对其进行了基准测试，并且知道碎片首先是一个问题，对吗？