Code d'erreur 1117 Trop de colonnes; MySQL colonne limite sur la table

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

  •  16-10-2019
  •  | 
  •  

Question

J'ai une table avec 1699 colonnes et quand je suis en train d'insérer plusieurs colonnes que je reçois,

  

Erreur de code: 1117. Trop de colonnes

Dans ce tableau, j'ai seulement 1000 lignes. Pour moi, la chose la plus importante est le nombre de colonnes. Y a-t-il des limites sur la table? Je veux créer 2000 colonnes. Est-ce possible?

Était-ce utile?

La solution

Pourquoi auriez-vous besoin de créer une table même avec 20 colonnes, et encore moins 2000 ???

Accordé, les données dénormalisées peut éviter d'avoir à faire JOIN pour récupérer de nombreuses colonnes de données. Toutefois, si vous avez plus de 10 colonnes, vous devez arrêter et de réfléchir à ce qui se passerait sous le capot lors de la récupération de données.

Si une table de colonne 2000 subit SELECT * FROM ... WHERE, vous générer de grandes tables temporaires pendant le traitement, l'extraction des colonnes qui ne sont pas nécessaires, et la création de nombreux scénarios dans lesquels les paquets de communication (max_allowed_packet ) serait poussé au bord de chaque requête.

Dans mes premiers jours en tant que développeur, je travaillais à un retour de l'entreprise en 1995 où DB2 était le SGBDR principal. La société avait une seule table qui avait 270 colonnes, des dizaines d'indices, et les problèmes avaient des performances de récupération des données. Ils ont contacté IBM et a des consultants donnent sur l'architecture de leur système, y compris celui d'une table monolithique. La société a été dit: « Si vous ne normalise ce tableau dans les 2 prochaines années, DB2 échouera sur les requêtes faisant Stage2 traitement (toutes les requêtes nécessitant du tri sur des colonnes non indexées). » Cela a été dit à une société de plusieurs billions de dollars, pour normaliser une table de colonne 270. Combien plus une table de colonne 2000.

En termes de MySQL, vous auriez à compenser cette mauvaise conception en définissant des options comparables à DB2 Stage2 traitement. Dans ce cas, ces options seraient

tweeking ces paramètres pour compenser la présence de dizaines, sans parler des centaines, des colonnes fonctionne bien si vous avez téraoctets de RAM.

Ce problème se multiplie géométriquement si vous utilisez InnoDB que vous devrez traiter MVCC (Multiversion Contrôle d'accès simultané) essayer de tonnes de colonnes avec Protéger chaque SELECT, UPDATE et DELETE par l'isolement de la transaction.

Conclusion

Il n'y a pas de substitut ou sparadrap qui peut compenser une mauvaise conception. S'il vous plaît, pour l'amour de votre santé mentale à l'avenir, Normaliser cette table aujourd'hui !!!

Autres conseils

Je ne parviens pas à quoi que ce soit d'imaginer où le modèle de données pourrait contenir légitimement 2000 colonnes dans une table correctement normalisée.

Je suppose que vous faites probablement une sorte de « remplir les blancs » schéma dénormalisé, où vous stockez réellement toutes les différentes sortes de données dans une table, et au lieu de casser les données sur des tables séparées dans et faire des relations, vous avez différents domaines qui enregistrent ce « type » de données sont stockées dans une ligne donnée, et 90% de vos champs sont NULL. Même alors, cependant, de vouloir se rendre à 2000 colonnes ... beurk.

La solution à votre problème est de repenser votre modèle de données. Si vous stockez un grand tas de données clé / valeur qui est associée à un enregistrement donné, pourquoi modélise pas cette façon? Quelque chose comme: 

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>
);

Ensuite, pour obtenir toutes les entrées de capteur associé à un enregistrement donné « maître », vous pouvez juste SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. Si vous avez besoin pour obtenir les données pour un enregistrement de la table de master ainsi que toutes les données du capteur pour cet enregistrement, vous pouvez utiliser une jointure: 

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>

Et puis rejoint plus si vous avez besoin de détails de ce que chaque capteur est.

  

Il est un système de mesure avec 2000 capteurs

Ignorer tous les commentaires criant au sujet de la normalisation - ce que vous demandez pourrait être la conception de base de données sensible (dans un monde idéal) et parfaitement normalisé, il est juste très inhabituel, et comme l'a souligné ailleurs SGBDR sont généralement tout simplement pas conçu pour un nombre de colonnes.

