Heim  >  Artikel  >  Datenbank  >  MySQL – Eine detaillierte Einführung in die 10 Konfigurationen, die für das neu installierte MySQL angepasst werden müssen

MySQL – Eine detaillierte Einführung in die 10 Konfigurationen, die für das neu installierte MySQL angepasst werden müssen

黄舟
黄舟Original
2017-03-09 13:12:531093Durchsuche

Sind Sie immer noch besorgt über den neu installierten MySQL-Dienst und wissen nicht, welche Standardkonfigurationen Sie ändern müssen? Es gibt mehr als 100 einstellbare Parameter, die Sie sofort anpassen müssen! 🎜>

In diesem Artikel werden hauptsächlich 10 Konfigurationen vorgestellt, die für die MySQL-Optimierung angepasst werden müssen. Mit diesen Methoden können Sie schnell eine robuste MySQL-Konfiguration erhalten:

Wenn wir mit der Überwachung der MySQL-Leistung beauftragt werden, erwarten die Leute von uns, dass wir die MySQL-Konfiguration überprüfen und Verbesserungsvorschläge machen. Viele Menschen sind überrascht, wenn wir vorschlagen, nur wenige Einstellungen zu ändern, obwohl es Hunderte von Konfigurationsoptionen gibt. Der Zweck dieses Artikels besteht darin, Ihnen eine sehr wichtige Liste von Konfigurationselementen zu geben.

Diesen Ratschlag haben wir schon vor ein paar Jahren auf dem Blog gegeben, aber die Welt von MySQL verändert sich so schnell

Geschrieben, bevor wir anfangen...

Obwohl Sogar Erfahrene Leute können Fehler machen, die viel Ärger verursachen können. Bevor Sie diese Empfehlungen also blind anwenden, denken Sie an Folgendes:

Ändern Sie immer nur eine Einstellung auf einmal! Nur so können Sie testen, ob eine Änderung von Vorteil ist.

Die meisten Konfigurationen können zur Laufzeit mit SET GLOBAL geändert werden. Dies ist eine sehr praktische Möglichkeit, Änderungen schnell rückgängig zu machen, wenn etwas schief geht. Um es jedoch dauerhaft zu machen, müssen Sie Änderungen in der Konfigurationsdatei vornehmen.

Eine Änderung wird auch nach einem Neustart von MySQL nicht wirksam.

Bitte stellen Sie sicher, dass Sie die richtige Konfigurationsdatei verwenden. Bitte stellen Sie sicher, dass Sie die Konfiguration im richtigen Bereich platzieren (alle in diesem Artikel erwähnten Konfigurationen gehören zu [mysqld])

Der Server kann nach dem Ändern einer Konfiguration nicht gestartet werden: Bitte stellen Sie sicher, dass Sie die richtige Konfigurationseinheit verwenden.

Beispielsweise ist die Einheit von innodb_buffer_pool_size MB und max_connection hat keine Einheit.

Eine Konfigurationsdatei darf keine doppelten Konfigurationselemente enthalten. Wenn Sie Änderungen nachverfolgen möchten, verwenden Sie die Versionskontrolle.

Verwenden Sie keine naiven Berechnungen wie „Jetzt hat mein Server doppelt so viel Speicher, also muss ich alle Werte ändern, um den vorherigen Wert zu verdoppeln.“

1. Grundkonfiguration

Sie müssen die folgenden 3 Konfigurationselemente regelmäßig überprüfen. Ansonsten kann es schnell zu Problemen kommen.

innodb_buffer_pool_size:

Dies ist die erste Option, die Sie nach der Installation von InnoDB festlegen sollten.

Im Pufferpool werden Daten und Indizes zwischengespeichert: Je größer der Wert, desto besser. Dadurch wird sichergestellt, dass Sie für die meisten Lesevorgänge Speicher anstelle der Festplatte verwenden. Typische Werte sind 5–6 GB (8 GB Speicher), 20–25 GB (32 GB Speicher), 100–120 GB (128 GB Speicher).

innodb_log_file_size:

Dies ist die Größe des Redo-Logs. Redo-Logging wird verwendet, um sicherzustellen, dass Schreibvorgänge schnell und zuverlässig sind und um nach Abstürzen wiederherzustellen.

