- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Считаю количество уникальных элементов в столбце, таблица - несколько сот тысяч строк.
Попробовал 2 варианта:
1) SELECT * FROM.., потом вынимаем поштучно, добавляем то что нужно посчитать в строку, сравниваем через strstr, если в строке нет - увеличваем счётчик.
2) SELECT DISTINCT `столбец` FROM.., и получаем значение через mysql_num_rows
Вроде бы второй вариант красивее, но первый обходится почти в три раза быстрее, результат одинаковый.
Возможно чтото делаю не так. Чтото с логикой не так. Подскажите почему плз.
Можно сделать так
SELECT
COUNT(*) as `C`
FROM
(
SELECT
COUNT(*)
FROM
`message`
GROUP BY
`from`
) as `Cnt`
message - ваша таблица, from - уникальные элементы.
nocomments, это вы для чего подсчет используете? У вас какой скрипт: блог, форум, авторизация на сайте? В таких случаях лучше всего счетчик использовать в виде обычного текстовго файла, в котором будет записано кол-во данных в таблице, чтобы каждый раз при обращении к скприту их не пришлось подсчитывать заново.
ИМХО
Это рейтинги посещаемости, подсчёт уникальных ip, от текстовых файлов для этого уже ушёл, в данном случае база предоставляет высокий уровень экономии.
Xoce, спасибо, результат получается тот верный, но это ещё дольше, ваш вариант 0.2240 сек., DISTINCT/num_rows 0.0007 сек. Вопрос в том, почему php эту операцию обрабатывает в три раза быстрее чем DISTINCT.
я не в курсе как там скуэл работает внутри конкретно вашей бд. Но могу послветовать добавить индекс на целевое поле, ну и мой запрос можно избавить от лишнего count()
SELECT
COUNT(*) as `C`
FROM
(
SELECT
`from`
FROM
`message`
GROUP BY
`from`
) as `Cnt`
Это рейтинги посещаемости, подсчёт уникальных ip, от текстовых файлов для этого уже ушёл, в данном случае база предоставляет высокий уровень экономии.
ну это дело вкуса конечно. Но, для самой задачи, я-бы использовал иное решение:
1. IP стоит хранить в естественном виде (это всего 4 байта) - поиск идет значительно быстрее.
2. Для расчета удобней иметь просто лог-файл/бд, куда данные записываются просто последовательно.
3. Каждые Х минут/часов лог обрабатывается и заносится в основную базу в обработанном виде. Результат счетчика, соответственно, корректируется.
В любом случае - уходите от текстового поиска и разделите (во времени) сложную задачу на несколько мелки и быстрых.
IP стоит хранить в естественном виде (это всего 4 байта)
вот это даже не подумал. нужно покопать в этом направлении. спасибо!
По поводу текстовых лог-файлов, тут не очень подходит, нужно не просто количество, нужно количество уников по определённым страницам, поэтому параллельно идёт выборка, и этот запрос выполняется несколько тысяч раз.
nocomments добавил 30.11.2010 в 20:19
Каждые Х минут/часов лог обрабатывается и заносится в основную базу в обработанном виде
Вот это как раз такая обработка, просто исходные данные сразу в базе удобнее
nocomments, то есть, вам нужна, так сказать, точная точность до уника?
Вообще-то, T.R.O.N, правильный подход описал - пересчитывать накопившиеся данные.
Dreammaker, об этом пересчёте и идёт речь. При количестве урлов около 20 000 и количестве записей 150 000 обработка через выбоку SELECT DISTINCT идёт 10 минут. Простым перебором всех 150 тысяч - 3-4 минуты.
Dreammaker, об этом пересчёте и идёт речь. При количестве урлов около 20 000 и количестве записей 150 000 обработка через выбоку SELECT DISTINCT идёт 10 минут. Простым перебором всех 150 тысяч - 3-4 минуты.
Ну значит оставляйте первый вариант :)
nocomments, где-то значит, что-то не так с индексами. Скиньте мне в личку структуру таблицы и что нужно посчитать - я прикину, что можно улучшить.