Есть запрос:
select firms.kod, firms.title, firms.pay, rekv.director, address.addr as address, address.phones
from firms left join rekv on (firms.kod=rekv.kod) left join address on (firms.kod=address.kod)
where firms.manager=".$manager['manager']." order by firms.title
таблица firms - 19300+ записай
rekv - 6900 записей
address - 24200+ записей
Данные, полученные в результате выполнения запроса обрабатываются далее при помощи smarty.
Данный запрос выполняется порядка 3х минут (при результирующем количестве записей около 1000). Это слишком долго... Как можно оптимизировать запрос или алгоритм выборки, чтобы уменьшить время выборки хотя бы секунд до 30-40?
И да. Локально это все выполняется около 10 секунд (MySQL 5.5.22), а проблема на сервере (который стоит у нас же в офисе - MySQL 5.0.51) Может ли это зависеть от версии мускла?
Спустя 14 минут, 21 секунда (6.06.2012 - 22:23) forza написал(а):
Во-первых сделайте эксплейн запроса (explain sql query). Везде должны быть индексы и количество затронутых строк минимизировано.
Во-вторых иногда полезней сделать 2 запроса, нежели связывать джойнами.
Если понравится анализировать запросы, можете еще сделать профилирование запросов.
Во-вторых иногда полезней сделать 2 запроса, нежели связывать джойнами.
Если понравится анализировать запросы, можете еще сделать профилирование запросов.
Спустя 26 минут, 58 секунд (6.06.2012 - 22:50) vital написал(а):
Вероятно нету идексов.
Спустя 7 минут, 6 секунд (6.06.2012 - 22:57) rj45 написал(а):
| Цитата |
| Вероятно нету идексов. |
prtimary по полю kod во всех перечисленных таблицах.
Спустя 1 час, 25 минут, 52 секунды (7.06.2012 - 00:23) vital написал(а):
| Цитата (rj45 @ 6.06.2012 - 21:57) | ||
prtimary по полю kod во всех перечисленных таблицах. |
этот индекс не используется в данном запросе вероятно
Спустя 1 минута, 28 секунд (7.06.2012 - 00:24) vital написал(а):
| Цитата |
| И да. Локально это все выполняется около 10 секунд (MySQL 5.5.22), а проблема на сервере (который стоит у нас же в офисе - MySQL 5.0.51) Может ли это зависеть от версии мускла? |
Не видел эту строку ранее. Тогда беда не в самой бд=(
Спустя 7 часов, 1 минута, 2 секунды (7.06.2012 - 07:25) rj45 написал(а):
| Цитата |
| Тогда беда не в самой бд=( |
т.е. все-таки версия сервера может так влиять?
Спустя 4 часа, 6 минут, 11 секунд (7.06.2012 - 11:32) Семён написал(а):
Если локально все ок, а на сервере нет - проверяйте значение key buffer-a в MySQL
Спустя 1 час, 24 минуты, 50 секунд (7.06.2012 - 12:57) rj45 написал(а):
| Цитата |
| проверяйте значение key buffer-a в MySQL |
Вычитал об этой опции
key_buffer - Величина буфера ( байтах ), который используется для индексов. Этот буфер
общий для всех потоков. Если используется много DELETE или INSERT запросов к таблицам с
большим кол - индексов, то увеличение значения повысит скорость выполнения таких
запросов. Для достижения еще большей скорости нужно использовать LOCK TABLES.
т.е. вляет только на delete И insert запросы, или на select тоже?
Спустя 2 часа, 25 минут, 55 секунд (7.06.2012 - 15:22) Семён написал(а):
key-buffer влияет как на чтение так и на запись и не забываем про временные таблицы
Спустя 1 день, 9 часов, 50 минут, 11 секунд (9.06.2012 - 01:13) rj45 написал(а):
| Цитата |
| Если локально все ок, а на сервере нет - проверяйте значение key buffer-a в MySQL |
Поправил. Дописал 16М (по дефолту было 8М) в my.cnf, рестартонул mysqld - ни фига. все то же... Вроде как первые час-два было быстрее, но пототм снова то же самое (может, самовнушение?)
Все подозрения в сторону настроек mysqld, т.к. базы идентичны на обеих серверах.
Спустя 42 минуты, 12 секунд (9.06.2012 - 01:55) Семён написал(а):
Как понять самовнушение? У вас должны быть показатели скорости исполнения SQL запросов, а не зрительные замеры
Спустя 24 дня, 21 час, 43 минуты, 58 секунд (3.07.2012 - 23:39) rj45 написал(а):
проблема была в нарушении порочки индексов в таблицах.
Все поправил и начало летать.
Всем спасибо за отзывы
Все поправил и начало летать.
Всем спасибо за отзывы