アプリのDB事情

はじめまして。
同じ悩みを抱えていくつかパターンを試して運用したことがあります。

1. blob typeにしてgzipを保存する
   テキストをgzip圧縮してvarcharやtextなどではなくblobとして保存します。データを取り出す時に解凍する必要があります。

メリット: サイズが減る
デメリット: 毎回gzip処理をするのでCPUを使う。テキスト検索はできない。

1. S3やDynamoDBなどに保存する
   s3, data
   というカラムを作って、保存するテキストが大きい場合は
   s3=1, data=NULL (データはS3に保存する)

保存するテキストが小さい場合は
s3=0, data='テキスト' (データはMySQLに保存する)
という感じです。

メリット: 仕組みさえ作れば、長文のテキストの扱いも気にならない。
デメリット: 多くのテキストを一覧で出したい時に処理が大変 (行数分、s3にアクセス)、テキスト検索はできない。

1、2だけじゃないですが、特殊な保存方法にするとサービスの途中で変えるのが難しいです。後で不都合が見つかった時に困ります。
私は抵抗がありそうな大きいテキストのデータも、text typeにしてMySQLに保存することにしています。（普通の方法）

色々な方法を試した上での結論です。メンテナンスのコストもデータの保存効率と同じくらい重要だと実感しました。
（時間に余裕があれば是非、色々なアイデアを試してみることをお勧めします。自分の中で、より納得できると思います。）

ダラダラと個人的なことを書き連ねてすいません。少しでも参考になったら嬉しいです。

■私の意見を述べる前の話

投稿者の方が考える具体的な手法があり、
ディスカッションに参加する「意見交換」というより
単純な「質問」に見えるので投稿時に「質問」を選択した方が良いかと思います。

---

■本題

以下、私の意見を述べます。
※PostgreSQLメインユーザなのでMySQL特有の作法に疎い点があります
(ズレている意見があれば申し訳ないです)

そのため投稿内容に絵文字が入ったりする場合,Mysqlに直接table内に保存することでデータが膨らみ複雑になると思いに抵抗があるのですが,

絵文字も結局、文字コードなので
「文字コードのバイト数を考慮し、対応する文字コードを利用できるようにする」
ということ以外回答できません。(直接保存する方法しかないと思われます)

■参考(古い記事ですが根本的な技術は変わらないので読んでみてください)
※必要であれば参考記事を基に新しい情報を調べてみてください

---

DBを使用して開発する場合,投稿データやお気に入り情報はどのように保存していますか

こちらについては、DB設計の段階で
「リレーション(シップ)」「正規化」について
考慮し保存するようにしているという回答になります。

特に「お気に入り情報」については
恐らく「多：多」の関係になると思うので「中間テーブル」
というワードも理解が必要かと思います。

■参考

・リレーション

・正規化

・中間テーブル

---

Mysqlに直接table内に保存することでデータが膨らみ複雑になると思いに抵抗があるのですが

ここからは想像ですが
「投稿に画像を付与するような」レベルのことを
想定するとしたら確かに「データが膨らみ」ます。

前述のレベルを想定しているのであれば
「SQLアンチパターン ファントムファイル」などで調べてみてください。

直接保存する・しない、それぞれのメリットがあるので
調べて吟味した上で判断してください。

■参考

そのため投稿内容に絵文字が入ったりする場合,Mysqlに直接table内に保存することでデータが膨らみ

絵文字のデータ量って極小じゃないですか？
文字と変わらず