我可以“优化”涉及文本列的查询吗？

Question

如果我有这个 400M 行的表：

create table my_table
( id int,
  filled tinyint,
  content text not null
) engine=myisam

我可以通过以下方式阻止对内容的额外访问（由于列类型文本）：

select id,if(filled,content,'') from my_table

（填充的是0或1）？

或者如果内容可以为空，会

select id,ifnull(content,'') from my_table

更好（仍然在性能方面，因为会发生空开销）？

Answer 1

你的问题不准确。 一行可能有filled = 1和content = 'some text'吗？

如果是，则IF(filled, content, '')有意义。

如果不是，则摆脱filled并简单地将content设置为'' 。 访问content的空字符串的成本很小。

content通常有多大？ 如果通常只有数百个字符，则性能差异很小。

不要使用 MyISAM，切换到 InnoDB。

你有很多DELETEs或UPDATEs吗？ 如果是这样，MyISAM 的 .MYD 文件可能是碎片化的。 这意味着content可能分散在磁盘周围。 如果您没有更新或删除，则content “就在那里”，因此几乎可以免费访问。

相比之下，InnoDB有时会将TEXT和BLOB置于“非记录”状态。

但是，哪个更好或更坏？ 记录外（在某些情况下）与碎片（在某些情况下）。

你只提取一行吗？ 或者很多这样的行？ 这是 MyISAM 和 InnoDB 实现完全不同的另一个领域。 MyISAM 需要跳过content才能到达“下一个”行。 （我不会对“下”行可能在哪里进行冗长的讨论。）

底线：不担心优化，但做出改变InnoDB的（对于很多原因）。

“下一个”行可能在哪里？

MyISAM... 行按插入顺序添加到 .MYD 中。 但是，在更新或删除之后，新的/更改的行倾向于首先填充空白，将附加到文件作为最后的手段。

InnoDB... 行位于按PRIMARY KEY排序的 B+Tree 中。 BTree 被 16KB 块阻塞。 你有一个TEXT列，所以它变得更复杂......

对于“小”TEXT 列，几行将适合 16KB。 例如，如果content是 1KB 的字符串，那么一个块中最多可以放入大约 15 行。 如果它们更大，那么content将被“非记录”存储。

块中的行基本上都彼此等距。 （最大的努力是将块加载到缓存中并定位块。）

“下一个”（或“上一个”）块只是一个磁盘访问——参见“B+树”中的“+”。

当一个块溢出时，它被“拆分”成两个块，每个块都有一些行。 新块被分配在某处，很少相邻。

使用 SSD，所有块彼此“等距”。 对于 HDD，旋转延迟和手臂运动使哪个块可能比其他块“更接近”的时间复杂化。