Как я могу увеличить скорость запроса, который имеет несколько условий «Где» и «Порядок»?

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

В программе я зацикливаюсь на данных из этой таблицы и создаю Select sql для запроса другой таблицы, которая содержит цену продукта на основе атрибутов, и я сохраняю ее в третьей таблице.

У меня есть 7000 записей в таблице атрибутов и 2 тысячи записей в таблице цен. Таким образом, программа зацикливается на 7000 записей, и каждый выбранный SQL запрашивает 2Lakh записей.

Выберите SQL, содержащий несколько предложений Where и порядок по цене, чтобы получить самую низкую цену.

Мой вопрос в том, как я могу уменьшить время выполнения запроса.

Пример :-

Таблица атрибутов

sno  color      Quality  Weight
1      blue     Good       3kg
2      red      Fair        1kg   
3      Yellow   Excellent   1.5Kg

Таблица цен

sno     color     Quality    Weight(in kgs)    Market Price  Our Price 
1      sky blue    Good       4                 $400           $360
2      orange red  Excellent  2                 $500           $450

Таблица цен для магазина Red I - Crimson Red, Orange Red и т. Д.

Но атрибут у меня красный, потому что красный - это основной цвет, и на рынке вы не найдете идеального красного. Поэтому я даю продукт, близкий к красному, и дешевле в этой красной группе.

select * from tbl_price 
where color IN {Array [tbl data Entry i.e. RED ]    gives-> ( "Crimson Red", "Orange Red","Carrot Red" )}
AND Quality IN {Array [tbl data Entry i.e. Good ] gives-> ("Above Average","Medium","Not Bad" )}
AND Weight >= {tbl Entry of Weight}
Order by OurPrice ASC
LIMIT 1,1;

person user1936330    schedule 13.09.2014    source источник
comment
проиндексированы ли цвет, качество, вес и наша цена?   -  person    schedule 13.09.2014


Ответы (2)


цитата: "программа зацикливается на 7000 записей, и каждый выборочный SQL запрашивает 2Lakh записей"

Это звучит так, как будто вы обрабатываете RBAR (строка за строкой) и выполняете 7000 запросов.

Обычно гораздо эффективнее (в SQL) обрабатывать строки как набор и запускать один запрос, который возвращает желаемый набор результатов.

Существуют накладные расходы, связанные с выдачей оператора SQL (клиент отправляет текст SQL, сервер анализирует текст, выполняет проверку синтаксиса, выполняет проверку семантики, выбирает план выполнения, а затем выполняет план, готовит набор результатов, возвращает результаты клиенту. )

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

(Вполне возможно, что я неверно истолковал то, что вы сказали.)

Любопытно, что в вашем примере запроса показано предложение LIMIT 1,1. Это «пропускает» первую строку в наборе результатов. Это кажется немного странным, учитывая, как вы сказали, что хотите получить «самую низкую» цену, а не вторую самую низкую цену.

В MySQL вы можете использовать EXPLAIN для просмотра плана выполнения; это может дать представление о проблемах с производительностью. Иногда добавление соответствующего индекса может значительно повысить производительность. Но в этом случае, если запрос, который вы пытаетесь улучшить, ищет таблицу, содержащую две строки, очень маловероятно, что какой-либо индекс повлияет на производительность.

В итоге, чтобы повысить производительность, если вы выполняете 7000 запросов, переработайте схему так, чтобы вы обрабатывали все 7000 строк как набор. Вполне вероятно, что один запрос, возвращающий результаты, будет более эффективным.

person spencer7593    schedule 13.09.2014

Трудно дать точное решение, пока мы не узнаем точный сценарий и то, чего вы пытаетесь достичь.

Общий ответ будет...

Попробуйте преобразовать это в запрос, основанный на наборе.. Если вывод, который вам нужен, не может быть выполнен в одном запросе на набор, подумайте о цикле, но все же с набором. Шансов будет очень мало..

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

Или вам, возможно, придется отступить и подумать о модели данных...

Наконец, если ничего нельзя сделать на уровне БД... получить данные на промежуточном уровне, обработать и поместить вывод в таблицу по мере необходимости. Я уверен, что этот вариант будет намного лучше, чем делать что-то на уровне БД.. У меня было мало таких опытов.

person dattatraynale    schedule 13.09.2014