这是场景，旧数据库有这种设计
dbo.Table1998
dbo.Table1999
dbo.Table2000
dbo.table2001
...
dbo.table2011
我在这个表 dbo.TableAllYears 中合并了 1998 年到 2011 年的所有数据
现在它们都由“应用程序编号”索引并且具有相同的列数（实际上是 56 列..）
现在当我尝试
select * from Table1998
和
select * from TableAllYears where Year=1998
第一个查询有 139669 行 @ 13 秒，而第二个查询有相同的行数但 @ 30 秒
所以对你们来说，我只是错过了一些东西，还是多张桌子比单张桌子好？
您应该按年份对表进行分区，这几乎相当于每年都有不同的表。这样，当您按年查询时，它将针对单个分区进行查询，并且性能会更好。
如果您要查找 1998 年的数据，那么最好在一个表中仅包含 1998 年的数据。这是因为数据库不必“搜索”记录，但知道该表中的所有记录都来自 1998 年。尝试将“WHERE Year=1998”子句添加到 Table1998 表中，您应该会得到一个比较好一点。
就个人而言，我会将数据保存在多个表中，特别是如果它是一个特别大的数据集并且您不必经常对旧数据进行查询。即使您这样做了，您也可能希望创建一个包含所有表数据的视图并在该视图上运行报告，而不必查询多个表。
尝试在您正在搜索的每个列上删除一个索引（where 子句）。这应该会大大加快查询速度。
所以在这种情况下，为字段 Year 添加一个新索引。
我相信你应该使用一张桌子。不可避免地，您需要跨多年查询数据，并且将其分成多个表是一个问题。优化您的查询和表结构是很有可能的，这样您就可以在一个表中拥有数百万行并且仍然具有出色的性能。确保您的年份列已编入索引，并包含在您的查询中。如果你真的遇到了数据大小的限制，你可以使用 MySQL 5 中的分区功能，它允许它把表数据存储在多个文件中，就好像它是多个表一样，同时让它看起来是一个表。
不管怎样，140k 行算不了什么，将其拆分为多个表可能为时过早的优化，如果您需要跨多年查询数据，甚至会严重损害性能。