Bis MySQL 5.1 war es schwierig, es zu optimieren, weil man es einerseits größer haben wollte, um die Leistung zu verbessern, und andererseits kleiner machen wollte, um nach einem Absturz schneller wiederherzustellen. Glücklicherweise wurde seit MySQL 5.5 die Leistung bei der Wiederherstellung nach einem Absturz erheblich verbessert, sodass Sie gleichzeitig eine hohe Schreibleistung und eine Leistung bei der Wiederherstellung nach einem Absturz erzielen können. Bis MySQL 5.5 war die Gesamtgröße des Redo-Logs auf 4 GB begrenzt (standardmäßig können 2 Log-Dateien vorhanden sein). Dies wurde in MySQL 5.6 verbessert.

Setzen Sie innodb_log_file_size von Anfang an auf 512 MB (damit 1 GB Redo-Log vorhanden ist), damit Sie ausreichend Platz für Schreibvorgänge haben. Wenn Sie wissen, dass Ihre Anwendung häufig Daten schreiben muss und Sie MySQL 5.6 verwenden, können Sie es von Anfang an auf 4G einstellen.

max_connections:

Wenn Sie häufig den Fehler „Zu viele Verbindungen“ sehen, liegt das daran, dass der Wert von max_connections zu niedrig ist. Dies kommt sehr häufig vor, da die Anwendung Datenbankverbindungen nicht ordnungsgemäß schließt und Sie einen höheren Wert als die standardmäßigen 151 Verbindungen benötigen. Ein großer Nachteil, wenn der max_connection-Wert hoch eingestellt ist (z. B. 1000 oder höher), besteht darin, dass der Server nicht mehr reagiert, wenn 1000 oder mehr aktive Transaktionen ausgeführt werden. Die Verwendung von Verbindungspooling in Ihrer Anwendung oder Prozesspooling in MySQL kann zur Lösung dieses Problems beitragen.

2. InnoDB-Konfiguration

Ab MySQL Version 5.5 ist InnoDB die Standardspeicher-Engine und wird viel häufiger verwendet als jede andere Speicher-Engine. Deshalb muss es sorgfältig konfiguriert werden.

innodb_file_per_table:

Diese Einstellung teilt InnoDB mit, ob Daten und Indizes für alle Tabellen in einem gemeinsam genutzten Tabellenbereich (innodb_file_per_table = OFF) oder für jede Tabelle gespeichert werden müssen Daten werden in einer separaten .ibd-Datei abgelegt (innodb_file_per_table = ON). Mit einer Datei pro Tabelle können Sie Speicherplatz freigeben, wenn Sie Tabellen löschen, kürzen oder neu erstellen. Dies ist auch für einige erweiterte Funktionen erforderlich, beispielsweise für die Datenkomprimierung. Es bringt aber keinen Leistungsgewinn. Das Hauptszenario, in dem Sie nicht eine Datei pro Tabelle benötigen, ist, wenn Sie eine sehr große Anzahl von Tabellen haben (z. B. 10.000+).

In MySQL 5.6 ist der Standardwert dieser Eigenschaft ON, sodass Sie in den meisten Fällen nichts tun müssen. In früheren Versionen mussten Sie diese Eigenschaft vor dem Laden von Daten auf ON setzen, da sie nur neu erstellte Tabellen betraf.

innodb_flush_log_at_trx_commit:

Der Standardwert ist 1, was darauf hinweist, dass InnoDB ACID-Funktionen vollständig unterstützt. Dieser Wert ist am besten geeignet, wenn Ihr Hauptanliegen die Datensicherheit ist, beispielsweise auf einem Masterknoten. Bei Systemen mit langsamen Festplattengeschwindigkeiten (Lesen und Schreiben) wird dies jedoch einen enormen Overhead mit sich bringen, da jedes Mal, wenn Änderungen im Redo-Log gelöscht werden, zusätzliche Fsyncs erforderlich sind. Das Festlegen des Werts auf 2 führt zu einer geringeren Zuverlässigkeit, da die festgeschriebene Transaktion nur einmal pro Sekunde in das Redo-Protokoll geschrieben wird. Für einige Szenarien ist dies jedoch akzeptabel, z. B. für den Sicherungsknoten des Primärknotens . von. Ein Wert von 0 ist schneller, kann jedoch bei einem Systemabsturz zu Datenverlusten führen: Gilt nur für Backup-Knoten.

innodb_flush_method:

