サイト内検索
Cocoonフォーラム
書き込みの前に以下の3点をご確認ください。
何を書き込んだら良いか分からない場合は、以下のテンプレートをコピペしてご利用ください。
不具合・カスタマイズ対象ページのURL：
相談内容：
不具合の発生手順：
解決のために試したこと：
※文字だけでは正しく伝わらない可能性があるため、スクショ画像の添付もお願いします。
※高速化設定をしている場合は無効にしてください。
環境情報：※↑こちらに「Cocoon設定 → テーマ情報」にある「環境情報」を貼り付けてください。
環境情報の取得方法はこちら。
→ https://wp-cocoon.com/theme-report/
高速化設定を無効にするにはこちら。
→ https://wp-cocoon.com/theme-trouble/
フォーラム利用ガイドリンク
- フォーラムガイドライン
- よくある質問と答え（FAQ）
- サポート対象外のケース
- 原因不明の不具合用トラブルシューティング
- トピックにHTMLを貼り付ける方法（推奨ツール：notepad.pw）
- 真っ白画面でのエラーメッセージの確認方法
- ブラウザ環境チェックツール
- Cocoonカスタマイズ依頼
フォーラム質問後、問題等が解決した場合は結果を書き込んでいただけると幸いです。同様の問題で調べている方には、結果が一番気になる部分となります。
トピックスターター 2024年4月21日 19:31
こんにちは。
「Cocoonのことに限らず、WordPress以外でも何でも。単なる雑談用のフォーラムなので、気軽に書き込んでください」とのことなので・・「CONOHAWINGにてデータベースがいっぱいになったときの対処方法について」質問させてください。
CONOHAWINGを契約してサイトを運営しています。
最近データベース容量が以下の状態になりました。
5123.55MB/5120MB（容量一杯使ってます・・という状況）
これにより、記事が追加できない状況となりました（当然です）。
CONOHAはデータベースの生成は無制限なので、新にデータベースを生成して、入れ替えようとしたらWordpressのインストールの手順から始まり、一から始めなくてはならないのか・・？という状況です。
ここで知りたいことは
「データベース容量が一杯になったときに、Wordpressの設定を変更しないまま新たなデータベースへ変更することは可能でしょうか。また新たなデータベースに変更した場合に過去の記事は閲覧できなくなるでしょうか」
文章が下手なので意味が分からない場合は申し訳ございません。
よろしくお願いいたします。
このトピックは8か月前からSHION_SHIONに変更されました
2024年4月21日 20:17
SHION_SHIONさん
最近データベース容量が以下の状態になりました。
5123.55MB/5120MB（容量一杯使ってます・・という状況）
データベース容量ががこんなに多くなる理由はなんでしょう？
私のサイトは5,000以上投稿がありますが、100MBくらいしか、使用していないです。
「データベース容量が一杯になったときに、Wordpressの設定を変更しないまま新たなデータベースへ変更することは可能でしょうか。
データベースの接続先を変更すれば、できると思います。
（設定を変えているとは言えるかもしれないですが）
新たなデータベースに変更した場合に過去の記事は閲覧できなくなるでしょうか
新しいデータベースということは、以前のものは格納されていないということになろうかと思います。
複数のデータベースを読み込むことが、できるものなのか・・・。
有識者の方ならご存じかも？
最初に書きましたが、なぜデータベース容量がそんなに多くなるのかは、気になりますね。
SHION_SHION and わいひら reacted
トピックスターター 2024年4月21日 22:18
MK２さん、ご返信ありがとうござます。
データベース容量ががこんなに多くなる理由はなんでしょう？
私のサイトは5,000以上投稿がありますが、100MBくらいしか、使用していないです
1万記事程度ですが、満タンです。。
データベースの接続先を変更すれば、できると思います。
（設定を変えているとは言えるかもしれないですが）
DBの接続先を変更したらやはりWPの設定を初期状態からやることになります。これがツライです。
新しいデータベースということは、以前のものは格納されていないということになろうかと思います
ということは、閲覧できないということですね。了解です。
最初に書きましたが、なぜデータベース容量がそんなに多くなるのかは、気になりますね
画像が多いからでしょうか。。もしくはWPの設定やプラグインの問題でしょうか。
ちょっと私、CONOHAに問い合わせてみます。でもCONOHAって対応よろしくないんですよね。。
2024年4月21日 23:01
SHION_SHIONさん
DBの接続先を変更したらやはりWPの設定を初期状態からやることになります。これがツライです。
元々の情報を控えておけば、もしくはコピー・アップロードすればできる言えばできますけれど。
しかし、それが根本的な解決になるとは思えないです。
画像が多いからでしょうか。。もしくはWPの設定やプラグインの問題でしょうか。
画像そのものは、データベースには保存されません。
画像そのものは、サーバーにファイルとして保存されます。
WordPressで管理するために、画像の情報がデータベースに保存されますが、所詮はテキストデータです。
（メディアライブラリに表示されるためには、データベースに情報登録が必要です）
とても、そんなに肥大する原因とは思えないです。
（プラグイン等の設定にしても、テキストデータですよね）
例えば、wp-postsには、以下のような情報が登録されますが、所詮はテキストデータでしかないです。
（以下のデータをSQLファイルとしてエクスポートしてみましたが、759Bytesでした）
wp-postmataにも登録はされると思いますが、やはりテキストデータですし。
ちなみに、私のサイトには画像は3～4万枚（サムネイルを除く）ありますが、それであれくらいです。
（35,000枚くらいから数えていません。データベースは100MBくらいで、サーバー側は5GB以上あります。）
データベース容量がいっぱいになってしまう原因は、少なくともしっておいた方が良さそうには思うんですよね。
（サイト構成や使い方によって違うのかもしれないですが、少し異常な容量な印象を受けてしまいます）
（サイト構成や使い方によって違うのかもしれないですが、少し異常な容量な印象を受けてしまいます）
SHION_SHION and わいひら reacted
トピックスターター 2024年4月22日 07:23
mk2さん。ご説明ありがとうございます。画像そのものはサーバーにファイルなんですね。
データベース内容の内訳を掴む方法がﾋﾟﾝとこないところで・・・
確かに肥大化してる原因が知りたいです。個人的に調べても現状掴めません。
最初から提示していればよかったのですが、以下の情報からなにかわかりますでしょうか。
ーーーーーーーーーーーーーーーーーーーーーーーーーー
----------------------------------------------
サイト名：東京トレンドニュース速報
サイトURL： https://tokyotrendnews2023.com
ホームURL： https://tokyotrendnews2023.com
コンテンツURL：/wp-content
インクルードURL：/wp-includes/
テンプレートURL：/wp-content/themes/cocoon-master
スタイルシートURL：/wp-content/themes/cocoon-master
親テーマスタイル：/wp-content/themes/cocoon-master/style.css
WordPressバージョン：6.5.2
PHPバージョン：8.2.15
ブラウザ：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0
サーバーソフト：Apache
サーバープロトコル：HTTP/1.0
エンコーディング：none
言語：ja,en-US;q=0.9,en;q=0.8,en-GB;q=0.7
----------------------------------------------
テーマ名：Cocoon
バージョン：2.7.2.6
カテゴリー数：249
タグ数：3589
ユーザー数：2
----------------------------------------------
Gutenberg：1
Font Awesome：4
Auto Post Thumbnail：1
Retina：0
ホームイメージ：/wp-content/uploads/2023/12/TOP_Image-Enhancer-scaled.jpg
----------------------------------------------
ブラウザキャッシュ有効化：0
HTML縮小化：0
CSS縮小化：0
JavaScript縮小化：0
Lazy Load：0
----------------------------------------------
利用中のプラグイン：
Advanced Ads 1.52.1
BlueskyTimeline for Wordpress 0.1.4
ConoHa WING コントロールパネルプラグイン 1.2
ConoHa WING 自動キャッシュクリア 1.0.0
SEO SIMPLE PACK 3.2.1
WP-Optimize - Clean, Compress, Cache 3.3.2
WP Headers And Footers 2.2.0
----------------------------------------------
2024年4月22日 18:15
SHION_SHIONさん
データベースは、外部からは確認のしようがありません。
そのため、申し訳ないですが、まったく分からないです。
プラグインは少ない方のように思います。
データベースは、「phpMyAdmin」のようなツールを使わないとアクセスできないです。
テーブルの中身を見て、これは本来あるべきものなのか、それとも必要のないのに増えているのか、など判断が必要な気はします。
ちなみに、以下のプラグインをご利用のようですね。
WP-Optimize - Clean, Compress, Cache 3.3.2
この管理画面で、テーブル別の容量は確認ができると思います。
異常に大きなテーブルがないか確認してみると、手掛かりにはなるかもしれません。
（ただ、詳細はテーブルの中身を見ないと分からないと思います）
データベースを触る際などは、事前にバックアップを取っておくことをお勧めします。
（何かあっても戻せるように。誤操作などで削除や更新などをしないか、注意は必要だと思います。）
ちなみに「WordPress データベース 肥大化」で検索すると、いくつかヒットします。
原因は人それぞれかと思いますが、参考にはなるかもしれないです。
あくまでも事例のご参考ということで、リンクしておきます。
（他にもいろいろヒットしますので、調べてみてください）
えっ！830MB！？WordPressのデータベースがめちゃくちゃ肥大していた件
https://www.taracohouse.com/blog/web/wp-database/
ワードプレスドクター 依頼事例:データベースの肥大化の解消
https://wp-doctor.jp/blog/2023/10/12/%E3%83%AF%E3%83%BC%E3%83%89%E3%83%97%E3%83%AC%E3%82%B9%E3%83%89%E3%82%AF%E3%82%BF%E3%83%BC-%E4%BE%9D%E9%A0%BC%E4%BA%8B%E4%BE%8B%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE-2/
SHION_SHION and わいひら reacted
2024年4月22日 18:32
@shion_shion さん
phpMyAdminで、DBの各テーブルの使用状態を、確認してみて下さい。
https://wp-cocoon.com/community/postid/77522/
上記の事もあり、以下のテーブルが肥大していると言う事はないでしょうか？
- wp_cocoon_accesses
- wp_options
SHION_SHION and わいひら reacted
トピックスターター 2024年4月22日 22:50
2024年4月22日 22:51
SHION_SHIONさん
各テーブルのサイズ（容量）だけであれば、以下プラグインで確認ができます。
WP-Optimize - Clean, Compress, Cache 3.3.2
大抵は100MB未満におさまると思います。（環境によって違うかもしれないですけど）
それを超えるようなサイズのテーブルがあれば、怪しいです。
SHION_SHION and わいひら reacted
トピックスターター 2024年4月22日 23:05
@chu-ya さん、ご無沙汰しております。
コメントありがとうございます！！！
phpMyAdminで、DBの各テーブルの使用状態を確認してみました。
（確認方法がこれで正しいか不安ですが、PDFでデータをアップしました）
- wp_cocoon_accesses
- wp_options
ともに肥大しているように見えます。これが原因でしょうか。
この投稿は8か月前ずつSHION_SHIONに変更されました
2024年4月22日 23:17
SHION_SHIONさん
このPDFは危険です、削除してください。
外部から、データベースへのアクセスを許してしまう可能性があります。
（phpMyAdmin経由での各テーブルへのリンクが埋め込まれています。）
私から、phpMyAdminが開けます。
（アドレスが、ConoHaのデータベースサーバーみたいです。）
SHION_SHION and わいひら reacted
2024年4月22日 23:29
SHION_SHIONさん
間にあったみたいですね。
良かったです。
ログイン画面を突破すれば、外部から直接データベースの操作が可能な状態でした。
ビックリしてしまいました。
SHION_SHION and わいひら reacted
トピックスターター 2024年4月22日 23:37
@chu-ya さん
@MK2 さん
各テーブルのサイズ（容量）を確認しました。
wp_posts、wp_postmetaが肥大化しています。
（Postieというプラグインを使ってメールで大量の記事を生成しておりました。）
これがあやしくないでしょうか。
2024年4月22日 23:40
SHION_SHIONさん
「wp-posts」の3.66GBは突出して多いですし、異常と言える気はしますね。
SHION_SHION and わいひら reacted
2024年4月22日 23:56
SHION_SHIONさん
「wp-posts」には、いろんなものが保存されています。
投稿ページや固定ページの中身は、「wp-posts」に保存されます。
（編集画面で、「下書き保存」や「公開」「更新」したものは、「wp-posts」に保存されます。以前書いた、画像の情報も）
SHION_SHION and わいひら reacted
2024年4月23日 00:04
SHION_SHIONさん
念のため、お伺いします。
リビジョンは溜まっていないですよね。
（WP-Optimize で、リビジョンのレコード数は確認できます。）
そうはいえ、とてもリビジョンごときで、こんな容量になるとは思えないですけれど、念のためです。
SHION_SHION and わいひら reacted
2024年4月23日 10:15
SHION_SHIONさん
データベースですので、ファイルとは呼びません。
「wp-posts」のようなものは、テーブルと呼びます。（レコードを格納するための器）
この中に、たくさんのレコードが入っています。
やはりリビジョンではないですよね。
今回の件は、この中のレコードの中身を確認をして、何が増えているのか確認する必要がありそうです。
phpMyAdminで直接閲覧するか、エクスポートしてから確認するか。
いずれにせよ、データベースを触ることになりますので、注意が必要です。
SHION_SHION and わいひら reacted
2024年4月23日 20:01
SHION_SHIONさん
ちなみに、以下で全部でしょうか。
使用量は以下のことですので・・・。
5123.55MB/5120MB（容量一杯使ってます・・という状況）
wp-postsが3.66GBだとすると、まだ他にもありそうな感じが。
wp-postsとwp-optionsのオーバーヘッドが、881MBと361MBと大きいですから、これを足すと1.2GBくらい。
そうすると、計算はあいそうな気はしますね。
（wp-optionsは、本体のサイズに対して、オーバーヘッドの方がかなり大きいです）
テーブル内のレコードの確認は、知識がないと難しいかもしれないです。
（ご存知でない、調べながらできない、そういう場合は、プロにお願いする必要があるかもです）
SHION_SHION and わいひら reacted
2024年4月23日 20:24
MySQLのオーバーヘッドも結構なものですね。
こちらの方法で最適化を行なうと881MB分空くのかな。wp_optionsもオーバーヘッドが大きいので、これも最適化した方が良いのかも。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
phpMyAdminの昨日使ったものなので、大丈夫とは思いますが、絶対は保証できません。事前にバックアップを取って元に戻せる体制を整えておく必要はあると思います。あくまで自己責任になりますので事前にご了承いただければ幸いです。
自信がない場合は、プロに依頼することを考えるのもありかもしれません。
ConoHa WINGは自動バックアップ・リストア機能があるので、これで戻す方法はあると思います。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
※戻せても1日前とかになると思います。
※mk2さんさんと書き込み内容がかぶってしまったようです。
この投稿は8か月前 5回ずつわいひらに変更されました
SHION_SHION reacted
2024年4月23日 20:49
phpMyAdminでwp_postsの構造はどのようになっていますか？スクリーンショットを頂ければ幸いです。
一般的なwp_postsの構造はような感じです。
この投稿は8か月前ずつわいひらに変更されました
SHION_SHION reacted
2024年4月23日 21:30
ちょっと私の環境で確認したのですけれど。
「WP-Optimize」で、「wp-posts」のレコード数の確認ができますが、ちょと違和感のある数字でした。
（5,000レコード台）
そこで、「phpMyAdmin」で、同じく「wp-posts」のレコード数を確認すると、2倍くらいの数字でした。
（10,000レコード台）
「phpMyAdmin」のレコード数は、しっくりくる数字なんですよね。
データサイズは両方とも差異はほぼ無い感じでした。
「WP-Optimize」のレコード数は、何を表示しているのでしょう？
レコード数に関しては、「phpMyAdmin」で確認した方が良いような感じがします。
（誤操作には気をつけてください）
もしかすると、もっとレコード数が多いのかもしれないです。
（私の環境と同様の状態が発生していれば）
SHION_SHION reacted
トピックスターター 2024年4月23日 23:21
ちなみに、以下で全部でしょうか。
DBをいじっていたら壊れてしまって3日前のDBをバックアップから取り込みました。
その内容を添付します。
テーブル内のレコードの確認は、知識がないと難しいかもしれないです。
（ご存知でない、調べながらできない、そういう場合は、プロにお願いする必要があるかもです）
たしかに難しかったですが、こういう壁を乗り越えて知識が付くと思いがんばります！！！
2024年4月23日 23:39
SHION_SHIONさん
DBをいじっていたら壊れてしまって3日前のDBをバックアップから取り込みました。
気をつけましょう、本当に。
添付いただいた画像は貼り付けさせていただきますね。
3日前とのことですけれど。
以前添付いただいたものと比較すると・・・。
「wp-posts」が、3.66GB ⇒ 4.32GBと、僅か数日で600MB以上変化があります。
レコード数は、41,924件 ⇒ 63,292件と、21,000件以上変化があります。
（このプラグインのレコード数を信用して良いのかはありますけれど）
（このプラグインのレコード数を信用して良いのかはありますけれど）
ちょっと尋常ではないと思います。
（人間の手で、こんなレコード数を追加ができるものなのか・・・）
（人間の手で、こんなレコード数を追加ができるものなのか・・・）
SHION_SHION and わいひら reacted
トピックスターター 2024年4月23日 23:51
@yhira アドバイスありがとうございます。
MySQLのオーバーヘッドも結構なものですね。
こちらの方法で最適化を行なうと881MB分空くのかな。wp_optionsもオーバーヘッドが大きいので、これも最適化した方が良いのかも。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
添付のようにオーバーヘッドの項目がないので「行」に数値があるのもを最適化いたしましたが、
最適化前後のオーバーヘッド容量に変化がございませんでした。
トピックスターター 2024年4月23日 23:55
これは
ゴミ箱にあった６０００記事程度を削除した結果、このように容量が増えました。
たしかにこの６０００記事を削除したとたんに容量が増えました。
削除しないでおいておくのも気持ち悪いですが、そのままにした方がいいのでしょうか。。
2024年4月24日 00:01
SHION_SHIONさん
ああ、3日前ということは、時系列で言えば・・・。
容量は、4.32GB ⇒ 3.66GB
レコード数は、63,292件 ⇒ 41,924件
ゴミ箱のものを削除した結果、上記のように変化したということですね。
ゴミ箱のものは、再利用することがないのであれば、削除して問題いなと思います。
むしろ、6,000件もあれば、容量圧迫の原因になると思います。
（6,000件、それぞれにリビジョンが3～4件あれば、万単位レコードは減るのかも？）
SHION_SHION and わいひら reacted
2024年4月24日 05:22
SHION_SHIONさん
もしかして、私変なこと言っていますか？
一度、時系列にご説明いただくと助かります。
できるだけ主語を省かず丁寧めだと助かります。（私は察しが悪いもので）
SHION_SHION reacted
トピックスターター 2024年4月24日 17:49
今回の問題にコメントをいただきありがとうございます。
以前からトラブルが解決できないときにはこちらのフォーラムに救われております。
ｍｋ２さんは変なこと言ってません！！！
私がちょっといっぱいいっぱいなので、フリーズしておりました。
（途中いただいた質問にもわかる範囲で回答していきます）
みなさんのコメント内容から、色々試していたらよい進捗がありました！
結論からお伝えすると、
①3日前のDBのバックアップデータで復元
（現状容量がフルだったので、少し空きのある過去の状態に戻した）
②phpMyAdminのクリーニング、WP-Optimizeでのクリーニング
これでDBの容量が「1603MB/5120MB」となりました！！！！！！！！！！！
DBの容量がフルだと、様々な処置も上手くいかないのではないか・・・と思っております。
今までの流れをここ記載したいのですが、画像を入れる方法がわからず添付ファイルにまとめました。
解決と言ってもよいのではないでしょうか。
なぜDBの容量が増えたのかは不明瞭ですが、、、、
2024年4月24日 20:17
docxの内容を貼り付けておきます。
以下転載します。
--------------------------------
今回の問題にコメントをいただきありがとうございます。
以前からトラブルが解決できないときにはこちらのフォーラムに救われております。
みなさんのコメント内容を見返して、よい進捗があったので時系列含めてご報告します！
ｍｋ２さんは変なこと言ってません！！！
私がちょっといっぱいいっぱいなので、フリーズしておりました。
（途中いただいた質問にもわかる範囲で回答していきます）
――――――――――――――――――――――――――――――――――――
■04/21
CONOHAWINGで運営しているサイトのDBがいっぱいになって記事が追加できない状況になる。5123.55MB/5120MB（容量一杯使ってます・・という状況）
データベース容量ががこんなに多くなることが異常で理由が不明。
サイトの記事数は「1万弱」、ひとつの記事の文字数ははざっくり平均5万文字程度。
――――――――――――――――――――――――――――――――――――
※主にテキストデータでるのにここまで容量が増える理由は把握しておく必要性がある。
――――――――――――――――――――――――――――――――――――
■4/22
データベースは、「phpMyAdmin」のようなツールを使わないとアクセスできない
ことを知る。テーブルの中身を見て不要なものを判断する必要があるかも。
（ちゃんとバックアップとってから！☞CONOHAは自動バックアップなのでOK）
個人的に調べたら、このプラグインでDBをクリーンにできるのではないか
WP-Optimize - Clean, Compress, Cache 3.3.2
「データベーステーブルの最適化」と「すべての投稿リビジョンをクリーンを実施」するも
データサイズ、オーバーヘッドのボリュームに変化なし。
えっ！830MB！？WordPressのデータベースがめちゃくちゃ肥大していた件
など事例をいただくがちょっとわたしにどって手を付けづらく内容のみ確認。
phpMyAdminで、DBの各テーブルの使用状態を、確認
wp_postmeta、wp_posts、wp_optionsなどが大きい（行でしかサイズを確認できない？？）。
各テーブルのサイズ（容量）だけであれば、プラグインで確認ができるので
確認してみた。
WP-Optimize - Clean, Compress, Cache 3.3.2
「wp-posts」には、いろんなものが保存されています。
投稿ページや固定ページの中身は、「wp-posts」に保存されます。
（編集画面で、「下書き保存」や「公開」「更新」したものは、「wp-posts」に保存されます。以前書いた、画像の情報も）だから消してはいけない！
また、リビジョンも溜まってない。
phpMyAdminで直接閲データベースを触る決心が固まる。
――――――――――――――――――――――――――――――――――――
■04／23
MySQLのオーバーヘッドも結構なものなので、
こちらの方法で最適化を行なう。
https://webkaru.net/mysql/phpmyadmin-optimize-database/
☞この方法ですが、DBの内容をいじって壊した後に、バックｱップから復旧させた後に
もう一度実施したら効果がでました。後ほど記載します。
※わいひらさんからのご質問
3.66GBはかなりのものですね。1記事あたり本文はだいたい何文字ぐらいでしょうか？
☞おおよそ5万文字程度です。少ない文字数から10万文字程度のものまで様々です。
phpMyAdminでwp_postsの構造はどのようになっていますか？スクリーンショットを頂ければ幸いです。
わいひらさん、こちらになります。
MK２さんから
WP-OptimizeとphpMyAdminでのレコード数に違和感があるとコメントをいただく。
わたしのDBで確認、wp_postsで比較すると
WP-Optimize：36,270
phpMyAdmin：38,092
レコード数に関しては、「phpMyAdmin」で確認するようにします。
また、BDをバックアップから復帰させた際に「wp-posts」が、3.66GB ⇒ 4.32GBと、僅か数日で600MB以上変化があった。これはゴミ箱にあった不要な記事６０００件を削除したことが原因。（BDをバックアップから復帰させた後のCONOHA管理画面でのDB容量の4720.2MB/5120MB）
――――――――――――――――――――――――――――――――――――
■04／24
BDをバックアップから復帰させた状態でクリーンの処置（phpMyAdminのクリーン、WP-Optimizeでのクリーニング）をしたら、以下の変化がありました。
- WP-Optimizeでの状況
- phpMyAdminでの状況
- CONOHA管理画面でのDB容量は変化あり！！！ 2MB/5120MB
現在は③の状態となっており、だいぶ容量が削減できております。
結果、3日前のDBのバックｱアップから、各種クリーニングを実施して削減できました！！！
2024年4月24日 20:43
②phpMyAdminのクリーニング、WP-Optimizeでのクリーニング
phpMyAdminのクリーニングってなんだろう。最適化とまた違うものなんでしょうか？
2024年4月24日 22:47
SHION_SHIONさん
どちらも「最適化」をなさったということですね。
ゴミがたくさん溜まっていた感じみたいですね。
2024年4月28日 15:23
SHION_SHIONさん
DBが満タンのままでは最適化が正常にいかないのではないでしょうか
空き領域がないのに、最適化はできないと思います。
昔は使っていたけれど、今はデータ削除された領域があれば、最適化をすれば開放されると思います。
その他にも、領域の再配置など行われて、断片化されたデータが整理されるイメージではないかと思います。
WordPressのゴミ箱に入っている状態は、まだデータは生きていますから、開放のしようもないと思います。
ちなみに、このトピックは「解決済」でよろしいのでしょうか？
（当方にて「解決済」にさせていただきました。もしそうでないならば、解除していただいてもOKです）
わいひら reacted
問題の解決に至った場合には、トピック冒頭の「解決済み」をクリックしていただけますと幸いです。
また、有用な回答があった場合は返信右下にある「いいね！」もご活用ください。回答者の励みになります。
（CC BY-ND 2.1）準じていれば（リンクを貼っていただければ）転載も自由です。カスタマイズ記事を書く際にコード等をコピペ利用していただいて構いません。
フォーラムの使い方がよくわからない場合は、テストトピックで自由にテストしていただいて構いません。
最近の書き込みはこちら。
詳細なカスタマイズ依頼をするならこちら。