Разное > Флейм

Оптимизация запроса

(1/4) > >>

Nicki:
Нужен совет знающего человека!
Вопрос связан с оптимизацией запросов к MySQL.

Таблица состоит, к примеру, из некоторого числа столбцов:

CREATE TABLE table
(
idPicture varchar(25) NOT NULL,
weightDesign enum(\'text\',\'grpL\',\'grpH\') NOT NULL,
sectionPicture tinyint NOT NULL,
discriptPicture varchar(255) NOT NULL,
UNIQUE idPic (sectionPicture,idPicture)
);

Предположим в таблице есть 500 записей по изображениям:
- 100 из них имеют weightDesign \'text\'
- 100 из них имеют weightDesign \'grpH\'
- 300 из них имеют weightDesign \'grpL\'
- из 300-от последних, 150 имеют sectionPicture равный $x, а остальные 150, $y

Мне нужно выбрать из всей этой кучи только некоторые из них. Допустим, 70 штук, со
следующими условиями отбора: weightDesign=grpL, sectionPicture=$X. Причем,
я знаю idPicture всех мне необходимых записей, т.е. всех 70-ти.

Как будет быстрее?
1. "SELECT * FROM table WHERE weightDesign=\'grpL\' AND sectionPicture=$X", при этом,
weightDesign из 500 оставит 300, а sectionPicture из 300 оставит 150. После чего средствами
PHP отбираются 70 из 150-и.

2. "SELECT * FROM table WHERE idPicture IN (\'pic1\',\'pic2\',\'...\',\'pic70\') AND sectionPicture=$X". Здесь sectionPicture
необходим, т.к. он в паре с idPicture образует многостолбцовый UNIQUE индекс. Думаю, вы уже и так поняли. В итоге,
я получаю необходимый список не прибегая к PHP.

Вот как будет лучше??? Первый вариант делает большую нагрузку на PHP, т.к. приходится проверять
каждую из 150-и записей на предмет "соответствия" одной из 70-и нужных. А во втором используется аж 70 эллементов в условии IN(),
честно говоря, даже не знаю какой максимальный предел кол-ва элементов у этой функции. Если кто знает, подскажите.
Да и вообще, на сколько сильно будет загружать сервер такая конструкция?

FreeSpace:
ИМХО, второй вариант значительно правильнее по следующим причинам:
1. Код php в любом случае будет работать медленнее мускуля.
2. По сокетному соединению между пхп и мускулем будет передаваться ощутимо меньше данных.
3. Ограничений на кол-во элементов в функции IN(), насколько я знаю, нет.
4. Единственный чисто психологический минус этого подхода - "слишком длинный"  mysql-запрос, но по сравнению с количеством данных, которые бы возвращал запрос в первом варианте, второй выглядит намного привлекательнее.

Меняздесьдавнонет:
обоим читать про волшебный оператор LIMIT.

FreeSpace:
RomikChef
Но ведь ни слова не было сказано про критерий отбора!
Я исходил из того, что записи выбераются случайным образом (или по какому-то иному закону) и ORDER BY + LIMIT в данном случае не работают.

Меняздесьдавнонет:
Тьфу ты! перепутал, блин, ответчика с истецом.

Ну. И чего?
Во-первых, именно потому, что он НЕ СКАЗАЛ, я и написал про лимит. Безо всяких критериев (как спрошено) лимит прекрасно работает. Надо отобрать 70 из 150 - лимит в руки. ответ дан. Ответ не устраивает - формулируйте критерии лучше.

Во-вторых, с любым законом лимит прекрасно работает.
Учи матчасть, студент.

Навигация

[0] Главная страница сообщений

[#] Следующая страница