错误代码1117太多的列；MySQL列限制表

dba.stackexchange https://dba.stackexchange.com/questions/3972

  •  16-10-2019
  •  | 
  •  

题

我有一个表1699列当我试图插入更多的列我得到的，

错误代码:1117.列太多

在这个表，我只有1000行。对我来说最重要的是列数。是否有任何限制？我想创建于2000年列。这可能吗？

有帮助吗？

解决方案

为什么你会需要创建一个表，甚至20列，让我们独自2000???

授予、非标准化的数据的可以防止不得不加以检索许多列的数据。但是，如果你拥有超过10列的，你应该停下来想想会发生什么发动机罩下在数据检索。

如果2000年的列表进行SELECT*from...在那里，就会产生大的临时表期间的处理、获取列不必要的，并创造许多情况通报(导致)将被推向边缘，在每次查询。

在我前天作为开发者，我曾在一个公司早在1995年DB2是主要的RDBMS。该公司有一个表，有270列，数十名索引和有效的问题检索数据。他们接触IBM和有顾问看过建筑自己的系统，包括这一个整体的表。该公司被告知"如果不正常化，这表在接下来的2年里，DB2将失败对查询做Stage2处理(任何查询要求的排序上的非索引列)。" 这是告诉一个多亿美元的公司，正常化的一个270列的表格。多少更多的使2000列的表格。

在mysql,你必须弥补这种不良设计，通过设置选择相当于DB2Stage2处理。在这种情况下，这些选项将是

Tweeking这些设置为弥补存在的几十个，让我们单独数以百计，列的工作好吧，如果你有TBs。

这个问题乘以几何，如果你使用少为你将要处理 MVCC(多版本并发控制) 试图保护吨列与每一个选择，更新和删除通过交易的隔离。

结论

没有任何东西可以替代或带援助，可以弥补不良的设计。请为了你的你的理智的未来，正常化，表今天！

其他提示

我在想象数据模型可以合法地包含2000列的任何内容中都遇到困难。

我的猜测是，您可能正在做某种“填充空白”模拟模拟模式，实际上您在一个表中存储了所有不同的数据，而不是将数据分解为单独的表并建立关系，您已经有各种字段记录在给定的行中存储什么“类型”数据，而90％的字段为空。不过，即使那样，要进入2000列... yikes。

解决问题的方法是重新考虑数据模型。如果您存储与给定记录相关的大量密钥/价值数据，为什么不这样对其进行建模呢？就像是：

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

然后，要获取与给定“主”记录相关联的所有传感器条目，您可以只是 SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. 。如果您需要在记录中获取数据 master 表格以及该记录的所有传感器数据，您可以使用一个JOIN：

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

如果您需要每个传感器是什么的详细信息，则进一步加入。

这是一个具有2000个传感器的测量系统

忽略所有关于归一化的评论 - 您要要求的可能是明智的数据库设计（在理想的世界中），并且完全正常化，这只是非常不寻常的，并且正如其他地方的指向RDBMS通常并不是为此众多列而设计的。 。

虽然您没有击中MySQL 硬限制, ，链接中提到的其他因素之一可能是阻止您更高

正如其他人建议的那样，您可以通过与儿童桌一起工作来解决此限制 id, sensor_id, sensor_value, ，或者更简单地，您可以创建第二个表以仅包含不适合第一个的列（并使用相同的PK）

MySQL 5.0列计数限制 （添加了重点）：

每张表有4096列的硬限, ，但是给定表的有效最大值可能较小。确切的极限取决于几个相互作用的因素。

  • 每个表（无论存储引擎如何）的最大行大小为65,535字节。 存储引擎可能会在此限制上放置其他约束，从而降低了有效的最大行尺寸。

    最大行尺寸限制了列的数字（可能是可能的大小），因为所有列的总长度不能超过此大小。

...

单个存储引擎可能会施加限制表列计数的其他限制。例子：

  • InnoDB最多允许1000列。

首先要有更多的燃烧，然后是真正的解决方案...

我主要同意已经扔给你的火焰。

我不同意键值归一化。查询最终变得可怕；性能甚至更糟。

避免直接问题的一种“简单”方法（列数的限制）是“垂直分区”数据。例如，每张5列，每列5列。他们都将具有相同的主键，除非一个人可能是auto_increment。

也许最好是决定最重要的十几个领域，将它们放入“主”表中。然后以某种逻辑方式对传感器进行分组，然后将它们放入几个并行表中。通过适当的分组，您可能不必一直加入所有桌子。

您在索引任何值吗？您需要搜索它们吗？可能您在DateTime上搜索？

如果您需要索引很多列 - 平底船。

如果您需要索引一些 - 将它们放入'主表中。

这是真正的解决方案（如果适用）...

如果您不需要索引的大量传感器，则不要制作列！是的，你听到了我。取而代之的是，将它们收集到JSON中，压缩JSON，将其存储到斑点字段中。您将节省大量空间；您只有一个表，没有列限制问题；等等。您的应用程序将取消压缩，然后将JSON用作结构。你猜怎么着？您可以拥有结构 - 就像您的应用所需的那样，可以将传感器分组为阵列，多级内容等。另一个“功能” - 它是开放式的。如果添加更多传感器，则无需更改表。 JSON如果这种方式灵活。

（压缩是可选的；如果您的数据集很大，它将有助于磁盘空间，因此可以进行整体性能。）

我认为这是大数据世界中的可能方案，您可能不会执行传统的选择 *类型的查询类型。我们在客户级别的预测建模世界中对此进行处理，在客户层面，我们在数千个维度上对客户进行建模（它们的值为0或1）。当您在同一行中拥有风险因素并在同一行中具有结果标志时，这种存储方式使下游模型构建活动变得更加容易。这可以从具有父子结构的存储位置进行标准化，但是下游的预测模型将需要将其转换为平面模式。我们使用Redshift进行柱状存储，因此加载数据时您的1000+列实际上以柱状格式存储...

这种设计有时间和地点。绝对地。归一化不是每个问题的解决方案。

许可以下： CC-BY-SA 和 归因
不隶属于 dba.stackexchange
scroll top