Чем занимаются JS-программеры.

[micscr]

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

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

[x-yuri]

дамп

[Gozar]

удалено.

[micscr]

интересно, кстати, micscr, что хоть твой подзапрос вроде никак не связан с внешним, но mysql его пометил как DEPENDENT SUBQUERY

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

ALTER TABLE banned_2 ADD INDEX (idb)

и скажешь результат.

[x-yuri]

почти догнал

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, люди даже целую хранимую процедуру написали

The real issue is that the subquery here is not really dependent on any of the columns in the outer query. The subquery will return the same result every time it is evaluated. You know that. I know that. But MySQL does not know that.

[micscr]

почти догнал

старался

[x-yuri]

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

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

[micscr]

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

[x-yuri]

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

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

[micscr]

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