mysql总结2000字_MySQL varchar(2000)vs文字？

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

我所读过的它们的存储大小都可变，所以我的情况不会有差异吗？我个人倾向于varchar(2000)，然后我读到varchar内联存储数据，而文本则不行。这是否意味着如果我不断选择该列，将数据存储为varchar会更好，反之，如果我很少选择此列，那么使用文本会更好？如果是这样，我想我现在选择text列，因为我在表上运行查询的很多次都不会选择该列。如果重要的话，该表也经常被联接(但不会选择该列)，这还会进一步带来使用文本的好处吗？

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

考虑一下内存使用情况。 VARCHAR字段是该行的一部分，其中TEXT列只是通过行中的地址指向磁盘上。 您的决定将影响查询缓存(该内存中可以容纳多少个结果集)，表缓存(该内存中可以容纳多少个表)，各个查询缓冲区中可以容纳多少行，等等。

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

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

可以将它视为将数据分为一个"内存表"和一个"文件表"。这样做的原因是为了避免访问文件系统，除非必要时(即仅当您需要文本时)。

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

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列，并且您对不需要该描述的表运行查询，那肯定是更好的选择。

抱歉，当您说"使用TEXT的表不能在内存中但需要文件I / O"时，您的意思是什么。这是否意味着即使我想在这种情况下使用文本，也无法(如果我将其保留在同一表中)。

感谢您详细解释。尽管这听起来听起来很麻烦，但这是否意味着每个文本列都应存储在单独的表中，因为即使是少于2000个字符的列也需要分开？您是否有示例说明何时应将文本列保留在同一张相关数据表中？

我更新了我的答案以解决您的问题。

对不起，我的意思是，例如，一个论坛脚本，在posts表中，它们可能存储20列的post数据，它们还将实际的post作为文本字段存储在同一表中。那个柱子应该分开吗？似乎有一个叫做post的表很奇怪，但是实际的post没有存储在那儿，也许不是在另一个叫做" actual_post"的表中，大声笑。我有一个标签表，其中只有三个字段，即tag_id，tag和description。这样说明列也应该分开吗？所以我只需要一个tag表和一个tag_description表来存储3列？

我更新了我的答案以解决您的问题。

那为什么人们很少这样做呢？即使在很多非常关注性能的商业应用程序中，似乎也不会这样做。有趣的是，我曾经这样做，但后来更改为将所有内容添加到主表中。现在，我应该回到之前的工作...这也是您从一开始就应该做的事情，还是将数据保留在同一表中，并且仅当您看到问题然后尝试将其分离出来时才做？我会更好地在主表中使用varchar(2000)吗？

我想这对我来说似乎很奇怪，想象一下，如果您有50个表，而其中的30个表需要描述，现在您又需要30个表，每个表只有1列。

我打算看看是否还有其他意见。但是我会更好地在主表中使用varchar(2000)而不是所有麻烦吗？这也意味着，当我更新或删除记录时，我还需要在多个表中进行记录。我还认为，如果您不打算一直选择文本，使用文本也会更好，但是您说的恰恰相反。我还注意到您说过，对于未缓存的查询，它会慢很多，但是总的来说，大多数查询都会变成缓存的吧？

@Joker当然，您可以使用VARCHAR(2000)，如果性能下降，可以稍后再使用。但是，如果您有时从表中进行SELECT但又不需要文本段落，则最好将其存储在单独的表中。

当您说"当一个表具有TEXT或BLOB列时，该表不能存储在内存中"，我认为它不是真的。我只是从mysql.com上读到，只有当您实际选择该值时，您才会因为使用磁盘而受到性能损失。这就是为什么他们说避免SELECT *。因此，如果您的查询没有真正选择文本列，我认为它不会像您所说的那样糟糕。这就是为什么让我感到困惑的原因，因为正如我在第一篇文章中所说的那样，我认为如果不选择该值，那么实际上文本比varchar好。

我的理解是TEXT列始终单独存储，因此将它们存储在单独的表中是没有意义的。 实际上，这里有一个问题，人们对此表示赞同：stackoverflow.com/questions/1849269/-您对此有何看法？ 您仍然坚持在这里说的话吗？ 尝试找出正确的方法，谢谢！

我认为您总结得很好。您可以考虑的另一件事就是将"文本"移到另一个表中……然后再联接回主记录。这样，每次实际使用主表时，"文本"所在位置的多余数据甚至都不会占用主记录中的空间。需要时，您可以加入该表。这样，您就可以将其存储为varchar，以防万一您想要执行诸如" where text like ..."之类的操作

我以前是这样做的，但被告知否则，除非我每秒进行多次查询，否则最好将其存储在同一张表中。我还想出了2000个字符的数据将其放在单独的表中的情况。另一种情况是，有人说一件事，而另一人说另一件事。 ：P也许我现在应该将该列保留在表中，如果我遇到问题将其移出？

这个问题的答案似乎表明我们不应将其存储在另一个表中。有任何想法吗？ @小丑？只是想在此方面获得一个可靠的答案。干杯。