ユーザーIDインデックスを使用するだけでもかまいませんが、結合の方がchar/varcharよりもはるかに高速です。これを追加するのにかかる2秒で、誤ってスキーマの機能を拡張する必要が生じた場合に、後で多くの時間を節約できます。
考えるべきいくつかの落とし穴：
- 将来的にいくつかのテーブルを追加するとします。誰かがユーザー名を変更したい場合はどうなりますか？
- アプリは私たちが考えるよりも成功していると言います。最適化を検討する必要があります。この時点でスキーマをやり直して、varcharされたインデックスのオーバーヘッドを削減しますか？