В таблице есть поле, например testfield. В нем находятся например числа. Необходимо определить, какие числа наиболее часто встречаются в таблице, и вернуть, скажем, только 10 чисел, которые наиболее часто встречаются в таблице. Вернуть данные необходимо в порядке убывания или возрастания (сортировать по кол-ву совпадений)
Спустя 8 минут, 51 секунда (8.04.2012 - 20:34) Игорь_Vasinsky написал(а):
SELECT `testfield` FROM TABLE `your_table` GROUP BY `testfield` ORDER BY `testfield` DESC LIMIT 10
Спустя 7 минут, 21 секунда (8.04.2012 - 20:41) Placido написал(а):
SELECT
`testfield`, COUNT(`testfield`) AS `count`
FROM
`table`
GROUP BY `testfield`
ORDER BY `count` DESC
LIMIT 10;
Спустя 1 час, 27 минут, 26 секунд (8.04.2012 - 22:09) testr написал(а):
Игорь_Vasinsky, дело в том что я для примера сказал что число, на самом деле там будут строки 
Извиняюсь что не сказал этого сразу. Я так полагаю 2 эти запроса работать со строками не будут...
Извиняюсь что не сказал этого сразу. Я так полагаю 2 эти запроса работать со строками не будут... Спустя 9 минут, 7 секунд (8.04.2012 - 22:18) Игорь_Vasinsky написал(а):
второй будет - вместо COUNT - CHAR_LENGTH подставь. эх....
SELECT
`testfield`, CHAR_LENGTH(`testfield`) AS `count`
FROM
`table`
GROUP BY `testfield`
ORDER BY `count` DESC
LIMIT 10;
Спустя 30 минут, 58 секунд (8.04.2012 - 22:49) Placido написал(а):
| Цитата (testr @ 8.04.2012 - 22:09) |
| Игорь_Vasinsky, дело в том что я для примера сказал что число, на самом деле там будут строки Извиняюсь что не сказал этого сразу. Я так полагаю 2 эти запроса работать со строками не будут... |
А сами запустить оба эти запроса не пробовали?
З.Ы. Моему запросу пофиг - хоть число, хоть строка. Каких записей больше, то и выведет.
Спустя 21 день, 9 часов, 54 минуты, 19 секунд (30.04.2012 - 08:43) testr написал(а):
а есть идеи насчет более легковесного запроса? а то тут я так понимаю для каждой строки таблицы вычисляется count, причем даже для повторяющихся строк, или нет? если да, то взять хотя бы distinct чтоли...
p.s. кол-во совпадений каждой метки мне не обязательно получать
p.s. кол-во совпадений каждой метки мне не обязательно получать
Спустя 7 минут, 39 секунд (30.04.2012 - 08:51) vagrand написал(а):
distinct ничем не легче чем group by. Если вы запрос будет выполнятся часто, а строк в таблице много, то я бы сделал отдельную таблицу в которой хранились бы уже сгруппированные данные и обновлялись посредством триггеров при обновлении основной таблицы.
Спустя 1 минута, 25 секунд (30.04.2012 - 08:52) testr написал(а):
нет, не особо часто. но вот строк будет немало.
Спустя 10 минут, 7 секунд (30.04.2012 - 09:02) vagrand написал(а):
Ну как сделать правильно я тебе написал, а там уже думай сам
Спустя 8 минут, 19 секунд (30.04.2012 - 09:11) testr написал(а):
то есть ты имеешь в виду хранить каждое значение и кол-во совпадений каждого?
а как триггер поставить, можешь намекнуть? дать так сказать пищу для дальнейшего размышления.
а как триггер поставить, можешь намекнуть? дать так сказать пищу для дальнейшего размышления.
Спустя 27 минут, 19 секунд (30.04.2012 - 09:38) ИНСИ написал(а):
testr можешь так попробовать:
SELECT
`testfield`, (SELECT COUNT(`testfield`) FROM `table` WHERE `testfield` = `t`.`testfield` LIMIT 1) AS `size`
FROM
`table` AS `t`
GROUP BY `testfield`
ORDER BY `size` DESC
LIMIT 10;
Спустя 8 минут, 44 секунды (30.04.2012 - 09:47) vagrand написал(а):
| Цитата |
| то есть ты имеешь в виду хранить каждое значение и кол-во совпадений каждого? |
Да именно это я и имею ввиду.
| Цитата |
| а как триггер поставить, можешь намекнуть? |
Вот тут подробно о триггерах написано: http://dev.mysql.com/doc/refman/5.0/en/triggers.html
ИНСИ
Твой пример не лучше чем с group by а даже хуже, т.к. во-первых он не правильный (будут дубликаты записей с одними и теми же значениями поля testfield), во-вторых на каждую отобранную запись ты будешь выполнять подзапрос, т.е. вместо одного запроса у тебя их будет 11.
Спустя 6 минут, 49 секунд (30.04.2012 - 09:54) ИНСИ написал(а):
| Цитата |
| будут дубликаты записей |
Не учел, добавил.
| Цитата |
| даже хуже |
Интересно почему же? Если индексы поставить, запрос никак не будет хуже.
| Цитата |
| вместо одного запроса у тебя их будет 11. |
Это ты как подсчитал? что получилось 11?
Спустя 4 минуты, 54 секунды (30.04.2012 - 09:59) vagrand написал(а):
| Цитата |
| Не учел, добавил. |
Ну так в этом случае твой запрос стал еще хуже, т.к. теперь тут есть и GROUP BY в основном запросе и подзапросы.
| Цитата |
| Это ты как подсчитал? что получилось 11? |
1 основной запрос, в котором стоит лимит на выборку 10 записей и еще 10 подзапросов на каждую отобранную в основном запросе запись. Вот тебе и 11.
Спустя 1 минута, 39 секунд (30.04.2012 - 10:00) ИНСИ написал(а):
| Цитата |
| distinct ничем не легче чем group by. Если вы запрос будет выполнятся часто, а строк в таблице много, то я бы сделал отдельную таблицу в которой хранились бы уже сгруппированные данные и обновлялись посредством триггеров при обновлении основной таблицы. |
Какая разницы сколько строк в таблице? От этого особо много не зависит если проставить индексы, не использовать JOIN-ы.
Что ты имеешь в виду под "хранились бы уже сгруппированные данные"?
Спустя 4 минуты, 5 секунд (30.04.2012 - 10:04) ИНСИ написал(а):
| Цитата |
| твой запрос стал еще хуже |
Что именно ты имеешь в виду под словом "хуже"?
Спустя 4 минуты, 27 секунд (30.04.2012 - 10:09) vagrand написал(а):
| Цитата |
| Что именно ты имеешь в виду под словом "хуже"? |
Будет дольше выполнятся и создавать большую нагрузку.
| Цитата |
| Какая разницы сколько строк в таблице? От этого особо много не зависит если проставить индексы, не использовать JOIN-ы. |
Да ну? А размер индексов и время поиска по ним не зависит от количества строк? И потом при использовании GROUP BY индексы не юзаются. Там создается временная таблица, куда и записываются сгруппированные данные.
| Цитата |
| Что ты имеешь в виду под "хранились бы уже сгруппированные данные"? |
То и имею ввиду. ТС понял в чем мысль, почитай и ты повнимательнее.
Спустя 34 минуты, 17 секунд (30.04.2012 - 10:43) ИНСИ написал(а):
| Цитата |
| Будет дольше выполнятся и создавать большую нагрузку. |
Большую нагрузку чем что?
| Цитата |
| А размер индексов и время поиска по ним не зависит от количества строк? |
| Цитата |
| Если использование индекса требует от MySQL прохода более чем по 30% строк в данной таблице (в таких случаях просмотр таблицы, по всей видимости, окажется намного быстрее, так как потребуется выполнить меньше операций поиска). Следует учитывать, что если подобный запрос использует LIMIT по отношению только к извлекаемой части строк, то MySQL будет применять индекс в любом случае, так как небольшое количество строк можно найти намного быстрее, чтобы вернуть результат. |
| Цитата |
| И потом при использовании GROUP BY индексы не юзаются |
Это где ты такое вычитал?
| Цитата |
| ТС понял в чем мысль |
Мысль понял, а как реализовать не знает. Воду не лей ...
| Цитата |
| почитай и ты повнимательнее |
Для начала: Не переходи на такую манеру общения. Я с тобой вел диалог, а не спор. Во вторых: Чтобы "вчитываться" в твой вариант, приведи объяснение в коде, а не просто в словах.
Спустя 6 часов, 31 минута, 59 секунд (30.04.2012 - 17:15) vagrand написал(а):
| Цитата |
| Большую нагрузку чем что? |
Чем запрос по таблице где данные уже выбраны и сгруппированы.
| Цитата |
| Для начала: Не переходи на такую манеру общения. Я с тобой вел диалог, а не спор. Во вторых: Чтобы "вчитываться" в твой вариант, приведи объяснение в коде, а не просто в словах. |
Сори конечно но код я писать не буду. А алгоритм как мне представлялось довольно ясен:
1. Создаешь таблицу testfield_count в которой всего два поля: testfield и num;
2. При создании, удалении или изменении записей в основной таблице подсчитываешь количество вхождений текущего testfield и изменяешь, при помощи триггеров, его в таблице testfield_count;
3. Если нужно хранить только определенное количество, например 10 значений, которых больше всего то можно в триггерах проверять еще и количество записей в этой таблице и вытеснять последнее наименьшее.
Вот по такой таблице запрос будет моментальным, т.к. все данные уже подготовлены.
Спустя 1 час, 36 минут, 35 секунд (30.04.2012 - 18:52) ИНСИ написал(а):
Я не говорил, что делать все одним запросом - гуд. Наоборот, я противник сложных решений, дабы зачастую простота в запросах, выгоднее чем эти сложные операции. Я лишь как пример дал реализацию.
Ты же начал осуждать и приводить доводы не совсем уместные и правильные, вместо того - чтобы подискутировать. Я всегда за нормальное общение.
Я думаю что теперь, ТС поймет твой вариант решения, вполне неплохое.
Ты же начал осуждать и приводить доводы не совсем уместные и правильные, вместо того - чтобы подискутировать. Я всегда за нормальное общение.
Я думаю что теперь, ТС поймет твой вариант решения, вполне неплохое.
Спустя 29 минут, 28 секунд (30.04.2012 - 19:21) vagrand написал(а):
Дело в том что мой вариант сложнее в реализации а твой проще и предложив его ты дал ТС-у соблазн пойти неправильным путем.
Спустя 28 минут, 27 секунд (30.04.2012 - 19:50) ИНСИ написал(а):
А я наоборот Мне часто проще дать готовый код, чем объяснять (если бесплатно) 
Мне часто проще дать готовый код, чем объяснять (если бесплатно)