Jok*_*ker 22 mysql varchar text
我需要平均存储一段文本,在数据库中约为800个字符.在极少数情况下,它可能会达到2000-2500~字符.我已经阅读了手册,我知道已经有很多这样的问题了,但我已经阅读了10多个关于stackoverflow的问题,我仍然觉得有点难以弄清楚我是否应该简单地使用文本或类似varchar( 2000).一半似乎说使用varchar,而另一半说文字.有些人说如果你有超过255个字符,总是使用文本(是的,这是在5.0.3之后允许varchar高达65k).但后来我想,如果每次字符都超过255时我都会使用文本,那么为什么mysql总是在增加大小,如果这总是最好的选择呢？
它们都有可变的存储空间我读过,所以我的情况会有所不同吗？我个人倾向于varchar(2000)然后我读到varchar存储数据内联而文本没有.这是否意味着如果我不断选择此列,将数据存储为varchar会更好,相反,如果我很少选择此列,那么使用文本会更好吗？如果这是真的,我想我现在会选择文本列,因为我不会在桌面上运行查询时多次选择此列.如果重要的话,这个表也经常加入(但不会选择列),这是否会进一步增加使用文本的好处？
我的假设是否正确,在这种情况下我应该使用文本？
小智 16
当表具有TEXT或BLOB列时,表无法存储在内存中.这意味着每个查询(没有命中缓存)都必须访问文件系统 - 这比内存慢几个数量级.
因此,您应该将此TEXT列存储在单独的表中,该表仅在您确实需要时才会访问.这样原始表可以存储在内存中,并且速度会快得多.
可以把它想象成将数据分成一个"内存表"和一个"文件表".这样做的原因是为了避免访问文件系统,除非必要时(即仅在您需要文本时).
通过将文本存储在多个表中,您无法获得任何收益.您仍然必须访问文件系统.
对不起我的意思是例如,一个论坛脚本,他们可能在帖子表中>存储20列的帖子数据,他们还将实际帖子作为文本字段存储在>同一个表中.那么帖子列应该分开吗？
是.
有一个名为post的表似乎很奇怪,但实际的帖子没有存储在那里,也许>在另一个名为"actual_post"的表中不确定大声笑.
你可以尝试(帖子,post_text)或(post_details,帖子)或类似的东西.
我有一个标签表,只有三个字段,tag_id,tag和description.那么>描述栏也应该分开出来？所以我需要一个标签表和一个> tags_description表来存储3列？
如果描述是TEXT列,并且您对此表运行不需要描述的查询,那么肯定会更好.
我觉得你总结得很好。您可以考虑的另一件事是将“文本”移动到另一个表......然后连接回主记录。这样，每次您实际使用主表时，“文本”所在位置的额外数据甚至不会占用主记录中的空间。当您需要时，您可以加入该表。这样你就可以将它存储为 varchar 以防万一你想做类似“其中文本像...”之类的事情
| 归档时间： |
|
| 查看次数： |
15424 次 |
| 最近记录： |