Frage

Mit MyISAM -Spalten mit variabler Länge (VARCHAR, BLOB) in der Tabelle verlangsamte die Abfragen sehr, so dass ich im Netz auf Ratschläge gestoßen bin, um die Varchar -Spalten in eine separate Tabelle zu verschieben.

Ist das immer noch ein Problem mit InnoDB? Ich meine keine Fälle, in denen die Einführung vieler Varchar -Zeilen in die Tabelle die Seitenaufteilung verursacht. Ich meine nur, sollte Sie beispielsweise post_text (einzelnes Blobfeld in der Tabelle) in eine andere Tabelle beachten und auf InnoDB spricht?

War es hilfreich?

Lösung

Soweit ich weiß, dass Blobs (und Texte) tatsächlich außerhalb der Tabelle gespeichert werden, werden Varchars in der Tabelle gespeichert.

Varchars sind schlecht für die Leseleistung, da jeder Datensatz von variabler Länge sein kann und es teurer macht, Felder in einem Datensatz zu finden. Blobs sind langsam, da der Wert separat abgerufen werden muss und höchstwahrscheinlich eine weitere Lektüre von Festplatten oder Cache erfordern.

Meines Wissens macht InnoDB in dieser Hinsicht nichts anders, also würde ich davon ausgehen, dass die Leistungsmerkmale gelten.

Ich denke nicht, dass sich bewegende Blobwerte wirklich hilft - außer der Verringerung der Gesamttabellengröße, was einen positiven Einfluss auf die Leistung hat, unabhängig davon. Varchars sind eine andere Geschichte. Sie werden hier auf jeden Fall profitieren. Wenn alle Ihre Spalten von definierter Länge sind (und ich denke, das bedeutet auch, dass Sie Blobs auch nicht verwenden können?), Wird die Feldschau schneller.

Wenn Sie nur die Felder von Varhcar und Blob lesen, würde ich sagen, dass dies einen Schuss wert ist. Wenn Ihre Auswahlabfrage jedoch einen Wert von einem Varchar oder einem Blob vergleichen muss, sind Sie ziemlich sauer.

Also ja, Sie können hier definitiv Leistung erzielen, aber stellen Sie sicher, dass Sie testen, dass Sie tatsächlich die Leistung gewinnen und dass der Anstieg die aggressive Denormalisierung wert ist.

Ps.

Eine andere Möglichkeit, die Performance von Varchar -Lese zu "optimieren", besteht darin, sie einfach durch Zeichenfelder (mit fester Länge) zu ersetzen. Dies könnte zu einer Leseleistung zugute kommen, solange die Zunahme des Festplattenraums akzeptabel ist.

Andere Tipps

InnoDB -Daten ganz anders als MyISAM.

In MyISAM werden alle Indizes-primär oder auf andere Weise-in der Myi-Datei gespeichert und enthalten einen Zeiger auf die in der MyD-Datei gespeicherten Daten. Zeilen der variablen Länge sollten die Abfragendrehzahl nicht direkt beeinflussen. Die MyD -Datei wird jedoch dazu neigen, mit variablen Längenzeilen stärker fragmentiert zu werden, da das Loch, das beim Löschen einer Zeile zurückgelassen wird, nicht unbedingt mit der Zeile eingereicht werden kann, die Sie als nächstes einfügen. Wenn Sie einen Wert variabler Länge aktualisieren, um länger zu gestalten, müssen Sie ihn möglicherweise an woanders hinweg verschieben, was bedeutet, dass er in Bezug auf die Indizes im Laufe der Zeit tendenziell ausdrückt, wodurch Reichweite langsamer wird. (Wenn Sie es auf einer drehenden Festplatte laufen, auf der Suchzeiten wichtig sind).

InnoDB speichert Daten, die in Seiten in einem B-Tree auf dem Primärschlüssel zusammengefasst sind. Solange die Daten in eine Seite passen, wird sie auf der Seite gespeichert, unabhängig davon, ob Sie einen Blob oder Varchar verwenden. Solange Sie nicht versuchen, regelmäßig übermäßig lange Werte einzufügen, sollte es keine Rolle spielen, ob Ihre Zeilen festgelegt oder variabler Länge sind.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top