Так посмотрите что у вас в таблице написано:
    (8, 1, '2015-10-26 18:45:34', 'success'),
    (9, 4, '2015-10-26 19:32:34', 'success'),
ТОесть и 1 и 4 заходили менее суток назад успешно. если вы измените время или дату чтобы было больше суток то все будет.

Почему моему не пох? Мой запрос вернет 0 в этом случае, что вполне нормально для меня. Нет логов по входам, то нет от чего отолкнутся. Логи никогда не будут чистится. Даже если такое и случится, то там уже ручная блокировка этих заявок будет по дате создания заявки. Случай 1 на миллион.

Добавлено через 6 минут и 23 секунды
Garmahis, возьмем кусок из базы



если по моим условиям строка с failed сразу отпадает, далее сработает сортировка на убывание



после я использую лимит 1 и связь между таблицами, что даст для первого клиента такую выборку



а для второго



Если мы применим еще условие со временным интервалом в 1 день, то второго сразу нам должно вывести, для него уже 1 день прошел, а вот для перого нет и мы его не выводим.

Давай уточним задачу.
Твоя версия такая: вывести, если последний вход сделан более суток назад.
Моя версия: вывести, если за последние сутки не было сделано входа.
Какая формулировка правильная?

Не понял. У обоих интервал меньше одного дня. сейчас 2015-10-27 14:14 соотвественно все кто больше 2015-10-26 14:14 меньше суток.
Соотвественно второй попадет в выборку после 19:32 сегодняшнего вечера

Это сообщение отредактировал(а) Garmahis - 27.10.2015, 14:18

Эта формулировка. Т.е. если человек не входил более суток в систему, мы его заявку считаем просроченой.

Добавлено @ 14:22

прошу прощения, ввел в заблуждение, да вы правы, в датах я запутался

Добавлено @ 14:27
Garmahis, Akina, ваши варианты верны, это я с датами запутался уже, спасибо

Это сообщение отредактировал(а) swordfishik - 27.10.2015, 14:27

Конструкция

предполагает иднтичность этой?

Нет.
В конструкции [NOT] EXISTS проверяется сам факт наличия записи, соответствующей условиям отбора, и пофиг, что там в выходном наборе. Выводить при этом в выходной набор статический литерал проще, дешевле и быстрее, чем поле из записи таблицы.

Гениально, учту на будущее. Теперь я понял, почему вы не использовали обратную сортировку с лимитом, они роли не играют. Хотя лимит 1 можно и использовать, дабы меньше отбирало во вложенном запросе, все же быстрей будет, верно?

MySQL при обработке конструкции [NOT] EXISTS прекращает выполнение подзапроса, как только найдётся первая соответствующая запись, и это явно описывается документацией. LIMIT абсолютно не имеет смысла.

Добавлено через 1 минуту и 35 секунд
Точно так же обрабатывается и =ANY (=SOME). И инверсно обрабатывается =ALL.

спасибо, упустил этот момент я