Zusammenfassung verschiedener MySQL-Probleme und -Lösungen

Ursprünglicher Link zu diesem Artikel: https://blog.csdn.net/xzk9381/article/details/114872726

1. MySQL 5.7 Thread Blocking Solution

1.1 Problembeschreibung

Beim Ausführen der Anweisung in der Datenbank wird ein Fehler gemeldet: FEHLER 1205 (HY000): Wartezeitüberschreitung der Sperre überschritten; Versuch, die Transaktion neu zu starten.

1.2 Lösung

Zeigen Sie die Threads in der aktuellen Datenbank an

show full processlist;

Wenn der langsame SQL-Datensatzthread nicht ausgeführt wird, überprüfen Sie in der Transaktionstabelle INNODB_TRX, ob ein Transaktionsthread gesperrt ist, und prüfen Sie, ob sich trx_mysql_thread_id im Sleep-Thread in der Liste show full process befindet. Es beweist, dass die Thread-Transaktion dieses Ruhezustands ohne Festschreiben oder Zurücksetzen stecken geblieben ist. Wir müssen sie manuell beenden, z. B. 32735

2. MySQL 5.7 ist langsam, wenn eine Remoteverbindung zur Datenbank hergestellt wird

2.1 Problembeschreibung

Verwenden Sie den Befehl mysql, um remote auf die Datenbank zuzugreifen. Nachdem Sie das Kennwort eingegeben haben, müssen Sie auf 5s-10s warten, um die Verbindung herzustellen, sodass der Hintergrunddienst eine Ausnahme auslöst.

2.2 Ursachen des Problems

Jedes Mal, wenn mysql auf die Datenbank zugreift, versucht es, den Domänennamen des Computers, auf den zugegriffen wird, aufzulösen. Wenn es zu diesem Zeitpunkt nicht aufgelöst werden kann, schlägt es nach einer Weile fehl, bevor die Daten abgerufen werden können.

2.3 Lösung

Fügen Sie das Konfigurationselement zum Auflösen von Sprungnamen unter [mysqld] in der MySQL-Konfigurationsdatei hinzu, um die Auflösung von Domänennamen zu verhindern, und starten Sie die Datenbank neu, damit sie wirksam wird

3. Fehler bei der binären Installation von MySQL 5.7

3.1 Problembeschreibung

Verwenden Sie das binäre Installationspaket, um MySQL 5.7 in Centos6.8 (minimale Installation) zu installieren und einen Fehler zu melden:

Fehler beim Laden von gemeinsam genutzten Bibliotheken: libaio.so.1: freigegebene Objektdatei kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis

3.2 Lösung

Die libaio-Bibliothek wird während der minimalen Installation von CentOS nicht standardmäßig installiert, und Sie müssen sie manuell installieren

yum install libaio-devel

4. Lösung des Problems abgeschnittener Daten mithilfe der Group Concat-Funktion in MySQL 5.7

4.1 Problembeschreibung

Wenn die Funktion GROUP_CONCAT für die Abfrage aufgerufen wird, wird die Abfrage nicht gestoppt und es werden keine Daten zurückgegeben (es gibt auch eine Situation, in der die abgefragten Daten abgeschnitten werden und die längste Länge 1024 Byte nicht überschreitet).

4.2 Ursache des Problems

Der Grund für dieses Problem ist, dass die offizielle Standardkonfiguration group_concat_max_len 1024 ist, wodurch die Länge der GROUP_CONCAT-Daten begrenzt wird. Sie können den folgenden Befehl zum Abfragen verwenden:

mysql> show variables like 'group_concat_max_len';
+----------------------+--------+
| Variable_name        | Value  |
+----------------------+--------+
| group_concat_max_len |  1024  |
+----------------------+--------+
1 row in set (0.05 sec)

# 官方手册对该配置的定义是：The maximum permitted result length in bytes for the GROUP_CONCAT() function

4.3 Lösung

Sie können group_concat_max_len auf den Maximalwert von 18446744073709551615 einstellen (oder entsprechend der maximalen Länge der tatsächlichen Rendite des Geschäfts festlegen).

