Форум PHP программистов > DISTINCT или array

[ Поиск ] - [ Пользователи ] - [ Календарь ]

Полная Версия: DISTINCT или array_unique

GET

31.05.2012 - 13:58

Здравствуйте.

Есть таблица (для теста на localhost сделал 100 тыс. записей).

При нужной выборке получаю смешанный результат т.е. с дублируемыми значениями.

Нужно получить массив с уникальными значениями.

Используя SELECT DISTINCT результат на 10% быстрее, чем если использовать array_unique(удаляет дубли из массива) для простого SELECT.

Вопрос собственно, как поведен себя этот кусок под нагрузкой юзеров? Что лучше использовать? Локальные тесты показывают, что DISTINCT, но с ним сервер создает дополнительную таблицу и для скоростных таблиц его не рекомендуют? С другой стороны PHP придется сортировать массив в 5000 элементов в поисках дублей???

Спасибо.

Спустя 1 минута, 26 секунд (31.05.2012 - 12:59) Игорь_Vasinsky написал(а):

можно ещё GROUP )))

в первом случае ты получаешь "чистый" массив и доволен, во втором ты выбираешь всё и потом чистишь в PHP - ответ видно сразу - где действий меньше - то и лучше.

Спустя 30 минут, 49 секунд (31.05.2012 - 13:30) inpost написал(а):

A.B.C.
Быстрее упадёт Мускул, чем ПХП. А 10% - это считай, что одинаково.
А вообще, если уж хочешь быть профессионалом, пересмотри структуру, возможно есть смысл результат кешировать, или хранить в отдельной таблице.

И почему именно DISTINCT ? Смысл хранить в БД абсолютно одинаковые записи?

Спустя 17 минут, 56 секунд (31.05.2012 - 13:48) GET написал(а):

inpost
Спасибо.

Там не то чтоб одинаковые записи, там поиск по названию `a`:

пример запроса:

SELECT DISTINCT `a` FROM `tab` WHERE `b`='1' AND `c`='25' AND `d`='10' AND `e`='3' AND `f`='2'

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

inpost

Посоветуй пожалуйста хорошую инфу по кешированию.

Спустя 5 минут, 10 секунд (31.05.2012 - 13:53) Игорь_Vasinsky написал(а):

google => ruseller memcache = http://ruseller.com/lessons.php?rub=37&id=1035

Спустя 22 минуты, 49 секунд (31.05.2012 - 14:16) Nikitian написал(а):

Пыху обычно выделяют ресурсов меньше и распределяет их он как попало. Для работы с большим количеством данных очень хорошо подходят временные таблицы. И кстати, стандартный array_unique() не работает с многомерными массивами, так что не совсем ясно как вы им выборку прочёсываете, только если выбирается один параметр и раскидывается в одномерный массив...

Спустя 9 минут, 28 секунд (31.05.2012 - 14:25) inpost написал(а):

A.B.C.
http://phpclub.ru/faq/cahcing?v=12c2

Игорь_Vasinsky
Мемкеш?!

Печалька, мне он совсем не понравился, есть и по лучше кеширование в памяти

Спустя 7 минут, 52 секунды (31.05.2012 - 14:33) GET написал(а):

Nikitian

Цитата

SELECT DISTINCT `a` FROM `tab`

один и выбирается.

Игорь_Vasinsky
inpost

Спасибо! Читаю.

Спустя 2 минуты, 35 секунд (31.05.2012 - 14:36) Игорь_Vasinsky написал(а):

вот я предлагал решение для полного кеширования вывода

http://phpforum.ru/index.php?showtopic=60955&hl=ob_start

но, можно легко под запросы переписать и юзать.

Спустя 1 час, 15 минут, 31 секунда (31.05.2012 - 15:51) GET написал(а):

Вопрос по кэшированию..

Какие есть минусы помимо разрастания размеров и количества кешируемых файлов?
Как я понял основной параметр контроля кэща это его время, а если скажем создать небольшую таблицу в которой перечислить номера тяжелых страниц, из-за тяжелых запросов на них, если таблицы этих запросов не менялись, то пишем 0=> достаем страницу из кеша , если менялись=>1, то создаем новый кеш этой страницы, выводим и снова пишем=>0.

?

Спустя 2 минуты, 23 секунды (31.05.2012 - 15:54) Игорь_Vasinsky написал(а):

минус ещё в том - что на сайте, время от времени, будет отображаться не актуальная информация

Спустя 3 минуты, 3 секунды (31.05.2012 - 15:57) GET написал(а):

Цитата

минус ещё в том - что на сайте, время от времени, будет отображаться не актуальная информация

ну я вот и предложил зацепить кэш на id autoincriment, если инфа из таблиц выбирается.

Спустя 3 минуты, 5 секунд (31.05.2012 - 16:00) inpost написал(а):

