最初にいくつかの説明：
クエリ結果をキャッシュするとは、結果を保存することを意味します。したがって、次のページの読み込みでは、時間のかかるSQLクエリを再度実行する必要はありません。
レンダリングされた出力をキャッシュするとは、生成されたHTML出力をキャッシュすることです。システムはページを再度レンダリングする必要はありません。
結局のところ、これらのexipireのほとんどが同時に存在することは理にかなっています。データが変更された場合、ユーザーに変更を表示する必要があります。
クエリ結果をSQLデータよりも長くキャッシュすると考えられる唯一の状況は、テンプレートファイルが頻繁に変更される状況です。テーマによって、テーブルの各行の色がランダムに変化したり、現在の時刻（テーマ変数と前処理関数によって提供された）がディスプレイに表示されたりすることがあります。これをキャッシュに入れずに、ページを比較的高速に配信しながら、ユーザーにデータが最新であるという印象を与えることができます。
レンダリングされた出力をクエリよりも長くキャッシュすることは悪い考えのようです。新しいデータに対してリソースを大量に消費するSQLクエリを実行しますが、代わりに古いデータを表示することを選択するため、データを直接破棄します。だから私はそうしないことをお勧めします。
クエリ結果
以下は、クエリ結果のキャッシュ時間の選択に影響を与えるいくつかの状況（ケース）です。
ケース1-リソースに制限はありません
実行に非常にコストがかかるクエリ（たとえば、メモリなど、必要なサーバーリソースの数）。それに必要なリソースは限られています。
ケース2-データが定期的にのみ変更される
これらのクエリの対象となるデータが、日、週、月、年に1回だけ更新されることが確実なクエリ。
ケース3-最新の情報は無料ではない
データが株式、商品などの現在の値（市場価値）に関するものであると想定します。プレミアム価格を支払うことをいとわないユーザーは、X秒/分ごとに更新を受け取りますが、その価格を支払うことを望まないユーザーは、それらの更新を毎日1回程度しか取得しません。
レンダリングされた出力
サンプルは、このビューを BigPipeテクニック を実装しようとしているサイトで使用している場合です。Drupal 8's- BigPipe module。プロジェクトページからの引用です：
ブラウザがより速く表示できるようにページを送信します。最初にページのキャッシュ可能な部分を送信し、次に動的/キャッシュ不可の部分を送信します。
このプロジェクトページのすばらしいビデオを参照して、アイデアを取得してください。また、これらの関連リンクを参照してください。
- 「 レンダー配列のキャッシュ可能性 」に関するコミュニティのドキュメント。
- 「 認証ユーザーのためのBigPipe：最初にページの安価な部分を送信してレンダリングし、次に高価な部分を送信する に関するDrupalコアの問題。
結論
IMOがこれら2つのキャッシングオプションのいずれかの値を選択することは、他のキャッシングオプションとは独立して行われる必要があります。そして、それらの値が同じに設定されていても、同じである必要があるという本当の理由はありません。