MySQL varchar(2000)与文本？

Question

我平均需要在数据库中存储大约 800 个字符的一段文本。在极少数情况下，它可能会达到 2000-2500~ 个字符。我已经阅读了手册，我知道已经有很多这样的问题，但是我已经阅读了超过 10 多个关于 stackoverflow 的问题，我仍然发现我仍然很难弄清楚我是否应该简单地使用文本或类似 varchar( 2000)。一半似乎说使用 varchar，而另一半说文本。有人说如果你有超过 255 个字符，总是使用文本(是的，这是在 5.0.3 之后允许 varchar 高达 65k)。但是后来我想如果我每次字符超过 255 时都使用文本，那么如果这始终是最好的选择，mysql 为什么还要费心增加大小呢？

它们在我读过的存储空间中都有可变大小，所以我的情况不会有什么不同吗？我个人倾向于 varchar(2000) 然后我读到 varchar 内联存储数据，而 text 没有。这是否意味着如果我经常选择此列，将数据存储为 varchar 会更好，相反，如果我很少选择此列，那么使用文本会更好？如果这是真的，我想我现在会选择文本列，因为我在表上运行查询的很多时候都不会选择这个列。如果重要的话，这个表也经常被加入(但不会选择列)，这是否也会进一步提高使用文本的好处？

在这种情况下我应该使用文本的假设是否正确？

Answer 1

当一个表有 TEXT 或 BLOB 列时，该表不能存储在内存中。这意味着每个查询(不命中缓存)都必须访问文件系统——这比内存慢几个数量级。

因此，您应该将此 TEXT 列存储在一个单独的表中，仅在您实际需要时才访问该表。这样可以将原始表存储在内存中，速度会快很多。

把它想象成把数据分成一张“内存表”和一张“文件表”。这样做的原因是为了避免在必要时访问文件系统(即仅当您需要文本时)。

将文本存储在多个表中不会获得任何 yield 。您仍然必须访问文件系统。

Sorry what I meant was for example, a forum script, in the posts table they might be >storing 20 columns of post data, they also store the actual post as a text field in the >same table. So that post column should be separated out?

是的。

It seems weird to have a table called post, but the actual post isn't stored there, maybe >in another table called "actual_post" not sure lol.

您可以尝试 (posts, post_text) 或 (post_details, posts) 或类似的东西。

I have a tags table that has just three fields, tag_id, tag, and description. So that >description column should also be separated out? So I need a tags table and a >tags_description table just to store 3 columns?

如果描述是一个 TEXT 列，并且您对该表运行不需要描述的查询，那么它肯定是更可取的。