Bien que vous ne frappez pas MySQL limite dure, une des autres facteurs mentionnés dans le lien qui vous empêche probablement d'aller plus haut

Comme d'autres suggèrent, vous pouvez contourner cette limitation en ayant une table enfant avec id, sensor_id, sensor_value, ou plus simplement, vous pouvez créer une deuxième table pour contenir seulement les colonnes qui ne rentrent pas dans le premier (et utiliser la même PK)

MySQL 5.0 Limites column-count (italique ajouté):

  

Il y a une limite 4096 colonnes par table , mais le maximum efficace peut être moins pour une table donnée. La limite exacte dépend de plusieurs facteurs qui interagissent entre eux.

     
      

  • Chaque table (quel que soit le moteur de stockage) a une taille de ligne maximale de 65535 octets. moteurs de stockage peuvent imposer des contraintes supplémentaires sur cette limite, ce qui réduit la taille maximale de ligne efficace.

         

    La taille de ligne maximale contraint le nombre (et éventuellement la taille) des colonnes en raison de la longueur totale de toutes les colonnes ne peut dépasser cette taille.

    •   
     

...

     

Les moteurs de stockage individuels pourraient imposer des restrictions supplémentaires que le nombre de colonnes de table limite. Exemples:

     
      
  • InnoDB permet jusqu'à 1000 colonnes.
    •   

D'abord un peu plus flamboyant, puis une véritable solution ...

Je suis d'accord avec la plupart du temps les flammes déjà jeté à vous.

Je suis en désaccord avec la normalisation de la valeur clé. Recherches finir par être terrible; la performance encore pire.

Un « simple » façon d'éviter le problème immédiat (limitation du nombre de colonnes) est de « partition verticalement après les » données. Avez, disons, 5 tables avec 400 colonnes chacune. Ils ont tous la même clé primaire, sauf qu'on pourrait avoir être AUTO_INCREMENT.

Peut-être mieux serait de décider de la douzaine de champs qui sont les plus importants, les mettre dans la table « principale ». Ensuite groupe les capteurs d'une certaine façon logique et les mettre dans plusieurs tables parallèles. Avec le regroupement approprié, vous pourriez ne pas avoir à se joindre à toutes les tables tout le temps.

Êtes-vous indexer une quelconque des valeurs? Avez-vous besoin de chercher sur eux? Probablement vous effectuez une recherche sur datetime?

Si vous avez besoin de beaucoup d'index de colonnes -. Punt

Si vous avez besoin d'indexer quelques-unes -. Les mettre dans la « table principale

Voici la vraie solution (si elle applique) ...

Si vous n'avez pas besoin de la vaste gamme de capteurs indexés, alors ne faites pas de colonnes! Oui, vous me avez entendu. Au lieu de cela, les recueillir dans JSON, compresser le JSON, le stocker dans un champ blob. Vous économiserez une tonne d'espace; vous aurez une seule table, avec des problèmes de limites ne colonne; etc. Votre demande sera décompressez, puis utilisez la JSON comme une structure. Devine quoi? Vous pouvez avoir une structure - vous pouvez regrouper les capteurs dans des tableaux, des choses à plusieurs niveaux, etc., tout comme votre application souhaitez. Une autre « caractéristique » - il est ouvert. Si vous ajoutez d'autres capteurs, vous n'avez pas besoin de modifier la table. JSON si souple de cette façon.

(La compression est facultative. Si votre ensemble de données est énorme, il aidera à l'espace disque, d'où la performance globale)

Je vois cela comme un scénario possible dans le monde des grandes données, où vous ne pouvez pas effectuerons la sélection traditionnelle de type * de requêtes. Nous traitons ce dans le monde de la modélisation prédictive à un niveau client où nous modélisons un client à travers des milliers de dimensions (tous ayant des valeurs de 0 ou 1). De cette façon, de stockage rend le modèle en aval des activités de renforcement etc plus facile lorsque vous avez les facteurs de risque dans la même ligne et le drapeau de résultat dans la même ligne et .. Ceci peut être normalisé à partir d'un point de support de stockage avec une structure parent-enfant, mais le modèle prédictif aval devra reconvertir en schéma plat. Nous utilisons redshift qui fait le stockage en colonnes, de sorte que vos colonnes 1000 lorsque vous chargez les données, en fait sont stockées dans un format colonnade ...

Il y a un temps et un lieu pour cette conception. Absolument. La normalisation est pas la solution pour chaque problème.

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top