管理画面の投稿一覧に記事のIDを表示するようになってから、その数字の進み具合がWordPressをインストールしたばかりの頃と比べ早くなっているのに気づきました。
記事IDが捗り過ぎる原因はリビジョン機能？
WordPressでは、投稿記事の積み上げや画像のアップロード、プラグインのインストールにより、サイト開設当初より記事や画像に割り振られるIDの数値が大きくなっていきます。
順調に運営が進むにつれて、数値が進む速度が速くなることにも気づくことになるでしょう。
どうやらこのIDは、リライトなどでページを修正するたびにも消費される（リビジョンごとにもIDが割り振られる）ようです。
つまり、記事を元に戻す機会がなければ使わない修正履歴がデータベースの中に積みあがってきます。
サイト管理に真剣になり、毎日リライトに励めばその分データベースが大きく成長することになります。
リビジョン機能の停止
大きく変更を加えたページの内容を元に戻す際には、リビジョン機能は特に便利でしょう。
しかし、運用の仕方によってはリビジョン機能に一切頼ったことがないという方もいらっしゃることでしょう。
自分の場合も、リビジョン機能は年に1回も使いません。
データベースのバックアップさえ頻繁に行っていれば、テキストデータの参照くらいは何とかなるという人ならリビジョンは停止してもよさそうです。
リビジョンの停止は次の一文をwp-config.phpファイルに書き足すのが一般的なようです。
define('WP_POST_REVISIONS', false);エディタで編集後に上書き保存でアップロードすればリビジョン機能が停止し表示もされなくなります。
上のコードを描く場所はrequire_once(ABSPATH . 'wp-settings.php');の上と案内されていることが多いですがWordPressをインストールした時期によって違いがあるようです。
バージョンによっては
/* カスタム値は、この行と「編集が必要なのはここまでです」の行の間に追加してください。 */
と書かれている部分がありますので、このメッセージが書かれた行の真下へdefine('WP_POST_REVISIONS', false);を注釈付きで記述すればよいでしょう。
データベースに重複して保存される記事の編集履歴
少し前のことですが、新規に作成したサイトへ既に閉鎖したサイトにあげていた記事を移転させる作業を行いました。
Webサイトは既に閉じているので、エクスポートしていたSQLのバックアップファイルを元に記事のテキスト文を参照したのですが、リビジョン機能で保存された投稿記事の編集履歴が複数レコードで保存されていました。
データベースには各リビジョンごとにレコードが作成されるようです。
この履歴をたどりリライトなどを行う前の状態に戻したいときは非常に助かるのですが、WordPressの使い方によっては、そうした作業自体が稀だという方も少なくないことでしょう。
日常から、細かな誤字や脱字もチェックし記事を磨き上げたい人にとっては停止するなり、リビジョンの数を制限をするなど調整したほうがデータベースもシンプルなまま維持できそうです。
おすすめ記事
サブドメインからサブディレクトリへのリダイレクト設定 
WordPressで有料テーマは必要か 
WordPressでタイトル下のアイキャッチ表示をどう運用するか 
グーテンベルク（Gutenberg）が使いこなせないWordPress7年目の言い訳 
サイドバーの新着記事表示を再開することにした 
サイトを追加するならサブドディレクトリよりサブドメイン【注意点あり】
