Ankündigung

Einklappen
Keine Ankündigung bisher.

ID auto_increment und sein Limit

Einklappen

Neue Werbung 2019

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

  • #46
    @erc danke nochmal für die Aufklärung. Also wenn es nur um die Geschwindigkeit des Selects geht brauche ich InnoDB garnicht, da reicht auch ein Index bei myISAM aus korrekt?
    Praxisbeispiel: ich habe 100.000 Bücherregale und suche jetzt ein Buch. Damit es schneller geht und das Suchen(selektieren) nicht komplett alle Regale abgehen muss sind diese noch in Gänge unterteilte. Ich sage mein Buch muss in Gang 530 liegen. Die Regale id 24k bis 28k haben die pid 530, also fängt das Suchen direkt ab Zeile 24k an. Auch korrekt oder ?

    Indexierung und Beziehung zwei unterschiedliche Dinge = habs verstanden

    Irritiert hat mich eben die Tatsache das man bei InnoDB direkt sagen wer und wo die referenzierte Spalte ist. Bei myISAM hingegen sag ich nur pid ist ein index.
    Das schien mir irgendwie zu ungenau um daraus einen Geschwindigkeitsbonus zu bekommen. Aber okey wenn das so funktioniert ist ja doch alles richtig wie ich meine Tabellen aufgebaut habe.

    Ob innoDB jetzt noch soooo interessant für mich ist weiss ich nicht weil die Integrität kann ich per PHP einhalten. Meine Tabellenbeziehung ist ja echt nicht komplex. Das bekomm ich mit ein oder zwei IF Abfragen auch hin. Ich überlege mir das nochmal und gehe die Praxis einmal durch.

    @eagle okey das wusst ich nicht das bei Index eine Kopie angelegt wird. Da muss man wohl scharf überlegen ob an welcher Stelle ein Index sinnvoll ist. Bei der generierung der Grundstücke ist es definitiv wichtig, weil es wird sehr viele geben und gebraucht wird ja nur die Gruppe die zum jeweiligen Gebiet gehört.
    Auch die besitzerID wird einen Index brauchen. Denn es sollen ja im Startmenü des Spielers alle seine Gebäude angezeigt werden. Das heisst die Suche geht über wirklich ALLE Grundstücke der gesamten Tabelle. Das werden ca. 4,5 Millionen sein. Da macht der Index für die Besitzer ID wirklich Sinn.
    Aber ne Kopie von 4,5 Millin Datensätze ist auch kacke, ist innoDB hierbei sparsamer oder macht der auch ne Kopie für den Index ?

    Kommentar


    • #47
      Zitat von izanagi Beitrag anzeigen
      Also wenn es nur um die Geschwindigkeit des Selects geht brauche ich InnoDB garnicht, da reicht auch ein Index bei myISAM aus korrekt?
      Nein. Vergleiche die Ausführungszeiten bei laufendem Dump.

      Aber okey wenn das so funktioniert ist ja doch alles richtig wie ich meine Tabellen aufgebaut habe.
      So verquirlt, wie Du schreibst, hab ich da Zweifel.

      Ob innoDB jetzt noch soooo interessant für mich ist weiss ich nicht weil die Integrität kann ich per PHP einhalten.
      Träum weiter.

      Aber ne Kopie von 4,5 Millin Datensätze ist auch kacke, ist innoDB hierbei sparsamer oder macht der auch ne Kopie für den Index ?
      Nein.
      PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

      Kommentar


      • #48
        Zitat von izanagi Beitrag anzeigen
        Also wenn es nur um die Geschwindigkeit des Selects geht brauche ich InnoDB garnicht, da reicht auch ein Index bei myISAM aus korrekt?
        Es gibt nicht das eine SELECT! Du kannst aber davon ausgehen das du mit InnoDB definitv besser beraten bist.

        Zitat von izanagi Beitrag anzeigen
        Praxisbeispiel: ich habe 100.000 Bücherregale und suche jetzt ein Buch. Damit es schneller geht und das Suchen(selektieren) nicht komplett alle Regale abgehen muss sind diese noch in Gänge unterteilte. Ich sage mein Buch muss in Gang 530 liegen. Die Regale id 24k bis 28k haben die pid 530, also fängt das Suchen direkt ab Zeile 24k an. Auch korrekt oder ?
        Nein. Das geht dann schon in Richtung wie ein Index selbst strukturiert ist. Ein Index kannst du dir als eine Liste die neben dem Regal hängt vorstellen und z.B. alle Titel alphabetisch listet + die genau Position des Buches. Mit der Liste könntest du schnell das Buch "Das ist ein Index" finden, aber nicht alle Bücher von Author X. Wenn du öfters nach Authoren suchst, musst du eine zweite Liste/Index erstellen, die dann nach den Authoren sortiert ist.

        Zitat von izanagi Beitrag anzeigen
        Aber ne Kopie von 4,5 Millin Datensätze ist auch kacke, ist innoDB hierbei sparsamer oder macht der auch ne Kopie für den Index ?
        Ein Index erstellt keine Kopie der Daten, der kostet aber trotzdem ordentlich Ressourcen. Du kannst auch davon aussgehen das InnoDB zwischen 10% bis 30% mehr Speicher für die selben Daten wie MyISAM braucht.

        Kommentar


        • #49
          izanagi - du träumst hier von zu erwartenden Datenbergen - sei realistisch und fang doch erstmal an kleinere Kuchen zu backen - wenn deine Datenbank irgendwann mal an Grenzen stoßen sollte, kann man immer noch mehr Hardware "draufwerfen" (weitere Festplatte rein / Clustering / etc.).

          wichtig ist ein sauberes, gut strukturiertes Grundgerüst - und dazu zähle ich bei MySQL auch InnoDB - im Gegensatz zu dem, was du gehört haben willst, musste auch mein Admin einsehen, dass InnoDB spätestens seit MySQL 5.1 schneller als MyISAM bei vergleichbaren Abfragen ist. Obendrein leisten die die Möglichkeiten der Fremdschlüssel gute Dienste bei der Strukturierung und helfen dir die Korrektheit der Daten abzusichern
          "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste [IMG]http://www.php.de/core/images/smilies/icon_lol.gif[/IMG]

          Kommentar


          • #50
            Ich habe den Beitrag gelöscht um euch nicht mit dem Abfall zu belästigen. Es kam heraus das

            Und magic_quotes_gpc fruchtet wohl nur wenn ich den Querie per bind_param ergänze. Mein Test lief aber als fertiger Querie String.
            Die komprimierten Daten von gzdeflate hatte nämlich " Sonderzeichen als Inhalt und ergab immer nur willkürlich Prepare Fehler.
            Selbst ein Austausch im String von abc zu abd brachte es ein einzige Buchstabe bereits zum Chaos. Das hab ich nach 6 verdammten Stunden erst rausgefunden.
            Wer denkt auch daran das der Kompressor Quotes benutzt zum komprimieren. junge junge

            Kommentar

            Lädt...
            X