A.B.C.
недоступность на простых серверах использования mem-кеша, только файлового.

Спустя 1 час, 42 секунды (31.05.2012 - 17:01) vital написал(а):

Цитата

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

Mysql одновремнно может использовать только 1 индекс.. ну почти так.
Когда куча AND AND AND в where надо делать один составной индекс, и, возможо, может понадобится скормить его мускулу принудительно через FORCE INDEX если у вас там куча других бесполезных на каждое поле.

Спустя 4 минуты, 40 секунд (31.05.2012 - 17:05) vital написал(а):

Цитата (inpost @ 31.05.2012 - 13:25)

A.B.C.
http://phpclub.ru/faq/cahcing?v=12c2

Игорь_Vasinsky
Мемкеш?!

Печалька, мне он совсем не понравился, есть и по лучше кеширование в памяти

Так то да. зачем мемкеш то, он плохой и не симпатичный. Инпост умнее чем livejournal и facebook.

Спустя 1 час, 41 минута, 16 секунд (31.05.2012 - 18:47) inpost написал(а):

vital
facebook & memcache... *facepalm*

Если не знаешь, то не надо говорить. Уже 3-я тема за 3 дня, где ты зафейлился своими ответами.

Спустя 2 часа, 49 минут, 38 секунд (31.05.2012 - 21:36) Семён написал(а):

vital, в какой-то степени я с inpost-ом соглашусь, т.к. не раз говорил что для простных смертных достаточно иметь tmpfs раздел (а ты о таком вообще слышал?) в который складывать свой кеш в виде обычных файлов.

Спустя 25 минут, 30 секунд (31.05.2012 - 22:02) Игорь_Vasinsky написал(а):

гугл задрал, вес кешированной страницы 50-70кб, за час гугл с яшей на 50-80 мб набегают. спасает крон + ручками (скрипт) если есть секунда.

Спустя 3 часа, 21 минута, 44 секунды (1.06.2012 - 01:23) GET написал(а):

vital

А если не

SELECT DISTINCT `a` FROM `tab` WHERE `b`='1' AND `c`='25' AND `d`='10' AND `e`='3' AND `f`='2'

SELECT DISTINCT `a` FROM `tab` WHERE `c`='25' AND `f`='2'

т.е. `b`,`d`,`e` нв выбраны? Кому будет нужен этот составной индекс?

Цитата

Mysql одновремнно может использовать только 1 индекс.. ну почти так.

Не знаю даже чему верить EXPLAIN'у или Вам.

Спустя 34 минуты, 1 секунда (1.06.2012 - 01:57) inpost написал(а):

A.B.C.
Для каждого УНИКАЛЬНОГО запроса необходим свой персональный составной индекс.

Спустя 16 минут, 47 секунд (1.06.2012 - 02:14) GET написал(а):

inpost

Если поиск может идти по 5 полям?

получается будет не меньше 10(на вскидку), вариантов - составных индексов, много места на диске будет занимать так ведь...придется этим жертвовать?

Спустя 2 минуты, 7 секунд (1.06.2012 - 02:16) inpost написал(а):

A.B.C.
Конечно. Скорость в замен на скорость и место.
Ведь каждый индекс ускоряет выборку, но замедляет абсолютно все другие операции к этой таблице.
Идеала пока нет.

Спустя 3 минуты, 23 секунды (1.06.2012 - 02:20) GET написал(а):

inpost

Спасибо!

Спустя 6 часов, 6 минут, 57 секунд (1.06.2012 - 08:27) GET написал(а):

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

 KEY `a` (`a`,`b`,`c`)
 KEY `a2` (`a`,`g`,`h`)

Это критично?

Смысл почему я понимаю, из-за дублирования первого столбца `a`, но если это удобно?

Спустя 4 часа, 59 минут, 44 секунды (1.06.2012 - 13:26) inpost написал(а):

A.B.C.
Как это ругается? Какая ошибка?

Спустя 17 минут, 53 секунды (1.06.2012 - 13:44) GET написал(а):

inpost

Блин не так выразился точнее ПМА выдает предупреждение:

! More than one INDEX key was created for column `a`

Спустя 3 минуты, 46 секунд (1.06.2012 - 13:48) Игорь_Vasinsky написал(а):

ну вроде ясно всё написано.

Спустя 5 минут, 22 секунды (1.06.2012 - 13:53) GET написал(а):

Игорь_Vasinsky

Ну мне тоже ясно, что для столца `a` создано больше одного индекса

Это просто предупреждение? Или предупреждение-призыв обязательно изменить индекс?

Спустя 31 минута (1.06.2012 - 14:24) Игорь_Vasinsky написал(а):

не вкурсе)) если бы всё было пучком - он бы не сказал наверно. может намёк на оптимизацию?

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Быстрый ответ:

Здесь расположена полная версия этой страницы.