MySQL：优化具有大量列的表答案

【问题标题】：MySQL: Optimize table with lots of columnsMySQL：优化具有大量列的表
【发布时间】：2012-01-06 12:03:44
【问题描述】：

我的用户表有超过 26 列，这正常吗？当这个用户表引起我的注意时，数据库已经规范化到第 3 级。有 26 列是否可以，或者在设计我应该做的数据库时是否使用了其他一些优化技术？

更多：对表进行分区是什么意思？

【问题讨论】：

好吧，如果你必须存储用户的 26 个唯一属性，那么拥有 26 列并没有什么问题 :) 我想说的是：我们无法在不了解上下文的情况下讲述它.但我认为您只需完成每个标准化步骤就可以自己弄清楚。
当您提出此类问题时，请始终发布 DDL。规范化基于依赖关系；规范化从不问“有多少列？”。

【解决方案1】：

26 列没有什么问题，但如果它们很少使用，那就不同了。

您不使用 26 列，而是选择使用较少的那一列，并使用序列化字符串对它们进行分组。

将该字段更改为文本字段，然后在您的代码中反序列化并使用它们。如果需要更新，则更新数组（从代码中），然后将其序列化并保存到数据库中。

【讨论】：

这种方法有什么好处？那些“很少使用”（您的意思是通常为 NULL 还是很少查询？）列不太可能影响数据库的性能。但是查询序列化数据将是一个 PITA。 :)
你的意思是我可以结合我认为移动最慢的列的字段值。通过对它们进行分组，您的意思是将它们保存为 PHP 中的字符串，然后将该字符串放入数据库？我以前从未这样做过……听起来很俗气。
我的意思是，如果您有例如：背景颜色，该值不会经常更改，因此您选择 + 反序列化然后使用它。 queyring 序列化数据与字符串相同，但您只需在插入时序列化并在读取时反转。另外：如果您需要添加更多列，则不必更改表，只需在数组中添加一个 KEY 即可完成
正如@djacobson 所说，为了删除一些列，这似乎引入了不必要的复杂性。
这是一个糟糕的建议 - 您无法在数据库级别（数据类型、可空性）验证序列化字段中的数据，您无法对其进行索引，并且如果它出现在“ where" 子句，性能会很差。