数据库设计1： 有1个表
Create Table (id int primary key, name varchar(20), description varchar(10000));
数据库设计2： 有2个表
Create Table1 (id int primary key, name varchar(20));
Create Table2 (id int primary key, description varchar(10000));
注意：每个id必须具有与之关联的描述。我们不像名字那样经常查询描述。
在设计1中，1个简单的查询可以获得名称＆amp;描述，不需要加入，但如果我们有100万条记录，那么它会慢吗？
在设计2中，我们需要加入，因此数据库需要一些搜索＆amp;匹配ID - ＆gt;这可能很慢，但我们不经常查询描述，所以有时候并不是所有时间都会慢。
那么这种情况下更好的设计是什么？
答案 0 :(得分：2)
这称为vertical partitioning或“行分裂”并且不是银弹（没有任何东西）。你没有得到“更好的表现”你只是得到“不同的表现”。一组性能特征是否优于另一组是一个工程权衡问题，因情况而异。
在您的情况下，100万行可以很好地适应当今硬件上的DBMS缓存，从而产生出色的性能。因此，除非某些other reasons适用，请将其保存在单个表中。
如果其10亿行（或1万亿或任何数字对于当天的内存标准来说太大），请记住，如果你有indexed your data correctly，性能将在它成为很久之后保持优异大于缓存。
只有在最极端的情况下，您才需要出于性能原因对表格进行垂直分区 - 在这种情况下，您必须在自己的环境中衡量您自己的访问模式，并确定它是否带来任何性能优势;它是否足以弥补增加的JOIN。
答案 1 :(得分：0)
在我看来，这是对100万条记录的过度优化。真的不是那么多。您可以尝试通过为虚拟数据库生成大约一百万行的虚拟数据并查询它来测试实际性能。你会看到它的表现。