Использование дискового пространства заставляет меня думать, что у вас есть очень большой набор результатов для сортировки во временных таблицах на диске. Чтобы проверить, ищите увеличение в переменной состояния счетчика Created_tmp_disk_tables
, когда происходят всплески.
mysql> show global status like 'Created%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 56 | <-- this is probably the culprit
| Created_tmp_files | 23 |
| Created_tmp_tables | 3177 |
+-------------------------+-------+
Если это так, у вас могут быть запросы, которые содержат временные таблицы, достаточно большие, чтобы они не умещались в памяти, и вам приходилось буферизовать на диск. К сожалению, вы не можете выяснить насколько большие эти временные наборы результатов, но я бы предположил, что он порядка 15 ГиБ.
Вы должны выяснить, какие запросы генерируют огромные временные таблицы, и попытаться оптимизировать эти запросы. К сожалению, стандартный MySQL не имеет хорошей информации для регистрации, чтобы отследить это, и Amazon RDS не позволяет вам заменить стандартный MySQL расширенным форком MySQL, например. Percona Server , который предоставит вам эту информацию в своем журнале медленных запросов.
Таким образом, вам придется перейти в свою среду разработки и выполнить некоторый анализ кода ваших SQL-запросов, один за другим выполнить их через EXPLAIN и определить, какое из них является узким местом.