Здравствуйте.

Есть таблица, с двумя основными полями - uid и status
+------+--------+---------+
| id | uid | status |
+------+--------+---------+
| 1 | 1 | 1 |
| 2 | 1 | 1 |
| 3 | 1 | 0 |
| 4 | 3 | 0 |
| 5 | 3 | 0 |
| 6 | 4 | 0 |
| 7 | 4 | 1 |
| 8 | 4 | 0 |
| 9 | 4 | 1 |
| 10 | 4 | 0 |
| 11 | 5 | 0 |
| 12 | 5 | 1 |
+------+---------+---------+

Нужно сделать выборку id по определенным условиям (uid > n и status = 1)
НО нужно, чтобы возвращались все подходящие строки только для одного uid, который я заранее не знаю. Пример:


Мне нужны строки 1 и 2 только для uid 1, т.к. на него пришлось первое вхождение
Другой пример:


В данном случае нужны строки 7 и 9, т.к. первое вхождение по условию пришлось на uid 4 и у него 2 совпавших поля.

Пробую сделать при помощи переменной:



Возвращает то что нужно - 1 и 2
Все замечательно получилось, но когда применил данный способ в проекте, вылезла неприятная вещь - запрос возвращает чушь после применения сортировки ORDER BY t.uid ASC;
Без сортировки не обойтись никак. Если в таблице значения uid идут не по порядку (что в проекте - обычное дело):
+------+--------+---------+
| id | uid | status |
+------+--------+---------+
| 5 | 3 | 0 | <сначала 3
| 6 | 4 | 0 |
| 7 | 4 | 1 |
| 8 | 4 | 0 |
| 9 | 4 | 1 |
| 10 | 4 | 0 |
| 11 | 5 | 1 |
| 12 | 5 | 1 |
| 13 | 6 | 0 |
| 14 | 1 | 1 | <затем 1
| 15 | 1 | 1 |
| 16 | 4 | 1 |
+------+---------+---------+

То при том же запросе с t.uid > 0 вернет строки для uid = 4, т.к. она стоит раньше, а записи для uid = 1 не вернет НИКОГДА.

После модификации запроса и добавления к нему ORDER BY t.uid ASC по логике должно вернуть 14 и 15 строки, но результат оказывается непредсказуем:
Возвращает по порядку 14, 15, 7, 9, 16, 11, 12 - хотя на первых двух результатах ему следовало остановиться.

Самый очевидный вариант:


не подходит, нужно избавиться от необходимости делать двойную выборку и избавиться от подзапроса и дупликации условий. В проекте очень большой список WHERE и огромный объем данных в таблице. Данный способ замедляет запрос в 200 раз.

В чем может быть проблема моего варианта?
Или может я некорректный способ выбрал для реализации данной задачи?

tanglir, да, такой индекс есть. Dependent subquery была в эксплейне. Попробовал Ваш способ. Стало быстрее, но все равно - с этим джойном медленне в 32 раза. В проекте запрос выглядит так:




Как видите, в запросе 4 лефт джойна, получается что при подзапросе, или джойне в вашем случае - количество лефт-джойнов повышается в 2 раза. Запрос сам по себе не быстрый. Может есть еще какие-то варианты?