pl: Insert Multiple Server is gone

Multiple Inserts sind echt der Hammer, 10000 Records einzufügen geht ja selbst auf meiner alten Kiste in Bruchteilen von Sekunden. Aber irgendwo gibt es da eine Grenze, ich vermute mal das hängt mit der Länge des Strings zusammen welcher die Values präsentiert.

Ich kann mich erinnern, daß wir in der Firma mit Oracle ähnliche Probleme hatten, aber hier gehts mir konkret um MySQL (5.1.40-community). Wo issn das konfiguriert? Bitte mal um Hinweise, VfG

  1. Hello Rolf,

    Multiinserts-/Updates sind nur solange "geil", wie man spezielle Regeln dafür einhält. Wenn, man z. B. keine spezielle Spalte für z. B. "Insertnumber" vorhält und mitführt, weiß man nachher nicht, welche denn fehlerfrei durchgeführt wurden...

    Es gibt mMn bei MySQL bisher keine Möglichkeit, eine garantierte Reihenfolge und einen verlässlichen Fail-Point festzulegen / zu ermitteln.

    guck mal in dein Information Scheme unter GLOBAL_VARIABLES und such nach max_allowed_packet

    Das sollte die Obergrenze in Bytes für ein zu verarbeitendes Datenpaket sein. Ob es noch subsidiare Beschränkungen gibt, weiß ich jetzt nicht aus dem Handgelenk.

    Liebe Grüße
    Tom S.

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. Hi Tom,

      Multiinserts-/Updates sind nur solange "geil", wie man spezielle Regeln dafür einhält. Wenn, man z. B. keine spezielle Spalte für z. B. "Insertnumber" vorhält und mitführt, weiß man nachher nicht, welche denn fehlerfrei durchgeführt wurden...

      Das habch grad gemerkt, da kommt z.B. gar keine FM wenn eine einzufügende Zahl den type tiniyint sprengt. Still und leise steht da ne 127 bei jeder Zahl die beim Insert größer war und keine Sau merkt das!

      Es gibt mMn bei MySQL bisher keine Möglichkeit, eine garantierte Reihenfolge und einen verlässlichen Fail-Point festzulegen / zu ermitteln.

      Problematisch ist auch last_insert_id()

      guck mal in dein Information Scheme unter GLOBAL_VARIABLES und such nach max_allowed_packet

      Na wenigstens wissenmer jetzt wos konfigured ist. Aber das Hauptproblem ist tatsächlich die Fehlerbehandlung.

      Danke Dir 😉

    2. Multiinserts-/Updates sind nur solange "geil", wie man spezielle Regeln dafür einhält. Wenn, man z. B. keine spezielle Spalte für z. B. "Insertnumber" vorhält und mitführt, weiß man nachher nicht, welche denn fehlerfrei durchgeführt wurden...

      Das kommt auf die Storage Engine an, bei InnoDB werden entweder alle oder keine Inserts ausgeführt.

      Es gibt mMn bei MySQL bisher keine Möglichkeit, eine garantierte Reihenfolge und einen verlässlichen Fail-Point festzulegen / zu ermitteln.

      InnoDB kennt Transaktionen.

      1. Hello,

        Das kommt auf die Storage Engine an, bei InnoDB werden entweder alle oder keine Inserts ausgeführt.

        Und weiß man dann auch, welches Teil-Insert-Statement abgelehnt wird und ob es ggf, noch weitere gibt?

        Liebe Grüße
        Tom S.

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
        1. Und weiß man dann auch, welches Teil-Insert-Statement abgelehnt wird und ob es ggf, noch weitere gibt?

          Ich gehe mal davon aus, dass InnoDB nur den zuerst auftretenden Fehler meldet und dann sofort abbricht. Dafür würde ich meine Hand aber nicht ins Feuer legen. Bei evtl. Fehlern, die noch folgen könnten, wäre es schwierig für InnoDB zu wissen, ob es sich um Folgefehler oder unabhängige Fehler handelt.

  2. Hallo pl,

    Multi-Inserts sind geil für kleinere Datenmengen - wenn man z.B. tabellarische Daten aus einem Eingabeformular in die DB schreiben will.

    Für alles andere, insbesondere dann, wenn aus Multi Masse wird, gibt's eigentlich LOAD. Wie da das Errorhandling ist, kann ich aber auch nicht sagen.

    Rolf

    --
    sumpsi - posui - clusi
    1. Moin,

      Multi-Inserts sind geil für kleinere Datenmengen - wenn man z.B. tabellarische Daten aus einem Eingabeformular in die DB schreiben will.

      Für alles andere, insbesondere dann, wenn aus Multi Masse wird, gibt's eigentlich LOAD. Wie da das Errorhandling ist, kann ich aber auch nicht sagen.

      Nunja, wenn, wie ich gestern schon schrieb, eine Typeverletzung gar nicht erst erkannt wird, ist eine Fehlerbehandlung überhaupt nicht möglich -- trotz RaiseError (errmode exception).

      MfG

      1. Hallo pl,

        ja ok, aber ist das nur bei INSERT so oder auch bei LOAD?

        Rolf

        --
        sumpsi - posui - clusi
        1. Hi ;

          ja ok, aber ist das nur bei INSERT so oder auch bei LOAD?

          Das Heimtückische beim multiple insert ist, daß, zumindest in meinem Fall, die Typeverletzung nicht nur nicht kommuniziert sondern auch unbemerkt korrigiert wird. Also, anstatt einen zu großen Integer anzumeckern wurde stattdessen einfach der maximal mögliche Wert eingefügt. Offensichtlich ist das aber ein Perl::DBI spez. Problem, mein Query Browser verhält sich da erwartungsgemäß und meldet den Fehler.

          Was LOAD betrifft, müsste man max_allowed_packet abfragen und gegen die Länge der ganzen Query vergleichen Alles in Allem ist, so denke ich, multiple insert nichts für ein Universal Modul, sondern nur speziellen Anwendungen vorbehalten, weil es Einiges an Aufwand efordert um es sicher zu machen.

          Issue last_insert_id siehe MySQL::Dokumentation. MfG