Оптимизируем запрос к Mysql

[Вурдалак]

Твой ответ в посте #14.

 

[oopros]

Хотя если мой вариант подогнать так:

$today  = mktime(0, 0, 0, date("m")  , date("d"), date("Y"));
$tomorrow  = mktime(0, 0, 0, date("m")  , date("d")+1, date("Y"));

$sql="select COUNT(ID) from table where time>'".$today."' and time<'".$tomorrow."'";

То ничего лишнего отбираться не будет, и скорость работы будет аналогично вашему запросу с NOW, правильно?

 

[Вурдалак]

Типа того

 

[hell0w0rd]

oopros, а зачем так делать-то? Вместо одной строки - 4, которые надо выполнить в голове, чтобы понять что за запрос и что он делает. Зачем?

 

[oopros]

oopros, а зачем так делать-то? Вместо одной строки - 4, которые надо выполнить в голове, чтобы понять что за запрос и что он делает. Зачем?

потому что чтобы уместить в одну строку уйдет часа 3 времени))) Главное что результат работы будет не хуже.

 

[Kotofey]

Потому что если что-то связанное с базой можно сделать посредством sql, лучше так и сделать, даже если sql запрос будет больше чем php-код. Если тебе срочно надо, сделай так как у тебя уже есть. Но лучше делай правильно. Попробуй тип поменять на datetime

 

[keltanas]

Потому что если что-то связанное с базой можно сделать посредством sql, лучше так и сделать, даже если sql запрос будет больше чем php-код. Если тебе срочно надо, сделай так как у тебя уже есть. Но лучше делай правильно. Попробуй тип поменять на datetime

Ну-ну

 

[Kotofey]

Ну-ну

Что не так я сказал?)

 

[c0dex]

Kotofey, все так, но не всегда, бывает лучше 20 мелких запросов, чем один, но больщой =) Но это не тот случай.

 

[Kotofey]

Kotofey, все так, но не всегда, бывает лучше 20 мелких запросов, чем один, но больщой =) Но это не тот случай.

Ну согласен с одной стороны, но для 20 мелких запросов уж лучше создать отдельные функции, процедуры то-есть.

 

[c0dex]

Ну не надо только предлагать сделать 20 процедур, где оно вообще не надо)

 

[Kotofey]

Ну не надо только предлагать сделать 20 процедур, где оно вообще не надо)

может эти 20 процедур можно объеденить на 5 к примеру?

 

[c0dex]

Kotofey, можнет быть, но я подразумевал 20 простых выборок, к примеру по PK/индексу, где процедура нафик не сдалась.

 

[Kotofey]

Kotofey, можнет быть, но я подразумевал 20 простых выборок, к примеру по PK/индексу, где процедура нафик не сдалась.

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

 

[c0dex]

Kotofey, да, если бы таблица была одна, то можно и IN(), а если разные, то не прокатит) JOIN в мускуле великое зло, сам убедился, а еще больщее злое нечто - это анализатор запросов в mysql, он рандомщик каких поискать.

 

[Redjik]

c0dex, STRAIGHT_JOIN в помощь =)
хотя сам угораю, когда INNER JOIN начианает мне temporary table создавать, меняю на LEFT JOIN - все нормально

 

[c0dex]

Redjik, у меня там не в straight дело было. По-дефолту мускуль выбирал самый короткий ключ для использования в запросе, а если есть составной по паре полей, сделанный специально под условие WHERE a=1 and b=2, он может взять вообще не тот. Недавно обнаружил такое, не мог понять, почему у меня выборка по многомиллионной таблице опять стала тормозить. Раньше выполнялась там за 0.0хх, а стала опять за 10-30 секунд. Начал копаться и выяснил сей неприятный момент у 5.6 сервера =\ С грустью предчувствую скорое введение партиций на ту таблицу =(

 

[grigori]

я встречался с этим, с ростом объема данных меняется план и надо писать use index

 

[Redjik]

когда писал про straight вангировал как раз про use index, но постеснялся сказать