Diese Konfiguration bestimmt, wie Daten und Protokolle auf die Festplatte geschrieben werden. Wenn Sie über einen Hardware-RAID-Controller verfügen und dessen unabhängiger Cache einen Rückschreibmechanismus verwendet und über einen Batteriestromausfallschutz verfügt, sollte er im Allgemeinen auf O_DIRECT eingestellt werden. Andernfalls sollte er in den meisten Fällen auf fdatasync (Standardwert) eingestellt werden ). sysbench ist ein großartiges Tool, das Ihnen bei der Entscheidung für diese Option hilft.

innodb_log_buffer_size:

Diese Konfiguration bestimmt den Cache, der für Transaktionen zugewiesen wird, die noch nicht ausgeführt wurden. Der Standardwert (1 MB) ist im Allgemeinen ausreichend. Wenn Ihre Transaktion jedoch große Binärobjekte oder große Textfelder enthält, wird dieser Cache schnell voll und löst zusätzliche E/A-Vorgänge aus. Schauen Sie sich die Statusvariable Innodb_log_waits an. Wenn sie nicht 0 ist, erhöhen Sie innodb_log_buffer_size.

3. Andere Einstellungen

query_cache_size:

Abfrage-Cache (Abfrage-Cache) ist sogar ein bekannter Engpass Dies gilt auch, wenn nicht viel Parallelität besteht.

Die beste Option ist, es von Anfang an zu deaktivieren, query_cache_size = 0 festzulegen (jetzt die Standardeinstellung in MySQL 5.6) und andere Methoden zu verwenden, um Abfragen zu beschleunigen: Indizes optimieren, Kopien hinzufügen, um die Last zu verteilen, oder aktivieren zusätzlicher Cache (z. B. Memcache oder Redis). Wenn Sie den Abfragecache für Ihre Anwendung aktiviert haben und keine Probleme festgestellt haben, kann der Abfragecache für Sie hilfreich sein. Darauf sollten Sie achten, wenn Sie es deaktivieren möchten.

log_bin:

Wenn Sie möchten, dass der Datenbankserver als Backup-Knoten für den Masterknoten fungiert, ist das Einschalten des Binärprotokolls erforderlich. Vergessen Sie in diesem Fall nicht, server_id auf einen eindeutigen Wert festzulegen. Auch bei nur einem Server ist dies (Aktivieren der binären Protokollierung) nützlich, wenn Sie eine Datenwiederherstellung zu einem bestimmten Zeitpunkt durchführen möchten: Wiederherstellung von Ihrem letzten Backup (vollständige Sicherung) und Übernahme der Änderungen im Binärprotokoll (inkrementelle Sicherung). . Nach der Erstellung wird das Binärprotokoll dauerhaft gespeichert. Wenn Ihnen also nicht der Speicherplatz ausgeht, können Sie alte Dateien mit PURGE BINARY LOGS löschen oder „expire_logs_days“ festlegen, um anzugeben, nach wie vielen Tagen die Protokolle automatisch gelöscht werden.

Das Protokollieren von Binärprotokollen ist nicht ohne Overhead. Daher wird empfohlen, diese Option zu deaktivieren, wenn Sie sie auf einem Replikatknoten, der nicht der Primärknoten ist, nicht benötigen.

skip_name_resolve:

Wenn der Client eine Verbindung zum Datenbankserver herstellt, führt der Server die Auflösung des Hostnamens durch. Wenn DNS langsam ist, ist auch der Verbindungsaufbau langsam. Es wird daher empfohlen, die Option „skip_name_resolve“ zu deaktivieren, wenn Sie den Server starten, ohne eine DNS-Suche durchzuführen. Die einzige Einschränkung besteht darin, dass in GRANT-Anweisungen später nur IP-Adressen verwendet werden können. Daher ist beim Hinzufügen dieser Einstellung zu einem vorhandenen System Vorsicht geboten.

Zusammenfassung

Natürlich gibt es je nach Auslastung oder Hardware auch andere Einstellungen, die funktionieren können: langsamer Speicher und schnelle Festplatte, hohe Parallelität und schreibintensiv. Unter Last, Sie benötigen spezielle Anpassungen. Das Ziel hierbei ist jedoch, dass Sie schnell eine robuste MySQL-Konfiguration erhalten, ohne zu viel Zeit damit zu verbringen, einige unbedeutende MySQL-Einstellungen anzupassen oder die Dokumentation zu lesen, um herauszufinden, welche Einstellungen für Sie wichtig sind.


Das obige ist der detaillierte Inhalt vonMySQL – Eine detaillierte Einführung in die 10 Konfigurationen, die für das neu installierte MySQL angepasst werden müssen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn