为什么你需要创建一个有 20 列的表，更不用说 2000 了？？？

当然，非规范化数据可以避免必须执行 JOIN 来检索许多数据列。但是，如果您有超过 10 列，您应该停下来想一想在数据检索期间会发生什么。

如果一个 2000 列的表经历 SELECT * FROM … WHERE，您将在处理过程中生成大型临时表，获取不必要的列，并创建许多场景，其中通信数据包 ( max_allowed_packet ) 在每次查询时都会被推到边缘。

在我早期作为开发人员的日子里，我在 1995 年曾在一家公司工作，当时 DB2 是主要的 RDBMS。该公司有一个包含 270 列、数十个索引的表，并且在检索数据时存在性能问题。他们联系了 IBM，并让顾问检查了他们系统的架构，包括这张单片机。该公司被告知“如果您在未来 2 年内不规范化该表，DB2 将在执行 Stage2 处理的查询（任何需要对非索引列进行排序的查询）上失败。” 这被告知一家价值数万亿美元的公司，以规范一个 270 列的表。2000 列的表格更是如此。

就 mysql 而言，您必须通过设置与 DB2 Stage2 处理相当的选项来弥补这种糟糕的设计。在这种情况下，这些选项将是

• max_allowed_packet
• tmp_table_size
• max_tmp_tables
• max_heap_table_size
• max_length_for_sort_data
• 最大排序长度
• 排序缓冲区大小
• myisam_max_sort_file_size
• myisam_sort_buffer_size

如果您有 TB 的 RAM，则调整这些设置以弥补数十个（更不用说数百个）列的存在效果很好。

如果你使用 InnoDB，这个问题会成倍增加，因为你将不得不处理MVCC（多版本并发控制），试图通过事务隔离来保护每个 SELECT、UPDATE 和 DELETE 的大量列。

结论

没有替代品或创可贴可以弥补糟糕的设计。请，为了您将来的理智，今天规范化该表！

请阅读有关数据库规范化的信息