Eine Möglichkeit besteht darin, dass es andere Probleme gibt, die Leistungsprobleme verursachen - 6 Sekunden scheinen für CRUD-Vorgänge zu viel zu sein, selbst bei einer komplexen Datenbank. Denken Sie daran, dass ArsDigita (früher) 30 Treffer pro Sekunde auf einer Zwei-Wege-Sun Ultra 2 (IIRC) mit einer ziemlich bescheidenen Festplattenkonfiguration verarbeiten konnte. Ein moderner Low-Midrange-Server mit einem vernünftigen Plattenlayout und entsprechendem Tuning sollte in der Lage sein, eine beträchtliche Arbeitslast zu bewältigen.
-
Fehlt Ihnen ein Index? - Überprüfen Sie die Abfragepläne der langsamen Abfragen auf Tabellenscans, wo sie nicht sein sollten.
-
Wie ist das Festplattenlayout auf dem Server? - Müssen Sie Ihre Hardware aktualisieren oder einige Probleme mit der Festplattenkonfiguration beheben (z. B. nicht genügend Festplatten, Protokolle auf demselben Volume wie Daten).
-
Wie der andere Poster andeutet, möchten Sie vielleicht InnoDB für die stark geschriebenen Tabellen verwenden.
-
Überprüfen Sie das Setup für die Speichernutzung auf dem Datenbankserver. Möglicherweise möchten Sie mehr Cache konfigurieren.
Bearbeiten: Datenbankprotokolle sollten auf eigenen stillen Festplatten gespeichert werden. Sie verwenden ein sequentielles Zugriffsmuster mit vielen kleinen sequentiellen Schreibvorgängen. Wenn sie Festplatten mit einer Arbeitslast mit wahlfreiem Zugriff wie Datendateien gemeinsam nutzen, erzeugt der wahlfreie Festplattenzugriff einen großen Engpass bei der Systemleistung in den Protokollen. Beachten Sie, dass dies ein Schreibverkehr ist, der abgeschlossen werden muss (d. h. auf die physische Festplatte geschrieben wird), sodass Caching dabei nicht hilft.