Ändern Sie die MySQL-Konfigurationsdatei und fügen Sie unter [mysqld] group_concat_max_len = 18446744073709551615 (permanent wirksam) hinzu.
In der Konsole einstellen (vorübergehend wirksam)

SET GLOBAL group_concat_max_len=18446744073709551615;
SET SESSION group_concat_max_len=18446744073709551615;

5. MySQL 报 FEHLER: Paket für Abfrage ist zu groß (2034> 1024)

5.1 Problembeschreibung

Beim Speichern der Daten wird ein Fehler gemeldet:

FEHLER: Paket für Abfrage ist zu groß (2034> 1024). Sie können diesen Wert auf dem Server ändern, indem Sie die Variable max_allowed_packet 'festlegen.

5.2 Lösung

Verwenden Sie den folgenden Befehl, um die Einstellung max_allowed_packet in der aktuellen Datenbank anzuzeigen

mysql> show variables like '%max_allowed_packet%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| max_allowed_packet       | 1024       |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
2 rows in set (0.00 sec)

# 这里显示max_allowed_packet的大小只有1M

Fügen Sie max_allowed_packet = 128M in der Konfigurationsdatei my.cnf [mysqld] hinzu oder ändern Sie es, und starten Sie mysql neu, damit es wirksam wird. Wenn der Wert von max_allowed_packet nach einiger Zeit auf 1024 wiederhergestellt wird, müssen Sie abfragen, ob der Speicher des aktuellen Servers nicht ausreicht. Dies führt dazu, dass MySQL den Parameter automatisch auf 1024 zurücksetzt und genügend Speicher reserviert, um das Problem zu lösen.

6. MySQL 5.7-Fehler "Warten auf Sperre der Tabellenmetadaten"

6.1 Problembeschreibung

Wenn Sie DDL-Operationen wie die Alt-Tabelle in MySQL 5.7 ausführen, ist die Operation blockiert und kann nicht ausgeführt werden. Verwenden Sie show processlist, um anzuzeigen und festzustellen, dass die Alt-Tabellenoperation der Tabelle das Warten auf die Sperre von Tabellenmetadaten anzeigt.

6.2 Ursache des Problems

Wenn bei der Ausführung von DDL-Vorgängen wie der Alt-Tabelle in MySQL 5.7 nicht festgeschriebene Transaktionen in der Tabelle vorhanden sind, wird der Sperrstatus Warten auf Tabellenmetadaten angezeigt

6.3 Lösung

Verwenden Sie den folgenden Befehl, um nicht festgeschriebene Transaktionen aus information_schema.innodb_trx anzuzeigen. Solange diese Threads beendet werden, warten DDL-Vorgänge im Allgemeinen nicht auf die Sperre von Tabellenmetadaten

select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx \G

# 字段说明：
# trx_state: 事务状态，一般为RUNNING
# trx_started: 事务执行的起始时间，若时间较长，则要分析该事务是否合理
# trx_mysql_thread_id: MySQL的线程ID，用于kill
# trx_query: 事务中的sql

Passen Sie den Schwellenwert für das Sperrzeitlimit an. lock_wait_timeout stellt das Zeitlimit (in Sekunden) für die Erfassung der Metadatensperre dar, und der zulässige Wertebereich liegt zwischen 1 und 31536000 (1 Jahr). Der Standardwert ist 31536000, stellen Sie ihn auf 30 Minuten ein

set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;

Ursprünglicher Link zu diesem Artikel: https://blog.csdn.net/xzk9381/article/details/114872726

7. Lösung des MySQL-Fehlers 1418 (HY000)

7.1 Problembeschreibung

Nachdem MySQL das bin-log geöffnet hat, tritt beim Aufrufen gespeicherter Prozeduren oder Funktionen und Trigger ein Fehler mit der Fehlernummer 1418 auf:

