我知道在MySql表中使用文本类型字段时,数据不是内联存储的,而只是一个指针'存储在行中。我只是不经常检索文本字段,所以最好是将它保存在同一个表中但是从查询结果中省略它还是将它保存在一个单独的表中并在我想要读取它时加入该表?
此表可能包含数十亿行,需要进行分区并具有较大(100k - > 1Mb)的文本字段值。
答案 0 :(得分:1)
具有100k字段的十亿行至少可以说是大的。这达到了100TB的数据(使用美国的“terabyte”定义)。根据{{3}}:
InnoDB存储引擎在表空间内维护InnoDB表 可以从多个文件创建。这使表格超出 最大单个文件大小。表空间可以包含原始磁盘 分区,允许非常大的表。最大值 表空间大小为64TB。
换句话说,你可能遇到比性能更大的问题。您可能会将表扩展到多个分区。
如果您只是偶尔检索文本而从不将其用于搜索,我建议您将其存储在单独的表中。这样,您可以自定义该表以访问这些记录。您将拥有一个用于参考的主键,所有引用都将通过该ID。
如果您使用文本进行搜索,特别是搜索结合“固定”数据,那么我的架构首选项是将其包含在基表中以便于跨字段搜索。
然而,即使有这种偏好,将它放在不同的表中可能更安全。例如,MySQL实例化子查询。将*
用于子查询是非常典型的。考虑一个简单的情况:获取由userid排序的1000条最新记录的查询:
select t.*
from (select t.*
from t
order by createddate
limit 1000
) t
order by userid
t.*
的使用意味着还将检索文本列。因此,可能需要几分之一秒(带索引)的查询将不得不读取和写入1000 * 100k = 100 MB的数据(至少)。这可能需要更长的时间。
总之,我建议将文本列放在一个表中,通常用其他列搜索它 - 例如,在科学论文摘要的数据库中。对于非常大的数据,我会把它放在一个单独的字段中,所以在极端情况下我可以更好地管理存储。
答案 1 :(得分:0)
我接受它:
通常,我会说对文本指针的引用是不必要的,特别是在处理多个连接,潜在的分区等时。
另一方面,这是一张桌子上的怪物。如果您忘记排除文本字段或者可能有某人,但没有充分了解您的数据结构,那么在同一个数据库上工作,可能会发出一个简单的SELECT * FROM monstertable
...,具体取决于您的服务器,它可以杀死/拖延它一段时间。
简而言之:对于性能,单个表应该更好一点,对于安全性/稳定性,最好分开。
副节点: 我会问自己,MySQL甚至关系数据库是否都是这项任务的正确工具 (花费无数个小时寻找替代方案,大肆宣传并使用MySQL,因为它已经安装在任何地方且集成良好;)