さまざまなMySQLの問題と解決策の要約

この記事の元のリンク：https：//blog.csdn.net/xzk9381/article/details/114872726

1. MySQL5.7スレッドブロッキングソリューション

1.1問題の説明

データベースでステートメントを実行すると、エラーが報告されます。エラー1205（HY000）：ロック待機タイムアウトを超えました。トランザクションを再起動してみてください。

1.2解決策

現在のデータベースのスレッドを表示する

show full processlist;

実行中の遅いSQLレコードスレッドが表示されない場合は、INNODB_TRXトランザクションテーブルをチェックして、ロックされているトランザクションスレッドがあるかどうかを確認し、trx_mysql_thread_idがshow fullprocesslistのスリープスレッドにあるかどうかを確認します。このスリープのスレッドトランザクションがコミットまたはロールバックなしでスタックしていることを証明します。手動で強制終了する必要があります。たとえば、32735を強制終了します。

2.データベースにリモート接続すると、MySQL5.7の速度が低下します

2.1問題の説明

mysqlコマンドを使用して、データベースにリモートアクセスします。パスワードを入力した後、接続が完了するまで5秒から10秒待つ必要があります。これにより、バックグラウンドサービスが例外をスローします。

2.2問題の原因

mysqlは、データベースにアクセスするたびに、アクセスされたマシンのドメイン名を解決しようとします。この時点で解決できない場合、データを取得できるようになるまでしばらくすると失敗します。

2.3解決策

ドメイン名解決を禁止するためにmysql構成ファイルの[mysqld]の下にskip-name-resolve構成項目を追加し、データベースを再起動して有効にします

3. MySQL5.7バイナリインストールエラー

3.1問題の説明

バイナリインストールパッケージを使用して、centos6.8にMySQL 5.7をインストールし（最小インストール）、エラーを報告します。

共有ライブラリのロード中にエラーが発生しました：libaio.so.1：共有オブジェクトファイルを開くことができません：そのようなファイルまたはディレクトリはありません

3.2解決策

libaioライブラリは、CentOSの最小インストール中にデフォルトでインストールされないため、手動でインストールする必要があります

yum install libaio-devel

4. MySQL5.7のグループ連結関数を使用した切り捨てられたデータの問題の解決策

4.1問題の説明

クエリに対してGROUP_CONCAT関数が呼び出された場合、クエリは停止せず、データを返しません（クエリされたデータが切り捨てられ、最長の長さが1024バイトを超えない場合もあります）。

4.2問題の原因

この問題の理由は、公式のデフォルトのgroup_concat_max_len構成が1024であり、これによりGROUP_CONCATデータの長さが制限されるためです。次のコマンドを使用してクエリを実行できます。

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解決策

group_concat_max_lenを最大値18446744073709551615に調整できます（またはビジネスの実際の収益の最大長に応じて設定できます）

MySQL構成ファイルを変更し、[mysqld]の下にgroup_concat_max_len = 18446744073709551615（永続的に有効）を追加します。
コンソールに設定（一時的に有効）

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

5. MySQL报エラー：クエリのパケットが大きすぎます（2034> 1024）

5.1問題の説明

データの保存時にエラーが報告されます。

エラー：クエリのパケットが大きすぎます（2034> 1024）。max_allowed_packet '変数を設定することにより、サーバーでこの値を変更できます。

5.2解決策

次のコマンドを使用して、現在のデータベースのmax_allowed_packet設定を表示します

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

my.cnf構成ファイル[mysqld]でmax_allowed_packet = 128Mを追加または変更し、mysqlを再起動して有効にします。max_allowed_packetの値が一定期間後に1024に復元された場合、現在のサーバーのメモリが不足しているかどうかをクエリする必要があります。これにより、MySQLはパラメータを自動的に1024にリセットし、問題を解決するのに十分なメモリを予約します。

6. MySQL5.7エラー「テーブルメタデータロックを待機しています」ソリューション

6.1問題の説明

MySQL 5.7でaltテーブルなどのDDL操作を実行すると、操作がブロックされて実行できなくなります。showprocesslistを使用して、テーブルのaltテーブル操作に「テーブルメタデータロックの待機中」と表示されていることを確認してください。

6.2問題の原因

MySQL 5.7でaltテーブルなどのDDL操作を実行するときに、テーブルにコミットされていないトランザクションがある場合、テーブルのメタデータロック状態を待機していますが表示されます

6.3解決策

