MySQLのコミットには時間がかかる
特定の時間に1秒以上かかるコミットの数があるという問題に直面しています。これの時間間隔は固定されていません。私たちのアプリケーションは何千ものコミットを送信しますが、場合によっては、まったく同じタイムスタンプのコミットが遅くなります。
これはMySQLスロークエリログから抽出されます 
スロークエリログに他のクエリが同時に存在しない。それをさらに調査する方法についてのポインタはありますか？
Amazon RDSではMySQL 5.7.16を使用しています。
コミットが停止しているため、innodb_flush_log_at_trx_commit=1（ ここで＃4を参照 ）で実行していると想定してもかなり安全です。そのため、明らかな変更の1つは、innodb_flush_log_at_trx_commit=0に切り替えることです。しかし、それはあなたにとって正しい選択ではないかもしれません-前のリンクを参照してください。
いずれの場合でも、COMMITsは、サーバー上の他のアクティビティ（クエリなど）が原因で、ある種のミューテックスを長時間ロックしない限り、通常はストールしません。
それ以上の証拠なしに推測する必要がある場合、書き込みが非常に集中しているため、MySQLは適応型チェックポイントを使用して十分に速くフラッシュできないため、ログ容量の75％を超え、鋭いチェックポイントを開始します（これによりサーバーアクティビティがブロックされます）短期間）。
MySQLが書き込みをよりよく処理するための簡単な方法はいくつかあります（上記の方法以外に）。
- Innodbログファイル（innodb_log_file_size）を増やす-ログの場合、最大4GBまで増やすことができます（書き込み量に関するゼロの情報に基づいて推定）。
- データドライブのpIOPS容量を増やす
- Innodb_io_capacityを増やします（最大pIOPS容量の70〜80％）
それ以外の場合、AWSからのディスクアクティビティ、現在書き込み中のデータサーバーの量を確認すると非常に便利です（2つの連続するLog sequence number実行間のshow engine innodb status\Gデルタを使用して計算できます）
他にも方法はありますが、そのためには、実際のワークロードについてさらに多くの詳細が必要になります。