MySQL DB Geschwindigkeit erhöhen

Hi,
ich bin auf der Suche nach Möglichkeiten um meine MySQL DB noch bisschen Feuer unterm Hintern zu machen^^

Vor einiger Zeit hat mir hier jemand den rat gebene Inizes zu setzen um so schneller Zugriffe zu erreichen.
Hab ich soweit gemacht. Nur dazu habe ich auch eine Frage. Gibt es einen Unterschied wenn ich einen Index über gleich alle Spalten einer Tabelle setze oder wenn ich für jede Spallte einen eigenen anlege? Weil irgendwie kann ich auch alle Spallten in einen Index packen und gleichzeitig noch andere Indizes anlegen... Daher HÖÖÖ???

Gibt es noch andere Möglichkeiten die ich über PHPMyAdmin machen kann (hab leider nur diesen Zugriff

)

Hoffe ihr könnt mir da weiterhelfen
mfg
Martin

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 40279

Url: https://administrator.de/forum/mysql-db-geschwindigkeit-erhoehen-40279.html

Ausgedruckt am: 23.01.2025 um 22:01 Uhr

9 Kommentare

Neuester Kommentar

Wo läuft denn MySQL? In nem Shared Hosting Account? Einem vServer? Root Server? Lokal? Linux? Windows?

öhm ja
ist linux und hab selber nur eine DB und auf die Zugriff per phpMyAdmin, hab den Kram von einem bekommen dem den ganzen root server gehört.

hoffe das hilft weiter

1a) mehr ram
1b) schnellere cpu

2) falls das nicht reicht schritt 1 wiederholen

Hi,
hmm also ich hab zwar kp von DB "optimierung" nur die Geschwindigkeit durch verschnellerung der Hardware zu erreichen finde ich etwas komisch... Also nicht das es nicht geht!
Nur irgendwie blinkt in meinem Innerren so ne kleine Lampe^^ weil normalerweise kann man Software alleine schon tunen und braucht, um das gesamte System zu verschnellern, nicht gleich neu Hardware einzusetzen. Daher will ich erstmal die reinen DB & PHP Möglichkeiten ausschöpfen.

Außerdem kommt ändern der Hardware eh nicht infrage, weil es sich um eine private Website handelt (www.diabolotreff.de) und das dort bisschen übertrieben wäre.

Kennt jemand andere Möglichkeiten auch Vorschläge die ich im Code selber beachten kann? (so allgemeine Sachen um schnelleren Zugriff zu bekommen) Hab schon gelesen Sockets oder persitente Verbindungen ehöhen die Zugrifsgeschwindigkeit auch, aber gibt da doch sicher mehr.

Hoffe ihr könnt mir da weiterhelfen ;)
mfg
Martin

Moin ThermoTubbie,

Vor einiger Zeit hat mir hier jemand den rat gebene Inizes zu setzen
um so schneller Zugriffe zu erreichen.

Bis dahin war der Rat gut.

Hab ich soweit gemacht. Nur dazu habe ich auch eine Frage.
Gibt es einen Unterschied wenn ich einen Index über gleich alle Spalten einer Tabelle setze
oder wenn ich für jede Spallte einen eigenen anlege?

Ja. Gibt es.
Variante A ("einen Index über gleich alle Spalten einer Tabelle") ist Bullshit.
Variante B ("für jede Spallte einen eigenen anlege") nur bedingt besser.

Ein Index soll der Datenbankengine ja die (intern vorprogrammierte) "Entscheidung" erleichtern, ob bei einem bestimmten SQL-Statement ein Full Table Scan erfolgen muss oder über einen Suchalgorithmus (i.d.R. B*-Baum oder auch andere Verfahren) ein selektiver Zugriff auf die "richtigen" Datensätze erfolgen kann.

Das hochtönende neudeutsche Full Table Scan heißt nichts anderes, als das jeder gottverdammte Satz in dieser Tabelle einmal in die virtuelle Hand genommen (gelesen und geprüft) wird.
Ist logischerweise langsamer, als wenn nur 5% der Sätze über einen B*-Baum überhaupt gelesen werden müssen.

Macht natürlich nur Sinn, wenn der Index kleiner ist als die Gesamt-"Breite" der Tabellenfelder (Ausnahme: reine Schlüssel-Dateien ohne jegliche Attribute).
Ein Index über eine ganze data row, den ganzen Datensatz ist Dönekens.
Wenn ALLE Felder "im Index sind" ist jede Suche über den Index "gleich teuer" wie ein Full Table Scan und die Datenbankengine wird den Index gar nicht erst benutzen.

Beispiel: Eine Kundentabelle mit
Kundennummer, kundenname, plz, ort, strasse, tel, fax, ansprechpartner, email

-> Absolutes Muss ist ja ein Unique-Index auf den PK (Kundennummer)
-> Sinn könnte machen je ein Index auf "kundenname" und "Plz"
[ Weil sicherlich SQL-Queries kommen werden mit "WHERE Kundenname Like 'Biber%'" oder "WHERE PLZ LIKE '28%'" ]

