Как вам такой MySQL запрос?

да почти никак. условие OR не дружит с индексами.

мне кажется, здесь два раза лишнее условие с != ибо незачем скрывать от пользователя переписку с самим собой ))) она вообще есть?
но я не думаю, что упрощение до (sender_id=93 or recipient_id=93) радикально улучшит скорость. можешь попытаться заменить его на UNION или UNION ALL

Код (Text):

1. SELECT blablabla... JOIN tyctyctyc
2. WHERE sender_id=:ID
3.   UNION ALL
4. SELECT blablabla... JOIN tyctyctyc
5. WHERE recipient_id=:ID

это выглядит хуже, чем работает попробуй и сравни
--- Добавлено ---
P.S. предполагаю, что у тебя есть индексы по sender_id и recipient_id

 

Я, чтоб не делать такие запросы, храню сообщения отдельно. У меня таблицы dialogs, messages, dialog_user. dialog_user - это, соответственно, связующая таблица для "многие-ко-многим", а в messages есть только from_id, recipient_id не нужен. В результате я делаю простую выборку по messages, и всё. Когда-то у меня получился подобный запрос, когда я начал как @artmirartem решать эту задачу, я ему ужаснулся, и решил переделать архитектуру. Пришёл к этому решению, и очень доволен. Уже на нескольких проектах проверено.

 

Код (Text):

1.  
2. select du.dialog_id from dialog_user du join dialog_user du2 on du2.dialog_id=du.dialog_id  where du.user_id=1 and du2.user_id=4;

Как-то так. Свой код прямо сейчас лень поднимать.
--- Добавлено ---
Самое крутое в моём решении, что оно подходит и для чатов с большим количеством участников.

 

Не понял вопроса. У тебя диалог между двумя пользователями, которые заранее известны, так? Если один из них отправитель, то другой - получатель. На этом и основано моё решение не хранить получателя в messages, а хранить только id диалгога. А если речь идёт о последнем сообщении, то можно ввести поле last_message_id в таблицу dialogs, и подновлять его. Но твой проект, тебе решать. Я тебе это привёл не для того, чтобы сказать, что моё решение самое лучшее. Для меня это так, поскольку я получаю сообщения совсем элементарным select-ом. И остальное в принципе тоже не самыми сложными запросами. Иконку получателя правда мне ни разу не приходилось выводить, обычно идёт иконка отправителя.

 

Ну я могу код Laravel показать. У меня все эти проекты на Laravel

PHP:

1. $models = Dialog::query()
2.       ->withParticipant($user)
3.       ->with("users")
4.       ->with("lastMessage")
5.       ->orderByDesc("last_message_date")
6.       ->get();

PHP:

1. class Dialog extends Model
2. {
3.     use ReadCountable;
4.     protected $casts = [
5.         'deleted' => 'array',
6.     ];
7.  
8.     public function messages()
9.     {
10.         return $this->hasMany(Message::class);
11.     }
12.  
13.     public function users()
14.     {
15.         return $this->belongsToMany(User::class);
16.     }
17.  
18.    
19.    public function lastMessage()
20.    {
21.        return $this->hasOne(Message::class, "id", "last_message_id");
22.    }
23.  
24.    
25.    public function scopeWithParticipant(Builder $builder, $participant)
26.    {
27.        return $builder->join("dialog_user as du", "dialogs.id", "=", "du.dialog_id")
28.            ->where("du.user_id", $participant instanceof User ? $participant->id: $participant)
29.            ->where("du.hidden", 0);
30.   }
31. }

Т.е. соответственно, некоторые вещи делаются в два запроса. Ну один или два запроса - для меня непринципиально. Много раз убеждался, что один или два на время выполнения заметным образом не влияет, влияет разница в десятки раз.
--- Добавлено ---
Можно и в один запрос нагородить, в принципе, если самому запросы все писать, не использовать Eloquent. Но я использую.

 

Оставлю здесь ссылочку на свой старый ответ по близкой теме:
https://php.ru/forum/threads/sistema-soobschenij.57436/#post-462055
в тот момент писалось на лету, не проверяя запросы, так что безошибочность не гарантирую )))