次のコマンドを使用して、information_schema.innodb_trxからコミットされていないトランザクションを表示します。通常、これらのスレッドが強制終了されている限り、DDL操作はテーブルメタデータロックを待機しません。

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

ロックタイムアウトのしきい値を調整します。lock_wait_timeoutは、メタデータロックを取得するためのタイムアウト（秒単位）を表し、許可される値の範囲は1〜31536000（1年）です。デフォルト値は31536000で、30分に調整します

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

この記事の元のリンク：https：//blog.csdn.net/xzk9381/article/details/114872726

7. MySQLエラー1418（HY000）の解決策

7.1問題の説明

MySQLがbin-logを開いた後、ストアドプロシージャまたは関数とトリガーを呼び出すと、エラー番号1418のエラーが発生します。

ERROR 1418（HY000）：この関数は、DETERMINISTIC、NO SQLのどれを持っていない、またはその宣言でSQLデータを読み取り、バイナリログは、（あなたが有効になっている可能性が少なく、安全なlog_bin_trust_function_creators変数を使用したいです）

7.2問題の原因

CREATE PROCEDURE、CREATE FUNCTION、ALTER PROCEDURE、ALTER FUNCTION、CALL、DROP PROCEDURE、DROP FUNCTIONなどのステートメントは、バイナリログに書き込まれ、スレーブサーバーで実行されるためです。ただし、更新を実行する不確定なサブルーチン（ストアドプロシージャ、関数、トリガー）は繰り返し実行できません。スレーブサーバーで実行すると（マスターサーバーに対して実行が繰り返されるため）、復元されたデータが元のデータと異なる場合があります。サーバーがメインサーバーと異なる状況。

この問題を解決するために、MySQLは、サブプログラムが決定論的であると宣言されているか、データを変更しない限り、サブプログラムの作成または置換が拒否されることをメインサーバーで義務付けています。これは、サブルーチンを作成するときに、それが決定論的であること、またはデータを変更しないことを宣言する必要があることを意味します。

宣言する方法は2つあります。

ステートメントは決定論的です。DETERMINISTICとNOTDETERMINISTICは、サブルーチンが特定の入力に対して常に同じ結果を生成するかどうかを示します。機能が指定されていない場合、デフォルトはNOT DETERMINISTICであるため、サブルーチンが決定論的であることを宣言するには、DETERMINISTICを明示的に指定する必要があります。ここで説明したいのは、NOW（）関数（またはその同義語）またはRAND（）関数を使用しても、サブルーチンが非決定論的になることはないということです。NOW（）の場合、バイナリログにはタイムスタンプが含まれ、正しく実行されます。RAND（）は、サブルーチンで1回呼び出される限り、正しくコピーできます。したがって、タイムスタンプと乱数シードはサブルーチンへの決定論的入力であり、マスターサーバーとスレーブサーバーで同じであると見なすことができます。
データを変更するかどうかを宣言します。CONTAINSSQL、NO SQL、READS SQL DATA、MODIFIES SQLは、サブルーチンがデータを読み取るか書き込むかを示すために使用されます。
NOSQLとREADSSQL DATAはどちらも、サブルーチンがデータを変更しないことを示していますが、いずれかが指定されている場合、デフォルトの指定はCONTAINS SQLであるため、そのうちの1つを明示的に指定する必要があります。

つまり、bin-logがオンになっている場合、作成された関数が次のタイプであるかどうかを指定する必要があります。

決定論的：不確実
SQLなし：SQlステートメントはなく、もちろんデータは変更されません
SQLデータの読み取り：データを読み取るだけです。もちろん、データは変更されません。
SQLデータの変更：データを変更するには
CONTAINS SQL：SQLステートメントが含まれています

デフォルトでは、CREATEPROCEDUREまたはCREATEFUNCTIONステートメントの受け入れが許可されている場合、DETERMINISTICまたはNOSQLおよびREADSSQL DATAのいずれかを明示的に指定する必要があります。指定しないと、1418エラーが生成されます。

7.3解決策

2つの解決策があります：

サブルーチン（ストアドプロシージャ、関数、トリガー）を作成するときは、それをDETERMINISTICまたはNO SQLのいずれかとして宣言し、SQLデータを読み取ります。

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

サブルーチンの作成者を信頼し、サブルーチンを作成または変更するときにSUPER権限の要件を禁止し、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.MySQLエラーの解決策通信リンク障害

8.1問題の説明

tomcatプロセスは、データベースに接続した後にエラーを報告します。

