Оптимизация SQL-запросов когда?

[SuperBred 0]

В DLE ужасная работа с БД !!! И об этом полно статей в инете.

Например - http://dlemax.ru/xachk/458-optimizirem-zaprosy-poiska-po-dle-sajtu.html

Вот кусок кода из engine/engine.php:

$sql_select = "SELECT id, autor, date, short_story, SUBSTRING(full_story, 1, 15) as full_story, xfields, title, category, alt_name, comm_num, allow_comm, allow_rate, fixed, rating, vote_num, news_read, votes, flag, editdate, editor, reason, view_edit, tags FROM " . PREFIX . "_post WHERE {$stop_list}approve AND allow_main" . $where_date . " ORDER BY " . $fixed . $news_sort_by . " " . $news_direction_by . " LIMIT " . $cstart . "," . $config['news_number'];


$sql_count = "SELECT COUNT(*) as count FROM " . PREFIX . "_post WHERE {$stop_list}approve AND allow_main" . $where_date;

Простите конечно, но за такое программистов вешают...

Для тех, кто ничего не понял, объясняю:

Здесь 1 запрос выполняется 2(!) раза.

Сначала выборка потом тот же запрос с подсчетом записей! - Нафига?

Когда записей в базе мало - ничего не замечаешь, но когда уже dle_posts за 5000 переваливает, то от мата на создателей DLE неудержаться

Оптимизируйте хотябы как в статье дано - нагрузка на БД круто спадает.

[celsoft 6 095]

Сначала выборка потом тот же запрос с подсчетом записей! - Нафига?

Долго объяснять, но нет смысла это делать людям некомпетентным в этих вопросах. А SQL_CALC_FOUND_ROWS для DLE давно пройденный этап, который в нем был еще в самых древних версиях, только в реальности это не уменьшает нагрузку, а серьезно ее увеличивает.

Простите конечно, но за такое программистов вешают...

http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

[zgr 72]

celsoft, а я частенько пишу так:

SELECT SQL_CACHE COUNT(*) FROM table

Читал, что цифирь загоняется в кеш и не обновляется из БД, если не было ранее записей, т.е. работает в 10-20 раз быстрее. Пробовал всякие штуки, типа: SQL_CALC_FOUND_ROWS и другие опции, но в циклах не проверял работу по нагрузке и времени. Правильно ли я делал и это как-то реально на тяжелых сайтах может снизить нагрузку? Проверить у себя не на чем в цикле, чуть что, сервер сразу глохнет.

[SuperBred 0]

http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Угу. Вот только пара ньюансов:

COUNT() быстрее, если WHERE в индекс попадает, а в ДЛЕ с этим туго.

И в статье отбросили сам кеш запросов...

SELECT SQL_CACHE COUNT(*) FROM table

Читал, что цифирь загоняется в кеш и не обновляется из БД, если не было ранее записей, т.е. работает в 10-20 раз быстрее.

Если кеш настроен верно, то он и без SQL_CACHE туда попадет.

[celsoft 6 095]

COUNT() быстрее, если WHERE в индекс попадает, а в ДЛЕ с этим туго.

нет, как раз таки не туго, а активно используются ключи. Я же говорю что для DLE это пройденный этап, в нем такие запросы были очень давно, потом от них отказались, в связи с большей нагрузкой, чем два отдельных запроса.

celsoft, а я частенько пишу так:

SELECT SQL_CACHE COUNT(*) FROM table

Это необязательно, если кеширование в MySQL включено, то запросы туда идут автоматически без указания этого, этот флаг по умолчанию включен.