FEHLER 1418 (HY000): Diese Funktion enthält keine DETERMINISTIC-, NO SQL- oder READS-SQL-Daten in ihrer Deklaration, und die binäre Protokollierung ist aktiviert ( möglicherweise möchten Sie die weniger sichere Variable log_bin_trust_function_creators verwenden).

7.2 Ursache des Problems

Da CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, ALTER FUNCTION, CALL, DROP PROCEDURE, DROP FUNCTION und andere Anweisungen in das Binärprotokoll geschrieben und dann auf dem Slave-Server ausgeführt werden. Eine unbestimmte Unterroutine (gespeicherte Prozedur, Funktion, Trigger), die eine Aktualisierung durchführt, ist jedoch nicht wiederholbar. Die Ausführung auf dem Slave-Server (relativ zum Master-Server ist eine wiederholte Ausführung) kann dazu führen, dass sich die wiederhergestellten Daten von den ursprünglichen Daten unterscheiden. A. Situation, in der sich der Server vom Hauptserver unterscheidet.

Um dieses Problem zu lösen, schreibt MySQL vor, dass auf dem Hauptserver die Erstellung oder Ersetzung des Unterprogramms abgelehnt wird, sofern das Unterprogramm nicht als deterministisch deklariert wird oder die Daten nicht ändert. Dies bedeutet, dass Sie beim Erstellen eines Unterprogramms entweder deklarieren müssen, dass es deterministisch ist oder dass es die Daten nicht ändert.

Es gibt zwei Möglichkeiten, dies zu deklarieren:

Die Anweisung ist deterministisch: DETERMINISTIC und NOT DETERMINISTIC geben an, ob eine Subroutine für eine bestimmte Eingabe immer das gleiche Ergebnis liefert. Wenn keine Funktion angegeben ist, lautet die Standardeinstellung NICHT DETERMINISTIC. Daher muss DETERMINISTIC explizit angegeben werden, um zu deklarieren, dass eine Unterroutine deterministisch ist. Was ich hier erklären möchte, ist: Die Verwendung der Funktion NOW () (oder ihrer Synonyme) oder der Funktion RAND () macht ein Unterprogramm nicht nicht deterministisch. Für NOW () enthält das Binärprotokoll einen Zeitstempel und wird korrekt ausgeführt. RAND () kann korrekt kopiert werden, solange es einmal in einem Unterprogramm aufgerufen wird. Daher kann davon ausgegangen werden, dass der Zeitstempel und der Zufallszahlen-Startwert deterministische Eingaben in das Unterprogramm sind und auf dem Master-Server und dem Slave-Server gleich sind.
Deklarieren Sie, ob die Daten geändert werden sollen: CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL wird verwendet, um anzugeben, ob das Unterprogramm Daten liest oder schreibt.
Sowohl NO SQL als auch READS SQL DATA weisen darauf hin, dass die Unterroutine die Daten nicht ändert, aber eine davon muss explizit angegeben werden, da die Standardspezifikation CONTAINS SQL ist, falls eine angegeben ist.

Mit anderen Worten, wenn bin-log aktiviert ist, müssen Sie angeben, ob die erstellte Funktion vom folgenden Typ ist:

DETERMINISTISCH: Unsicher
NO SQL: Es gibt keine SQl-Anweisung, und die Daten werden natürlich nicht geändert
LESEN SQL-DATEN: Lesen Sie einfach die Daten, natürlich werden die Daten nicht geändert
ÄNDERT SQL-DATEN: Zum Ändern der Daten
ENTHÄLT SQL: Enthält SQL-Anweisungen

Wenn die Anweisungen CREATE PROCEDURE oder CREATE FUNCTION akzeptiert werden dürfen, muss standardmäßig eine der Anweisungen DETERMINISTIC oder NO SQL und READS SQL DATA angegeben werden, andernfalls wird ein 1418-Fehler generiert.

7.3 Lösung

Es gibt zwei Lösungen:

Wenn Sie ein Unterprogramm (gespeicherte Prozedur, Funktion, Trigger) erstellen, deklarieren Sie es als DETERMINISTIC oder NO SQL und READS SQL DATA

CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`()
    DETERMINISTIC
BEGIN
 #Routine body goes here...
END;

Vertrauen Sie dem Ersteller der Unterroutine, verbieten Sie die Anforderung der SUPER-Berechtigung beim Erstellen oder Ändern der Unterroutine und setzen Sie log_bin_trust_routine_creators = 1

# 方法1，在mysql控制台中直接修改（临时生效）
SET GLOBAL log_bin_trust_function_creators = 1;

# 方法二，在MySQL启动时，加上--log-bin-trust-function-creators选项，参数设置为1

# 方法三，在my.cnf配置文件[mysqld]中添加如下内容，重启后生效
log-bin-trust-function-creators = 1

8. Lösungen für MySQL-Fehler Kommunikationsverbindungsfehler

8.1 Problembeschreibung

Der Tomcat-Prozess meldet nach dem Herstellen einer Verbindung zur Datenbank einen Fehler:

Auslöser: org.apache.commons.dbcp.SQLNestedException: PoolableConnectionFactory kann nicht erstellt werden (Kommunikationsverbindungsfehler Das letzte erfolgreich an den Server gesendete Paket war vor 0 Millisekunden. Der Treiber hat keine Pakete vom Server empfangen.)

8.2 Ursachen des Problems

Anhand der Fehlermeldung kann beurteilt werden, dass die Verbindung im Verbindungspool ungültig ist, dh die gültige Zeit wait_timeout abgelaufen ist. Überprüfen Sie nach der Anmeldung bei MySQL, ob die gültige Zeit für wait_timeout 28800 beträgt, was 8 Stunden entspricht.

mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

8.3 Lösung

Ändern Sie das Attribut wait_timeout und erhöhen Sie den Wert auf 31536000 (365 Tage, der maximale Wert von Linux beträgt ein Jahr).

# 在my.cnf配置文件中，[mysqlId]下添加wati_timeout、interactive_timeout属性，重启mysql
wait_timeout = 31536000
interactive_timeout = 31536000

9. ERROR 1129 (00000)… ist aufgrund vieler Verbindungsfehler blockiert

9.1 Problembeschreibung

Beim Herstellen einer Verbindung zur Datenbank wird ein Fehler gemeldet:

FEHLER 1129 (00000): # HY000Host '192.168.31.242' ist wegen vieler Verbindungsfehler blockiert. Entsperren mit 'mysqladmin flush-hosts'

9.2 Ursache des Problems

Es gibt zu viele Verbindungsfehler (zu viele Verbindungsversuche), die die Anzahl der Konfigurationselemente für max_connection_errors in der Konfigurationsdatei überschreiten.

9.3 Lösung

Geben Sie den folgenden Befehl auf dem MySQL-Server ein, um den Cache zu leeren

mysqladmin flush-hosts -uroot -p

Fügen Sie die folgende Konfiguration in die Konfigurationsdatei my.cnf [mysqld] ein und starten Sie die Datenbank neu

max_connection_errors = 1000

10. MySQL5.7 Err 时：： [Err] 1055 - Ausdruck Nr. 1 der SELECT-Liste befindet sich nicht in der GROUP BY-Klausel. Dies ist nicht kompatibel mit sql_mode = only_full_group_by

10.1 Problembeschreibung

Migrieren Sie die Datenbank von Version 5.5 auf Version 5.7. Die detaillierte Fehlermeldung beim Ausführen der Abfrageanweisung lautet wie folgt:

[Err] 1055 - Ausdruck Nr. 1 der SELECT-Liste befindet sich nicht in der GROUP BY-Klausel und enthält die nicht aggregierte Spalte 'cdxc.a.id', die funktional nicht von den Spalten in der GROUP BY-Klausel abhängig ist. Dies ist nicht kompatibel mit sql_mode = only_full_group_by

10.2 Ursache des Problems

In MySQL 5.7 ist sql_mode standardmäßig auf ONLY_FULL_GROUP_BY festgelegt. Um dies zu verwenden, müssen dieselben Gruppenregeln wie bei Oracle verwendet werden. Die ausgewählten Spalten müssen sich in der Gruppe befinden oder sie müssen aggregierte Spalten sein (SUM, AVG, MAX, MIN).

10.3 Lösung

Fragen Sie die aktuelle sql_mode-Konfiguration ab

mysql> select @@sql_mode;
+--------------------------------+
| @@sql_mode					 |                                 
+--------------------------------+
|ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+--------------------------------+
1 row in set (0.04 sec)

Entfernen Sie ONLY_FULL_GROUP_BY in der Konfiguration, schreiben Sie den Rest der Konfiguration unter [mysqld] in die Konfigurationsdatei und starten Sie den Datenbankdienst neu. Das Format lautet wie folgt

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Oder geben Sie den folgenden Inhalt direkt in die Datenbank ein (Sie müssen die Datenbank verlassen und erneut eingeben, um wirksam zu werden).

set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

11. MySQL5.7 报错 Falscher Datums- / Uhrzeitwert: '0000-00-00 00:00:00' für Spalte

11.1 Problembeschreibung

mysql5.7 meldet einen Fehler beim Ausführen des Imports von SQL-Anweisungen: mysql 5.7 Fehler: Falscher Datums- / Uhrzeitwert: '0000-00-00 00:00:00' für Spalte xxx

11.2 Ursachen des Problems

Ab Version 5.7 unterstützt datetime das Format '0000-00-00 00:00:00' nicht mehr.

11.3 Lösung

Ersetzen Sie die SQL-Anweisung, die '0000-00-00 00:00:00' enthält, durch '1970-01-01 00:00:01' in der zu importierenden SQL-Anweisung

sed -i 's/0000-00-00 00:00:00/1970-01-01 00:00:01/g' test.sql

Ändern Sie sql_mode, löschen Sie NO_ZERO_IN_DATE und NO_ZERO_DATE in sql_mode

# 查询sql_mode
select @@sql_mode;

# 在控制台中重新设置sql_mode
set global sql_mode='STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION';

# 在配置文件[mysqld]中添加如下内容重新设置sql_mode
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

12. MySQL 5.7 ：： Für Transaktionen mit mehreren Anweisungen ist mehr als 'max_binlog_cache_size' Speicherbytes erforderlich. Erhöhen Sie diese mysqld-Variable und versuchen Sie es erneut

12.1 Problembeschreibung

Wenn große Transaktionen wie Stapelaktualisierungen oder Löschungen von MySQL ausgeführt werden, werden die folgenden Fehler gemeldet:

Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

12.2 Ursache des Problems

Dies liegt daran, dass große Transaktionen mit Aktualisierungen und Löschungen eine große Anzahl von Binlogs schreiben, was dazu führen kann, dass der Binlog-Cache zu klein ist und Ausführungsfehler verursacht. Es wird auch Fälle geben, in denen die Master-Bibliothek erfolgreich ausgeführt wird, die Slave-Bibliothek jedoch nicht synchron ist. Dies liegt daran, dass, obwohl die Parameter max_binlog_cache_size von Master und Slave gleich eingestellt sind, der tatsächlich verwendete Binlog-Cache nicht unbedingt derselbe ist, was dazu führt, dass die Master-Slave-Replikation unterbrochen wird, weil der Binlog-Cache zu klein ist.

12.3 Lösung

Überprüfen Sie zunächst die aktuell in MySQL festgelegte max_binlog_cache_size:

mysql> show variables like 'max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+

Überprüfen Sie, ob der Wert dieser Parametereinstellung 134217728 (128 MB (128 * 1024 * 1024)) ist, und stellen Sie eine geeignete Größe ein, z. B. 256 MB:

# 在控制台中设置
mysql> set global max_binlog_cache_size=268435456;
Query OK, 0 rows affected (0.05 sec)

# 在配置文件 [mysqld] 中添加如下内容进行设置
max_binlog_cache_size = 256M

Ursprünglicher Link zu diesem Artikel: https://blog.csdn.net/xzk9381/article/details/114872726