Медленный Mysql Query / In Clause - PullRequest
0 голосов
/ 15 июля 2011

У меня есть база данных с ~ 100 000 записей - сейчас мой запрос выглядит следующим образом:

ВЫБЕРИТЕ id, zipcode, цену ИЗ списков, ГДЕ почтовый индекс IN (96815, 96815, 96835, 96828, 96830, 96826, 96836, 96844, 96816, 96847, 96814, 96822, 96823, 96843, 96805, 96806, 96810, 96848, 96808, 96809, 96842, 96839, 96802, 96812, 96804, 96803, 96840, 96807, 96813, 96801, 96850, 96811, 96898, 96837, 96827, 96824, 96846, 96821, 96817, 96859, 96838, 96819, 96820, 96858, 96849, 96825, 96795, 96863, 96818, 96853, 96861, 96734, 967, 96761, 967, 96860, 96709, 96782, 96706, 96797, 96862, 96789, 96707, 96730, 96854, 96759, 96786, 96857, 96717, 96792, 96762, 96712, 96791, 96731) И (цена МЕЖДУ 1000 И 1200) ЗАКАЗАТЬ по id

Этот запрос работал нормально, когда у меня было только 50 000 записей, но он становится очень медленным, когда я расширяю радиус почтовых индексов (что приводит к еще большему числу почтовых индексов в предложении in).

id int (8) AUTO_INCREMENT Price mediumint (7) zipcode mediumint (5)

Все три поля проиндексированы.У кого-нибудь есть идеи, как я мог бы это оптимизировать?Спасибо, ребята

Ответы [ 2 ]

0 голосов
/ 15 июля 2011

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

Попробуйте создать индекс со следующими столбцами (почтовый индекс, цена)

0 голосов
/ 15 июля 2011

Почтовые коды обычно географически распределены - вы можете ускорить процесс, упростив предложение ZIP-кода до следующего вида:

zipcode BETWEEN 96700 AND 96898

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

...