• イベント情報を記録する events テーブル（マスタ）

• event_id | event_name | stat_date | end_date

• イベントごとのユーザのスコアを記録する event_users テーブル

• event_id | user_id | score | created_at | updated_at
• イベントごとのスコア昇順index

•  index_event_id_and_score_on_event_users (event_id, score_id)

• じゃあイベント期間外のデータを消してしまえばいいのではないか？

• イベント期間外のデータをユーザに提供しないのであればそれで対処可能ですが、「過去のイベント情報を見ることができる」という機能を提供することもできなくなります

• じゃあイベント期間外のデータを別テーブルに逃してしまえばいいのではないか？

• それも一つの手段であり、広義では上記の年度で分ける水平分割と同じことです
• この辺り、どういう単位で分割するのかはバックエンド側の実装や組織の判断によって異なるはずです

• 参加してないユーザの情報はINSERTしないとか、各種ユーザのINSERTはイベント開始時に一気にやってしまうとかの手法もあるのでは

• 負荷対策を目的としてどういう手段を取るのかは色々あるので、今回の例のうにデータベース側で対策するのではなくバックエンド側の実装で対処するというのも十分あり得ます。スコアのようなものを記録するのはRDBではなくNoSQLのようなものを使うという手法など色々ありますね

水平分割は水平分割したものを跨ぐような検索に弱いですし
垂直分割はレコード数が起因となる上記例のようなものの対策には効きにくいです
水平分割も垂直分割も行わずデータベースのスペック引き上げで対処するというのも１つの判断です
RDB（リーレーショナルデータベース）じゃないものを使うという手ももちろんありますどれもメリットデメリットあるので目的に応じて適切な手段を考えられるようになるのが大事ですね

このような事例と対策のような話はインターネットに多く公開されており
ChatGPTにも大量の解決事例がパラメータとして学習データに入っている（はず）ですから
「こういう問題が発生しそうなんだけど水平分割や垂直分割で対応できるか？」
「水平分割と垂直分割どちらかを採用して対策するならどちらが適切か」
などChatGPTにきいてみるのもいいと思います。