私はMySQL 8(8.0.12)を使い始めましたが、このバージョンでは「挿入」がMySQL 5.6またはMySQL 5.7よりも遅いことがわかりました。テーブルがMyISAMであるかInnoDBであるかは関係ありません。レコードが1つだけの「挿入」が1つだけの場合、サーバーはMySQL 8で約0.2〜0.3秒かかります。MySQL5.7で同じ「挿入」は0.003秒以下しかかかりません。
私はすでにWindows Defenderまたは別のアンチウイルスプログラムを破棄しました。同じサーバーに仮想マシンがあり、VMにMySQL 5.7があり、結果がかなり良い:0.003秒以下。
同じ「挿入」を異なるS.O.の異なるコンピューターでテストしました。結果は常に同じです。MySQL5.7(または5.6)の所要時間は0.003秒以下ですが、MySQL 8の場合、レコードが1つしかないすべての挿入で0.2〜0.3秒かかります。 「作成」も遅いです。
私にとって奇妙に思えるのは、MySQL 8では、以前のバージョンよりも単純な「選択」または「結合による選択」の方が高速であることです。問題はディスクに書き込むクエリにあると思いますが、ディスクの制限ではなく、my.iniまたは別のMySQL設定で割り当てられた制限である可能性があります。
ここでは、MySQL 8のスクリプトのパフォーマンスが遅いままにしておきます。
CREATE TABLE `ciiu_test2` (
`id` INT(11) NULL DEFAULT NULL,
`codbut` VARCHAR(11) NULL DEFAULT NULL,
`ciiu` VARCHAR(8) NULL DEFAULT NULL
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
;
MySQL 5.7での実行時間:0.016秒MySQL 8.0.12での実行時間:0.140秒
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (1, '18237', '2750');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (2, '18238', '9491');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (3, '18245', '9411');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (4, '18248', '2221');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (5, '18264', '3520');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (6, '18265', '4645');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (7, '18268', '6202');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (8, '18276', '6512');
INSERT INTO `ciiu_test2` (`id`, `codbut`, `ciiu`) VALUES (9, '18290', '4210');
MySQL 5.7での実行時間:0.002秒MySQL 8.0.12での実行時間:0.681秒
複数のレコードを使用して「挿入」を最適化することはお勧めしません。具体的には、MySQL 5.7で1回行った「挿入」ごとに、MySQL 8で同じ時間を取得する必要があります。
この問題で私を与えることができる助けを事前に感謝します。
5.7と8.0の違いは、MySQL 8.0ではバイナリロギング(レプリケーションとPITRに使用される)がデフォルトでオンになっていることです。 8.0でバイナリロギングなしで実行するには、MySQLサーバーを--disable-log-bin
。
詳細 バイナリログ
バイナリログには、テーブル作成操作やテーブルデータへの変更など、データベースの変更を説明する「イベント」が含まれています。また、行ベースのロギングを使用しない限り、変更を加えた可能性のあるステートメント(たとえば、行に一致しないDELETEなど)のイベントも含まれます。バイナリログには、各ステートメントがその更新されたデータに要した時間に関する情報も含まれています。バイナリログには2つの重要な目的があります。
- レプリケーションの場合、マスターレプリケーションサーバーのバイナリログは、スレーブサーバーに送信されるデータ変更の記録を提供します。マスターサーバーは、バイナリログに含まれるイベントをスレーブに送信します。スレーブはそれらのイベントを実行して、マスターで行われたのと同じデータ変更を行います。セクション17.2「レプリケーションの実装」を参照してください。
- 特定のデータ回復操作では、バイナリログを使用する必要があります。バックアップが復元された後、バックアップの作成後に記録されたバイナリログのイベントが再実行されます。これらのイベントにより、バックアップの時点からデータベースが最新の状態になります。セクション7.5「バイナリログを使用したポイントインタイム(増分)リカバリ」を参照してください。
MySQL 8から、XXHASH64
というトランザクション書き込みセット抽出アルゴリズムが導入されました。新しいデフォルトでは、ユーザーがマスターでバイナリログの書き込みセットの並列化を簡単に有効にして、グループのレプリケーションを高速化できます。[1] MySQLグループレプリケーションを使用していない場合は、設定をXXHASH64
からOFF
に変更できます。また、スレーブを並行して実行している場合は、バイナリログを有効にできます。
[mysqld]
#skip-log-bin
transaction_write_set_extraction=OFF
[1]: https://mysqlserverteam.com/new-defaults-in-mysql-8-0/