MariaDBを使用しているWordPress Webサイトでは、数千のレコードをテーブルに書き込む悪質なプラグインのためにwp_optionsテーブルが増加し続けています。この問題はまだプラグインのメンテナーによって解決されておらず、DELETEステートメントを介してこれらの一時的な（一時的な）レコードを手動で削除する必要があります。問題は、ibdファイルのサイズが35GBに増え続けることです。これが解決されたら、私は、テーブル上のOPTIMIZE TABLEをクリーンアップする予定です。それはそのスペースをすべて取り戻す最善のアプローチですか？これを行うには40GBの空き容量が必要で、OPTIMIZE TABLEにはどれくらいの時間がかかるでしょうか？この表はWordPressでかなり使用されているので、ロックを回避するために最適化しながらウェブサイトをオフラインにすることが最善の方法と思われます。私は解決するための最も速い方法を探します。大規模なibdファイルのためにMariaDBを最適化する
少なくとも、私はこれらの不正な記録がテーブルの成長の原因だと思います。以下は、テーブル内のエントリの上位10種類のリストです：
MariaDB [wmnf_www]> SELECT substr(`wp_options`.`option_name`, 1, 18) AS `option_name`, count(`wp_options`.`option_value`) AS `cnt` FROM `wp_options` GROUP BY substr(`wp_options`.`option_name`, 1, 18) ORDER BY `cnt` DESC LIMIT 10;
+--------------------+-------+
| option_name | cnt |
+--------------------+-------+
| _transient_timeout | 21186 |
| _transient_ee_ssn_ | 12628 |
| _transient_jpp_li_ | 222 |
| _transient_externa | 125 |
| _transient_wc_rela | 63 |
| jpsq_sync-14716436 | 50 |
| wpmf_current_folde | 35 |
| _wc_session_expire | 34 |
| jpsq_sync-14716465 | 29 |
| jpsq_sync-14716417 | 25 |
+--------------------+-------+
10 rows in set (0.17 sec)
_transient_ee_ssn_と_transient_timeout_ee_が問題であり、成長し続けるが、その上記のセットで唯一のものは、最後の夜以来、成長してきたし、最初に見つかりました800Kレコードでプラグインメンテナーが安全だと言っても、私はそのレコードを削除し続けます。しかし、これはibdファイルの成長の原因ですか？
---更新--- 奇妙なことに、この問題は解決されず、一時的なレコードは数千も生成され続けていますが、このibdインデックスファイルは現在のところ増えていません。週末にかけて20GBから現在の39GBまで着実に成長した後、数時間で成長することはありません。おそらく限界がありますか、このファイルは他の理由で成長していたでしょうか？
これは最近、wp_optionsが驚異的に成長した第3の質問です。プラグインの1つは、それ自体の後ではクリーンアップしません。他のQ＆Aを検索してください。 –