DB设计1：有1个表
创建表（id int 主键，名称 varchar(20)，描述 varchar(10000)）；
DB设计2：有2个表
创建Table1（id int主键，名称varchar(20)）；
创建Table2(id int主键，描述varchar(10000))；
注意：每个 id 必须有一个与之关联的描述。我们不会像名称那样经常查询描述。
在设计1中，1个简单的查询就可以得到name&description，不需要join但是如果我们有100万条记录，那会不会很慢？
在设计 2 中，我们需要连接，因此数据库需要一些搜索和匹配 id --> 这可能会很慢，但我们不经常查询描述，因此有时会很慢。
那么在这种情况下更好的设计是什么？
这称为垂直分区或“行拆分”，并不是灵丹妙药（什么都不是）。你没有得到“更好的表现”，你只是得到了“不同的表现”。一组性能特征是否优于另一组是工程权衡的问题，并且因情况而异。
在您的情况下，100 万行可以轻松放入当今硬件上的 DBMS 缓存中，从而产生出色的性能。因此，除非其他一些原因适用，否则请保持简单，在一个表中。
如果它的 10 亿行（或 1 万亿或任何数字对于当时的内存标准来说太大了），请记住，如果您正确索引了数据，那么在它变得比缓存大之后，性能仍将保持良好状态.
只有在最极端的情况下，您才需要出于性能原因对表进行垂直分区——在这种情况下，您必须在自己的环境中使用自己的访问模式进行测量，并确定它是否带来任何性能优势；它是否足够大以弥补增加的 JOINing。
在我看来，这是对 100 万条记录的过度优化。真的没有那么多。您可以尝试通过为虚拟数据库生成大约一百万行的虚拟数据并查询它来测试实际性能。你会看到它的表现如何。