MySQL
Сделал три запроса дающих нужный результат, какой быстрее?

#1
select (select datetime from t1 where t1.key = p.key) datetime
from ( SELECT key FROM t2 GROUP BY key ) p
#2
SELECT datetime
FROM t1
where t1.key in    ( SELECT key FROM t2 ) # GROUP BY key???
#3
SELECT t1.datetime
FROM t1
JOIN t2 ON t1.key = t2.key
GROUP BY datetime

exists вместо in
Хотя он есть в MySQL?

http://habrahabr.ru/post/31129/

ну и без индексов нужных все равно бесполезно

Быстрее тот, который быстрее.
Напиши за какое время выполняется запросы и мы тебе скажем какой из них быстрее.

(0) гонишь.
результаты запроса разные

2 и 3-ий - разную группировку имеют, к примеру.

join должен быть быстрее подзапросов. Хотя проще написать функцию замера времени и проверить

на каком-нибудь С

(3) все нужные индексы есть
(4) 0 секунд
(5) (6) порядок только разный, если добавить сортировку в конце, будет совсем одинаково.

(7) >> join должен быть быстрее подзапросов
это достоверная информация?

(9) :)))
ну-ну..
удачи в сравнении теплого с мягким.

(11) спасибо

Сортировка после выполнения запроса не повлияет на результат соревнования по скорости, поэтому я ее сократил для простоты.

первый запрос тоже, <> 2 и 3

Могу тебе на пальцах нарисовать, если так не понимаешь

(15) Нарисуй себе на пальцах если не понимаешь что они ==

а в (2) автор что-нибудь прочитал?

t1
datetime  key
01.01.01   Вася
02.01.01   Вася
03.01.01   Вася
01.01.01   Федя
02.01.01   Федя
03.01.01   Федя

t2
datetime  key
22.01.01   Вася
11.01.01   Федя

1 запрос
выдаст ошибку, ибо для ключа Вася есть 3 записи, а коррелированный подзапрос
select (select datetime from t1 where t1.key = p.key)
должен выдавать одну (top 1 там нужен или макс или еще как)

2 запрос
выдаст ошибку , ибо при group by key есть куча datetime не в агригирующей функции

3 запрос
01.01.01
02.01.01
03.01.01

(16) удачи

(16) Не прислушиваться к мнению Ёпрст это большой удар по своей карме.

(17) Да, с помощью той хорошей штуки можно узнать где не хватает индексов.

(18) в твоем примере key не уникальный. Исправь и проверь еще раз. Удачи.

(20) спасибо

(22) Я не рассматриваю частные случаи
+ В (0) об уникальности key ни слова.

+ если key уникальный, делать group by key в подзапросе ?!!!
Это ужо п...ц

Так што .. см (19)

(24) название говорит само за себя. Извините что забыл написать что оно уникально.
group by можно убрать для упрощения.

(0) Тот который будет вызван второй раз :)
SQL так весело выполняет повторный запрос, что по сути сложно оценить ту или иную скорость :)

Оценить надо именно по сути, а не методом тыка.

Есть эскуэльщики?

(29) посути - надо курить (2). если там для всех запросов одинаково, то и время выполнения будет одинаково

(31) Буду курить...

А есть кто уже опытный и сразу может сказать?

Перед выполнением текст запроса проходит через оптимизатор, который составляет план запроса. Поэтому для всех 3-х запросов может быть составлен один план и как следствие одинаковое время.

Хм. Правило 2 (флейм в тематике) еще не отменяли. И к топикстартеру это тоже относится.

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

SELECT t1.datetime
FROM t1 ,( SELECT distinct key FROM t2 ) t2
where t1.key = t2.key

(39) Как-бы уже сказали, что key уникален и нужды в distinct нет. А запрос равнозначен join, просто старая форма записи.

(40) :)))))) ыыыы нет старых форм и новых... .
как бы скуль он стандартизирован.
з.ы.
и разницы нет когда десят записей.а когда будет 10млн то разница будет

(41) http://msdn.microsoft.com/ru-ru/library/dd172122.aspx

(42) ыыыыыыы.
еще раз для упертых. есть стандарты . а есть sql server от МС это разные вещи.

(0) Если key уникальный то в 1
#1
SELECT key FROM t2 GROUP BY key не нужен
просто


select datetime from t1 where key in (select key from t2)

(0) тогда и 3 ещё лучше сделать так
SELECT distinct t1.datetime
FROM t1
INNER JOIN t2 ON t1.key = t2.key

да и как верно было подмеченно, запросы разные в плане результата.

с JOIN получается немного быстрее, но только если есть индекс по t1.datetime. Не понятно почему. Если нет индекса по t1.datetime, то индексы в t1 вообще не используются, даже по key. Не понятно