MySQL / InnoDBバッファープールのサイズが小さく、大きなトランザクションが実行されてバッファープールのオーバーフローが発生するとどうなりますか？
50,000の挿入を実行するトランザクションがあり、データベースの約600 MBを汚しているとします。バッファー・プールのサイズが128 MBの場合、トランザクションの実行中にバッファー・プールにダーティー・ページがあり、スペースを作るためにこれらを除去する必要があります。私の質問は、MySQL/InnoDBはこれらのダーティなコミットされていないページをどのように処理するのですか？
5日前に質問を見つけました： InnoDBエラーが発生し、MyISAMデータベースでクラッシュしますか？
ライブチャットセッションで問題をトラブルシューティングしているときに、一時的なInnoDBテーブルのダーティページがInnoDBバッファープールを占有していることを発見しました 。 innodb_max_dirty_pages_pct が75だったため、ファイルibtmpは482MBで、バッファープールの75％がダーティでした。バッファープールは128Mしかありませんでした。では、どうなるのでしょうか。
バッファー・プールが小さすぎる場合、バッファー・プールは非常に頻繁にフラッシュする必要があります（これは、仮想的に空のデータベースで発生したものです）。
SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool%';を実行すると、次のように表示されます。
mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool%';
+---------------------------------------+--------------------------------------------------+
| Variable_name | Value |
+---------------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_dump_status | Dumping of buffer pool not started |
| Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 190925 9:50:58 |
| Innodb_buffer_pool_resize_status | |
| Innodb_buffer_pool_pages_data | 247 |
| Innodb_buffer_pool_bytes_data | 4046848 |
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
| Innodb_buffer_pool_pages_flushed | 36 |
| Innodb_buffer_pool_pages_free | 7945 |
| Innodb_buffer_pool_pages_misc | 0 |
| Innodb_buffer_pool_pages_total | 8192 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |
| Innodb_buffer_pool_read_ahead | 0 |
| Innodb_buffer_pool_read_ahead_evicted | 0 |
| Innodb_buffer_pool_read_requests | 1090 |
| Innodb_buffer_pool_reads | 214 |
| Innodb_buffer_pool_wait_free | 0 |
| Innodb_buffer_pool_write_requests | 325 |
+---------------------------------------+--------------------------------------------------+
18 rows in set (0.01 sec)
mysql>
Innodb_buffer_pool_pages_dirtyは
mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_pages_dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
+--------------------------------+-------+
1 row in set (0.00 sec)
mysql>
この数は、フラッシュされるページと受信されるページによって変動する可能性がありますが、これは間違いなくInnoDBをボトルネックにします。あなたの解決策は、バッファプールのサイズを増やすことです。
以前に他の悪影響について話しました（私の投稿を参照してください InnoDBログスペースが小さすぎるとどうなりますか ）
私はケースを見てきたと思います
- buffer_poolが実際に低く設定されている（128Mをはるかに下回る）
- トランザクションはcomplexであり、単に「大きな」ものではありませんでした。
- エラーは、buffer_poolがスペース不足（またはそのようなもの）であることを示していました。あなたはあるエラーをチェックしています、そうですか？
「ビッグ」は問題ではありません-InnoDBはROLLBACKなどのために保持されている任意の多くの行を処理するように設計されています。元に戻すログだけでなく、テーブルなど.
「複雑」は問題になる可能性があります-いくつかのテーブルとそれらのインデックスのいくつかのBTreeの多くのブロックをロックする必要があると仮定します。
128Mがトラブルに巻き込まれるのを見たとは思わない（遅いこと以外）。以前のデフォルト（8M）は問題を引き起こしたと思います。それはMyISAMが王だった時代に戻ったもので、InnoDBは新たに生まれたばかりのブロックでした。
5コースの食事のように考えてください。キッチンは一度に1つずつコースを準備できます。しかし、5つすべてを同時に配信するように要求した場合はどうなるでしょうか。