--> wenig Sinn machen Indices auf "Tel" oder "Fax" ... wer wollte denn einen Kunden ermitteln wollen, von dem er nur die ersten 4 Ziffern der Faxnummer in Erinnerung hat?

Gruß
Biber

AHHH

vielen Dank Biber, du hast mir sehr weitergeholfen !!! hab schon rumgegoogelt aber so eine klare Erklärung nicht gefunden

Ich hoffe du kannst mir auch bei paar Verständnissfragen weiterhelfen.

Also ich habe eine Tabelle wo unter anderem url, linkname,status(Fremdschlüssel) und auch kategorie(Fremdschlüssel) drin gespeichert ist. Bei einem klick auf den Link "Händler" wird dan ein sql befehl losgelassen, der nach den entsprechenden Datensätzen sucht, wo die Kategory stimmt und der Status nicht offline /fehlerhaft oder so ist. Also müsste ich dafür einen Index über "Kategorie" und "Status" legen. Stimmt das?

Und dann bei der Sortierfunktion für die einzelnen Kategorien, die als Bedinung entweder nach Kategory und Datum oder Kategory und Linkname(ASC&DESC) sucht und auf die selbe Tabelle wie oben zugreift. Müsste ich dafür 2 weitere Indizes anlegen ? Also für Kategory&Datum und Kategory&Linkname?
Also für jede Möglicheform eines in der Anwendung vorkommenden SQL Befehls jeweils ein Index oder gibt's Chaos wenn ich zuviele habe?

Bin schon auf Antworten gespannt.
mfg
Martin

Also, ThermoTubbie,

Also ich habe eine Tabelle wo unter anderem
url, linkname,status(Fremdschlüssel) und auch kategorie(Fremdschlüssel) drin gespeichert ist.
Bei einem klick auf den Link "Händler" wird dan ein sql befehl losgelassen,
der nach den entsprechenden Datensätzen sucht, wo die Kategory stimmt
und der Status nicht offline /fehlerhaft oder so ist.
Also müsste ich dafür einen Index über "Kategorie" und "Status" legen. Stimmt das?

Im Prinzip ja. Auch hierbei hilft der gesunde Menschenverstand bei der Entscheidung.
Ein Index über x Datensätze kann nur etwas bringen, wenn dadurch die Gesamtzahl der Sätze halbwegs gleichverteilt wird.
Beispiel: Ein Index auf den Kundennamen "verteilt" oder "sortiert" vereinfacht ausgedrückt alle Datensätze in Schubladen von "A" bis "Z".
Letztenendes werden aber dann nicht 26 gleich gefüllte Teilbäume herauskommen... die Buchstaben "X", "Y" und "Q" werden wenig Einträge haben..die Buchstaben "S", "T" und "C" wesentlich mehr.
Dennoch kann man/frau darauf vertrauen, selbst wenn ein Eintrag gesucht wird, der mit "S" beginnt->dieses Kriterium erfüllen schlimmstenfalls 20% aller Sätze.
Ergo: 80% der Sätze müssen nicht gelesen werden. Mit "Sch" sind nur noch 5% der Sätze relevant-->effizienter Index.

Ineffizienter Index (den Du weglassen kannst): Ein Statusfeld, in dem nur "J" oder "N" steht oder ein Feld "Status" oder "Kategorie", in dem 80% aller Sätze einen Wert haben.
Ein Index auf solche Felder wird nur dann von der Datenbankengine genutzt, wenn er Erfolg versprechender ist als ein Full Table Scan... bei J/N-Feldern wird das nie der Fall sein.

Und dann bei der Sortierfunktion für die einzelnen Kategorien,
die als Bedinung entweder nach Kategory und Datum oder Kategory und Linkname(ASC&DESC) sucht
und auf die selbe Tabelle wie oben zugreift. Müsste ich dafür 2 weitere Indizes anlegen ?
Also für Kategory&Datum und Kategory&Linkname?

Wenn Du das oben geschriebene weiterdenkst: Jein.
Schon diesen "Index-auf-zwei-Felder".
Aber nicht Kategory&Datum bzw. Kategory&Linkname.
Sondern Datum&Kategory und Linkname&Kategorie.
Um eine Ausgewogenheit, ein Balance des Indexbaums zu gewährleisten.
Bei "Datum" und "Linkname" kannst Du eine Gleichverteilung erwarten. Nicht bei "Kategory" und "Status".

Also für jede Möglicheform eines in der Anwendung vorkommenden SQL Befehls jeweils ein Index

Sieh das nicht zu dogmatisch. Wer ganz abwegige Anfragen stellt (das Beispiel von oben: "Ich weiß noch vier Ziffern von der Faxnummer des Händlers"), dem musst Du keinen Index spendieren.

oder gibt's Chaos wenn ich zuviele habe?

Chaos nicht, aber Indices verbrauchen Speicherplatz, müssen reorganisiert und verwaltet werden, beanspruchen eben auch einen Teil der von Dir bezahlten Gesamtressourcen.

HTH
Biber

Hi Biber,
danke das Hilft sehr ;) Denk mal nun hab ich's kapiert. Ich werde, wenn ich bisschen Zeit habe, mal rumtesten und schauen wie die Geschwindigkeit sich verändert.

mfg
Martin