Tipps:
1. Wie erkennt man ineffiziente Anweisungen?
Unter MySQL können Sie durch Festlegen von --log-slow-queries=[Dateiname] in den Startparametern SQL-Anweisungen, deren Ausführungszeit long_query_time (Standard ist 10 Sekunden) überschreitet, in der angegebenen Protokolldatei aufzeichnen. Sie können die lange Abfragezeit auch in der Startkonfigurationsdatei ändern, z. B.:
# Lange Abfragezeit auf 8 Sekunden setzen
long_query_time=8
2. Wie frage ich den Index einer Tabelle ab?
Sie können die SHOW INDEX-Anweisung verwenden, z. B.:
SHOW INDEX FROM [Tabellenname]
3. Wie frage ich die Indexverwendung einer bestimmten Anweisung ab?
Sie können die EXPLAIN-Anweisung verwenden, um die Indexverwendung einer bestimmten SELECT-Anweisung anzuzeigen. Handelt es sich um eine UPDATE- oder DELETE-Anweisung, muss diese zunächst in eine SELECT-Anweisung umgewandelt werden.
4. Wie exportiere ich den Inhalt der INNODB-Engine in die Fehlerprotokolldatei?
Mit dem Befehl SHOW INNODB STATUS können wir viele nützliche Informationen über die INNODB-Engine anzeigen, z. B. den aktuellen Prozess, Transaktionen, Fremdschlüsselfehler und Deadlocks Probleme und andere Statistiken. Wie kann die Aufzeichnung dieser Informationen in der Protokolldatei aktiviert werden? Solange Sie die Tabelle innodb_monitor mit der folgenden Anweisung erstellen, schreibt MySQL das System alle 15 Sekunden in die Fehlerprotokolldatei:
CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
Wenn Sie keinen Export mehr in die Fehlerprotokolldatei benötigen , einfach löschen Diese Tabelle kann sein:
DROP TABLE innodb_monitor
5. Wie lösche ich regelmäßig große Protokolldateien?
Legen Sie einfach die Protokollablaufzeit in der Startkonfigurationsdatei fest:
Expire_logs_days=10
Hinweise:
1. Konzentrieren Sie sich auf den Index
. Im Folgenden wird die Tabelle TSK_TASK als Beispiel verwendet, um den SQL-Anweisungsoptimierungsprozess zu veranschaulichen. Die TSK_TASK-Tabelle wird zum Speichern von Systemüberwachungsaufgaben verwendet:
ID: Primärschlüssel;
STATUS_ID:erstellte
Fremdschlüsselbeziehung;
Hinweis: MySQL erstellt automatisch Indizes für Fremdschlüssel. Bei diesem Optimierungsprozess wurde festgestellt, dass diese automatisch erstellten Fremdschlüsselindizes die Effizienz von SQL-Anweisungen unnötig beeinträchtigen.
Zunächst haben wir in der Protokolldatei festgestellt, dass die Ausführung der folgenden Anweisung relativ langsam war, mehr als 10 Sekunden:
# Query_time: 18 Lock_time: 0 Rows_sent: 295 Rows_examined: 88143
select * from TSK_TASK WHERE STATUS_ID = 1064 and MON_TIME >= ' 2007-11 -22' und MON_TIME < '2007-11-23'
Es stellt sich heraus, dass unter 88143 Datensätzen 295 Datensätze gefunden werden müssen, die die Bedingungen erfüllen, was natürlich langsam ist. Verwenden Sie schnell die EXPLAIN-Anweisung, um die Indexverwendung zu überprüfen:
+----+-------------+----------+------+- --------
|. key_len
|
---------+----------
1 |
. +-------------+----------+------+--------- --Das
ist dort zu sehen Es stehen zwei Indizes zur Verfügung: FK_task_status_id_TO_SYS_HIER_INFO, TSK_TASK_KEY_MON_TIME. Der Fremdschlüsselindex für STATUS_ID wird verwendet, wenn die Anweisung endgültig ausgeführt wird.
Schauen wir uns noch einmal den Index der TSK_TASK-Tabelle an:
+----------+-------------------------- -- -------
|. Schlüsselname |
. ------------
|.
TSK_TASK
|.
-------------------------
Unter Oracle oder anderen relationalen Datenbanken spielt die Reihenfolge der Felder im Index bei WHERE-Bedingungen eine wichtige Rolle bei der Auswahl der Index. Passen wir die Feldreihenfolge an, fügen Sie STATUS_ID am Ende ein und EXPLAIN erneut:
EXPLAIN select * from TSK_TASK WHERE MON_TIME >= '2007-11-22' and MON_TIME < '2007-11-23' and STATUS_ID = 1064;
but it has Keine Auswirkung: MySQL verwendet weiterhin den vom System erstellten Fremdschlüsselindex STATUS_ID.
Nach sorgfältiger Analyse scheint das Kardinalitätsattribut (dh die Anzahl der eindeutigen Werte im Index) eine äußerst wichtige Rolle bei der Auswahl des Index zu spielen. MySQL wählt den Index mit der geringeren Anzahl eindeutiger Werte aus im Index als Index der gesamten Anweisung.
Wenn Sie für diese Anweisung FK_task_status_id_TO_SYS_HIER_INFO als Index verwenden und die TSK_TASK-Tabelle Daten über viele Tage speichert, ist die Anzahl der gescannten Datensätze groß und die Geschwindigkeit gering. Es stehen mehrere Optimierungslösungen zur Verfügung:
Wenn an einem Tag nicht viele Aufgaben anfallen, löschen wir den Index FK_task_status_id_TO_SYS_HIER_INFO, dann verwendet MySQL den Index TSK_TASK_KEY_MON_TIME und scannt dann die Datensätze mit STATUS_ID 1064 in den Daten dieses Tages, was nicht langsam ist ;
Wenn an einem Tag viele Aufgaben anfallen, müssen wir die Indizes FK_task_status_id_TO_SYS_HIER_INFO und TSK_TASK_KEY_MON_TIME löschen und dann einen gemeinsamen Index von STATUS_ID, MON_TIME erstellen, was auf jeden Fall sehr effizient ist.
Daher wird empfohlen, für Tabellen mit einer großen Anzahl von Datensätzen keine Fremdschlüssel zu verwenden, um eine ernsthafte Beeinträchtigung der Leistungseffizienz zu vermeiden.
2. Versuchen Sie, die Anzahl der Datensätze in jeder Tabelle zu kontrollieren.
Wenn die Anzahl der Datensätze in einer Tabelle groß ist, ist die Verwaltung und Wartung beispielsweise sehr zeitaufwändig und führt zu großen Störungen Normaler Betrieb des Systems.
Bei Tabellen, deren Datenvolumen im Laufe der Zeit weiter zunimmt, können wir Echtzeitdaten und historische Daten anhand der Zeit unterscheiden. Mit dem Hintergrunddienstprogramm können wir die Daten in der Echtzeittabelle regelmäßig in die historische Tabelle verschieben und so steuern die Anzahl der Datensätze in der Echtzeittabelle und die Verbesserung der Abfrageleistung und der betrieblichen Effizienz. Beachten Sie jedoch, dass die Zeit jeder Bewegung kurz genug sein sollte, um das Datenschreiben des normalen Programms nicht zu beeinträchtigen. Wenn es zu lange dauert, kann es zu einem Deadlock-Problem kommen.
3. Daten-Hashing-(Partitionierungs-)Strategie:
Wenn die Anzahl der Kunden einen bestimmten Umfang erreicht, kann eine einzelne Datenbank keinen höheren gleichzeitigen Zugriff mehr unterstützen. Zu diesem Zeitpunkt können Sie erwägen, die Kundendaten in mehrere Datenbanken zu hashen (partitionieren). Teilen Sie die Last. Verbessern Sie die Gesamtleistung und Effizienz des Systems.