Ankündigung

Einklappen
Keine Ankündigung bisher.

On duplicate key delete

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • On duplicate key delete

    Hallo,
    eine db-table wird ab und an geupdated. Dabei werden Updates per for () ... if(whatever) ... INSERT INTO ... ON DUPLICATE KEY UPDATE gespeichert. Wenn das Update aber ein DELETE sein soll, gibt es kein ON DUPLICATE KEY DELETE für ein else. Reicht dann ein einfaches else DELETE FROM, dass jeden Wert in der for-Schleife, der nicht in if() abgefangen wird, zum DELETE schickt, oder ist ein SELECT FROM davor besser, das erstmal checkt, ob überhaupt gelöscht werden muss, denn was nicht vorhanden ist, muss nicht gelöscht werden?

  • #2
    Du musst das vorher nichts checken, denn was nicht zutrifft wird auch nicht ausgeführt.

    Beispiel:
    die ID 13 ist nicht vorhanden
    PHP-Code:
    DELETE FROM `fooWHERE `id` =13 
    Es geschieht nichts..
    Schau dir dazu auch mal mysqli_affected_rows an.
    Der Vorteil ist zudem, das aufgrund dessen das nicht vorher nachgesehen wird, es schneller ausgeführt wird, das kann bei grossen Datenbanken ohne Spalten-Index schon was ausmachen.

    Das Gleiche hättest du, wenn du den Datensatz abfragen würdest, der nicht vorhanden ist.
    Es gibt dann halt keine Rückgabe

    Kommentar


    • #3
      OK, wenn bei DELETE nichts zurückgegeben wird, dann ist das OK.
      Man könnte in diesem Fall ein "mysqli_affected_rows" davorsetzen, weil ein INSERT oder UPDATE davor geschieht, aber ist nicht nötig?

      Kommentar


      • #4
        aber ist nicht nötig?
        Genau, ist nicht nötig.

        Kommentar


        • #5
          gut, Danke für die Info!

          Kommentar


          • #6
            Zitat von protestix Beitrag anzeigen
            Du musst das vorher nichts checken, denn was nicht zutrifft wird auch nicht ausgeführt.
            Es wird nix gelöscht, ausgeführt wird es aber trotzdem. Diese kleine Feinheit kann bei hoher parallelität ein massiven Einfluss auf die Gesamtperformance haben. Ein Schreibzugriff ist i.d.R. teuerer als ein Lesezugriff, selbst wenn er nix ändert.

            Kommentar


            • #7
              Ok, richtig. Aber wenn nicht gelöscht wird, wird auch kein Schreibzugriff erfolgen. Das ein Delete teuer ist weil der Index neu geschrieben wird ist klar, aber so wie mysql in Verbindung mit InnoDB verstanden habe, wird bei einem delete erst mal ein read lock auf den Index gesetzt, genauso wie beim lesen. Hintergrund ist wohl das nicht eine Einfügeoperation dazwischenfunkt. Demzufolge sind die Kosten gleich. In beiden Fällen, Select wie Delete wird die DB feststellen, das kein Treffer erfolgt auf den Index, somit auch keine Aktion stattfinden muss. Es bleibt also bei beiden Fallen auf den read lock begrenzt.

              Ob in der Praxis bei grossen Datenmengen oder hohem Traffic da Nachteile entstehen, kann ich gar nicht testen, da die DB so schnell ist, wohl aufgrund des Indexes, dass es mir gar keine Zeit anzeigt, Ausführungszeit ist immer 0.000 Sekunden bei 500.000 Datensätzen.
              Aufgrund des Suchvorgangs und des B-Tree Indexes dürften selbst grosse Datenmengen keinen nennenswerten Nachteil haben.

              Falls ich falsch liege klärt mich gerne auf.

              Link zum Locking auf Mysql

              Kommentar


              • #8
                Wie ist es bei "MyISAM"?

                Kommentar


                • #9
                  Wer nutzt denn heute noch MyIsam?
                  https://forums.mysql.com/read.php?106,657374,657374

                  Kommentar


                  • #10
                    Zitat von protestix Beitrag anzeigen
                    Ok, richtig. Aber wenn nicht gelöscht wird, wird auch kein Schreibzugriff erfolgen.
                    Transaction Log und ggf. Binary Log.

                    Kommentar


                    • #11
                      Danke erc, konnte auch mittlerweile einen Unterschied feststellen, man muss nur mit OR mehrere Ids gleichzeitig abfragen, dann wird ein signifikanter Geschwindigkeitsunterschied deutlich.

                      Kommentar


                      • #12
                        Was bedeutet das nun bezüglich meiner Eingangsfrage?

                        Kommentar


                        • #13
                          Das heisst das du vorab ein select machst um zu prüfen ob ein delete notwendig ist.

                          Kommentar


                          • #14
                            OK, danke.

                            Kommentar

                            Lädt...
                            X