x-yuri, а можешь выложить сюда дампы? Я тоже погоняю.

С разбаниванием - да, точно. Строки все таки помечены направлениями. Дубляж по объему в 2 раза будет, но из цифр - не сильно значительный наверное. При большом числе пользователей- так наверное и лучше всего сделать. Я про оптимальность собственно и не думал. Миллионы зареганных одновременно пользователей на сайте - больше мечта чем реальность :) .

удалено.

это бажок в мускуле версий до 5.6.
Фиксится так: Добавь плиз индекс в таблицу banned_2:
и скажешь результат.

почти догнал :)

mysql> SELECT u.id
    -> FROM users_2 u
    -> WHERE u.id != 5
    -> AND u.id NOT IN
    ->   (
    ->     SELECT IF(b.idu = 5, b.idb, b.idu)
    ->     FROM banned_2 b
    ->     WHERE b.idu = 5 OR b.idb = 5
    ->   )
    -> ORDER BY RAND()
    -> LIMIT 1;
+-------+
| id    |
+-------+
| 26202 |
+-------+
1 row in set (0.54 sec)

explain:

*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: u
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 13847
        Extra: Using where; Using index; Using temporary; Using filesort
*************************** 2. row ***************************
           id: 2
  select_type: DEPENDENT SUBQUERY
        table: b
         type: index_merge
possible_keys: PRIMARY,idb
          key: PRIMARY,idb
      key_len: 4,4
          ref: NULL
         rows: 3
        Extra: Using union(PRIMARY,idb); Using where

а у меня стоит в PRIMARY KEY добавить origin, иначе если два пользователя попытаются друг друга забанить, один из них рискует получить ошибку 1062 Duplicate entry, а то и целостность нарушится

а по поводу DEPENDENT SUBQUERY, люди даже целую хранимую процедуру написали

:lol:

старался :)

а по поводу целостности, вы как считаете, надо ли рассматривать всякие неизвестно-насколько-вероятные-ситуации? Например, между первым и вторым INSERT'ом mysql вырубило. И вообще, можно ли считать, что INSERT либо выполнился либо нет? Ведь, например, с помощью INSERT можно вставлять несколько записей. Ну и речь не только об INSERT, конечно же

p.s. да, Gozar, должен признать, что чтение английских ресурсов сказывается на мне, но я не уверен, что это плохо :)

Одним insert-ом несколько записей - команда поступит к mysql и выполнится, разрыва думаю не может получиться.
Если сильно критично - возможность транзакций надо поюзать.

нет, дело не в критичности. Дело в выборе: MyISAM vs InnoDB, READ UNCOMMITTED vs READ COMMITTED vs REPEATABLE READ vs SERIALIZABLE. Исключительно в контексте целостности БД. В каких единицах измеряется критичность? В долларах чтоле? :lol: И как ее посчитать, а тем более спроецировать на выбор движка, уровня изоляции? И ты знаешь, в каких именно случаях может нарушиться целостность, без думаю?

Ну вот у тебя если сбой запроса произойдет и одна запись останется без ее дубля - целостность нарушена.
Но например твой код для user1 ищет кандидата user2, находит не того(из-за ошибки). Но перед соединением ты для user2 все равно проверяешь возможность работы с user1. Программа выяснит разногласие, не позволит соединиться и возможно устранит неточность. Или по крону. Т.е. приложение будет работать как надо.
Можно считать что возможность ошибки при записи - не критична :) .