我一直在研究数据库，我必须处理一个TEXT字段。
现在，我相信我已经看到一些地方提到最好将TEXT列与表的其余部分隔离开来（将它放在自己的表中）。
然而，现在我无法在任何地方找到这个参考，因为它已经有一段时间了，我开始认为我可能会错误地解释这些信息。
一些研究显示this，暗示
将文本/ blob与元数据分开，如果不需要，请不要将文本/ blob放在结果中。
但是，我不熟悉这里使用的“元数据”的定义。
所以我想知道将TEXT列放在自己的表中是否有任何相关的优点。与其他领域合作的潜在问题是什么？将它保存在分开的表格中的潜在问题？
该表（没有TEXT字段）应该被频繁地搜索（选择）。 “过早优化被认为是邪恶的”在这里很重要吗？ （如果在TEXT列中确实存在惩罚，那么 的相关性如何，考虑到以后在需要时更改它很容易）。
此外，这个主题有什么好的链接吗？ （也许stackoverflow问题和答案？我试图搜索这个主题，但我只发现了TEXT与VARCHAR的讨论）
答案 0 :(得分：6)
祝福， 费边
答案 1 :(得分：5)
这可能是过早的优化。性能调优MySQL非常棘手，只能通过应用程序的真实性能数据来完成。我已经看到很多尝试再次猜测是什么让MySQL在没有实际数据的情况下变慢，结果每次都是一个混乱的架构和复杂的代码，这实际上会使性能调整更加困难。
从标准化的简单模式开始，然后当事情证明太慢时，只在需要的地方添加复杂性。
正如其他人所指出的那样，你提到的引用更适用于查询结果而不是模式定义，无论如何你选择的存储引擎都会影响建议的有效性。
如果你确实发现自己需要将TEXT / BLOB列移动到一个单独的表中的复杂性，那么可能值得考虑将它们完全移出数据库的选项。文件存储通常优于数据库存储，特别是如果您不对TEXT / BLOB列的内容进行任何关系查询。
基本上，在获取互联网上的任何MySQL调优建议之前，先获取一些数据，包括这个！
答案 2 :(得分：3)
TEXT列的数据已单独存储。每当您从包含文本列的表中SELECT *时，结果集中的每一行都需要查找文本存储区域。这与大量数据的真正可能性相结合将是您系统的一大开销。
将列移动到另一个表只需要一个额外的查找，一个进入辅助表，一个正常进入文本存储区。
将TEXT列移动到另一个表中的唯一时间将带来任何好处，如果通常选择表中的所有列的倾向。这只是引入第二种不良做法来弥补第一种不良做法。 不用说两个错误与三个 不一样。
答案 3 :(得分：1)
可能有一些很好的理由将文本字段从表定义中分离出来。例如，如果您正在使用加载完整记录的ORM而无论如何，您可能希望创建一个属性表来保存文本字段，以便它不会一直加载。但是，如果您要控制代码100％，为简单起见，请将字段保留在表格中，然后仅在需要时选择它以减少数据传输和读取时间。
答案 4 :(得分：1)
值得关注的是，超过8,192字节的大型文本字段方式会在未编制索引的字段上进行复杂查询时导致过多的分页和/或文件i / o。在这种情况下，最好将大字段迁移到另一个表，并将其替换为新表的行id或索引（然后它将是metadata，因为它实际上不包含数据）。
缺点是： a）更复杂的架构 b）如果大型油田正在使用检查或检索，则没有任何优势 c）确保数据一致性更复杂，并且是数据库不适的潜在来源。
答案 5 :(得分：1)
现在，我相信我已经看到一些地方提到最好将TEXT列与表的其余部分隔离开来（将它放在自己的表中）。 但是，现在我无法在任何地方找到这个参考，因为它已经有一段时间了，我开始认为我可能误解了这些信息。
你可能从MySQL手册中看到了这一点 http://dev.mysql.com/doc/refman/5.5/en/optimize-character.html
如果表包含字符串列（如名称和地址），但许多查询不检索这些列，请考虑将字符串列拆分为单独的表，并在必要时使用带有外键的连接查询。当MySQL从一行中检索任何值时，它会读取包含该行的所有列（以及可能的其他相邻行）的数据块。仅使用最常用的列保持每行较小，允许更多行适合每个数据块。这种紧凑的表减少了常见查询的磁盘I / O和内存使用。
这确实告诉你，在MySQL中你不鼓励在频繁搜索的表中保留TEXT数据（和BLOB，如其他地方所写）