我是一名拥有一些有限数据库知识的开发人员，他试图为新应用程序整合可扩展的数据库设计。任何人都可以提出有关这个问题的任何想法将不胜感激。
假设我目前有以下表格：
Stuff
------------
ID Integer
Attr1 Integer
Attr2 Integer
Attr3 Double
Attr4 TinyInt
Attr5 Varchar(250)
展望未来，假设我们将在此表中拥有5亿条记录。但是，在任何给定时间，只有5000个左右的记录在Attr5列中有任何内容;所有其他记录将具有空白或空Attr5列。插入记录时，Attr5列填充100-200个字符，然后每夜进程将清除其中的数据。
我担心的是，表空间中心的这么大的varchar字段（否则主要包含小数字字段）会降低对表的读取效率。因此，如果更改数据库设计以使用两个这样的表可能会更好：
Stuff
------------
ID Integer
Attr1 Integer
Attr2 Integer
Attr3 Double
Attr4 TinyInt
Stuff_Text
------------
StuffID Integer
Attr5 Varchar(250)
然后在夜间过程中从Stuff_Text中删除，将其保留在5,000条记录中，从而使Stuff表的大小保持最小。
所以我的问题是：是否有必要将此表分解为两个，或者数据库引擎是否足够智能以便有效地存储和访问信息？我可以看到数据库压缩数据效率并在Attr5中存储没有数据的记录，就好像没有varchar列一样。我还可以看到数据库在预测Attr5数据的每条记录中留下一个开放的250字节数据。我倾向于期待前者，因为我认为这是varchar超过char的目的，但我的数据库经验有限，所以我认为我最好仔细检查。
我正在使用MySQL 5.1，目前在Windows 2000AS上，最终升级到Windows Server 2008家族。数据库目前在标准的7200转磁盘上，最终将被移动到SSD。
答案 0 :(得分：0)
如果您使用VARCHAR并允许NULL值，那么您应该没有问题。因为存储这种数据类型非常有效。这与CHAR数据类型非常不同，但您已经拥有VARCHAR。
无论如何，将它分成两个表并不是一个坏主意。这可能会使查询缓存保持活动状态，但这主要取决于这些表的使用情况。
我可以说最后一件事：尝试对其进行基准测试。检查大量数据并尝试模拟某些用途。
答案 1 :(得分：0)
Stuff ------------ ID Integer Attr1 Integer Attr2 Integer Attr3 Double Attr4 TinyInt Attr5 Integer NOT NULL DEFAULT 0 (build an index on this) Stuff_Text ------------ Attr5_id Integer (primary key) Attr5_text Varchar(250)
行动中
desc select * from Stuff WHERE Attr5<>0;
desc select Stuff.*, Stuff_text.Attr5_text
from Stuff
inner join Stuff_text ON Stuff.Attr5=Stuff_text.Attr5_id;
where Attr5 <>0 <-- scan 5,000 rows