原因：org.apache.commons.dbcp.SQLNestedException：PoolableConnectionFactoryを作成できません（通信リンク障害サーバーに正常に送信された最後のパケットは0ミリ秒前です。ドライバーはサーバーからパケットを受信していません。）

8.2問題の原因

エラーメッセージによると、接続プール内の接続が無効である、つまり有効時間wait_timeoutが期限切れになっていると判断できます。mysqlにログインした後、wait_timeoutの有効時間が28800、つまり8時間であることを確認します。

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

8.3解決策

wait_timeout属性を変更し、値を31536000に増やします（365日、Linuxの最大値は1年です）

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

9.エラー1129（00000）…多くの接続エラーのためにブロックされています

9.1問題の説明

データベースへの接続時にエラーが報告されます。

エラー1129（00000）：＃HY000Host '192.168.31.242'は、多くの接続エラーのためにブロックされています。'mysqladminflush-hosts'でブロックを解除します

9.2問題の原因

接続エラーが多すぎます（接続試行が多すぎます）。構成ファイル内のmax_connection_errors構成項目の数を超えています。

9.3解決策

mysqlサーバーで次のコマンドを入力して、キャッシュをクリアします

mysqladmin flush-hosts -uroot -p

my.cnf構成ファイル[mysqld]に次の構成を追加し、データベースを再起動します

max_connection_errors = 1000

10. MySQL5.7查询時报错：[Err] 1055-SELECTリストの式＃1がGROUPBY句にありません…これはsql_mode = only_full_group_byと互換性がありません

10.1問題の説明

データベースをバージョン5.5からバージョン5.7に移行すると、クエリステートメントの実行時の詳細なエラーメッセージは次のようになります。

[エラー] 1055-SELECTリストの式＃1がGROUP BY句になく、GROUPBY句の列に機能的に依存しない非集約列 'cdxc.a.id'が含まれています。これはsql_mode = only_full_group_byと互換性がありません

10.2問題の原因

MySQL 5.7では、sql_modeはデフォルトでONLY_FULL_GROUP_BYに設定されています。これを使用するには、Oracleと同じグループルールを使用します。select列はグループ内にあるか、集計列（SUM、AVG、MAX、MIN）である必要があります。

10.3解決策

現在のsql_mode構成を照会します

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)

構成からONLY_FULL_GROUP_BYを削除し、構成ファイルの[mysqld]の下に残りの構成を書き込み、データベースサービスを再起動します。形式は次のとおりです。

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

または、データベースに次のコンテンツを直接入力します（データベースを終了し、再度入力して有効にする必要があります）

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报错不正な日時値：列の「0000-00-0000：00：00」

11.1問題の説明

mysql5.7は、sqlステートメントのインポートの実行時にエラーを報告します：mysql 5.7エラー：列xxxの日時値が正しくありません： '0000-00-00 00:00:00'

11.2問題の原因

バージョン5.7以降、datetimeは「0000-00-0000：00：00」の形式をサポートしなくなりました。

11.3解決策

インポートするSQLステートメントの「0000-00-0000：00：00」を含むSQLステートメントを「1970-01-0100：00：01」に置き換えます

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

sql_modeを変更し、sql_modeのNO_ZERO_IN_DATEとNO_ZERO_DATEを削除します

# 查询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报错：マルチステートメントトランザクションには、「max_binlog_cache_size」バイトを超えるストレージが必要でした。このmysqld変数を増やして、再試行してください

12.1問題の説明

MySQLのバッチ更新や削除などの大規模なトランザクションが実行されると、次のエラーが報告されます。

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

12.2問題の原因

これは、更新と削除のトランザクションが大きいと、多数のbinlogが書き込まれ、binlogキャッシュが小さすぎて、実行エラーが発生する可能性があるためです。マスターライブラリは正常に実行されますが、スレーブライブラリが同期していない場合もあります。これは、マスターとスレーブのmax_binlog_cache_sizeパラメーターが同じに設定されていても、実際に使用されるbinlogキャッシュが必ずしも同じであるとは限らないためです。これにより、binlogキャッシュが小さすぎるため、マスタースレーブレプリケーションが中断されます。

12.3解決策

まず、MySQLで現在設定されているmax_binlog_cache_sizeを確認します。

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

このパラメータ設定の値が134217728、つまり128M（128 * 1024 * 1024）であることを確認し、適切なサイズ（たとえば、256M）に設定します。

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

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

この記事の元のリンク：https：//blog.csdn.net/xzk9381/article/details/114872726