X   Сообщение сайта
(Сообщение закроется через 3 секунды)



 

Здравствуйте, гость (

| Вход | Регистрация )

2 страниц V   1 2 >
Открыть тему
Тема закрыта
> MariaDB: несколько SELECT COUNT(*)
pastuhoff
pastuhoff
Topic Starter сообщение 11.8.2014, 4:48; Ответить: pastuhoff
Сообщение #1


Коллеги, подскажите, можно ли на такой таблице

CREATE TABLE `z` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`x` smallint(5) unsigned NOT NULL DEFAULT '0',
`a` int(11) unsigned NOT NULL DEFAULT '0',
`b` int(11) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `x` (`x`)
) ENGINE=Aria DEFAULT CHARSET=cp1251 PAGE_CHECKSUM=1 TRANSACTIONAL=0

объединить запросы

SELECT COUNT(*) AS n1 FROM `z` WHERE x=1
SELECT COUNT(*) AS n2 FROM `z` WHERE a=0 AND x=1
SELECT COUNT(*) AS n3 FROM `z` WHERE a=1 AND x=1
SELECT COUNT(*) AS n4 FROM `z` WHERE a>1 AND x=1
SELECT COUNT(*) AS n5 FROM `z` WHERE b=0 AND x=1
SELECT COUNT(*) AS n6 FROM `z` WHERE b=1 AND x=1
SELECT COUNT(*) AS n7 FROM `z` WHERE b>1 AND x=1

в один, дабы уменьшить общее время выполнения всех этих селектов (новые индексы создавать нельзя).


--------------------
1
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Karlasan
Karlasan
сообщение 11.8.2014, 7:00; Ответить: Karlasan
Сообщение #2


думаю, union select - то, что тебе нужно


Поблагодарили: (1)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
pastuhoff
pastuhoff
Topic Starter сообщение 11.8.2014, 9:00; Ответить: pastuhoff
Сообщение #3


Karlasan, благодарю, но похоже, это не дает выйгрыша в скорости (делается не один проход по строкам, а все семь).

Подсказали следующее решение:

SELECT
SUM(1) AS `n1`,
SUM(IF(a=0,1,0)) AS `n2`,
SUM(IF(a=1,1,0)) AS `n3`,
SUM(IF(a>1,1,0)) AS `n4`,
SUM(IF(b=0,1,0)) AS `n5`,
SUM(IF(b=1,1,0)) AS `n6`,
SUM(IF(b>1,1,0)) AS `n7`
FROM `z` WHERE x=1

Это ведь уже нельзя ускорить?


--------------------
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Neolands
Neolands
сообщение 11.8.2014, 11:16; Ответить: Neolands
Сообщение #4


pastuhoff,
Не пробовали сделать только SELECT * FROM `z` WHERE x=1, все равно в следующих запросах Вы делаете выборку по x=1 и полученный массив данных уже разобрать циклом?
Или как вариант сделать выборку по WHERE x=1 в таблицу в памяти и уже по ней пройтись SELECT COUNT(*)....

Сообщение отредактировал Neolands - 11.8.2014, 11:18


Поблагодарили: (1)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Karlasan
Karlasan
сообщение 11.8.2014, 12:29; Ответить: Karlasan
Сообщение #5


если искомый запрос будет выполняться достаточно часто - имеет смысл завести отдельную таблицу, в которой хранить нужные тебе 7 чисел, и при изменении таблицы z пересчитывать соответствующие значения. тогда искомые суммы можно будет взять простым селектом из таблицы с 7ю строками


Поблагодарили: (1)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
VulkanPartner
VulkanPartner
сообщение 11.8.2014, 15:03; Ответить: VulkanPartner
Сообщение #6


Цитата(pastuhoff @ 11.8.2014, 3:48) *
в один, дабы уменьшить общее время выполнения всех этих селектов (новые индексы создавать нельзя).

Для COUNT(*) очень важен размер БД! Каков он у вас? Каков прогноз по размеру? Возможно, имеет смысл для большой базы найти принципиально другое решение, и извлечение результатов возлагать не на "плечи БД"... Тем более, если у вас возникают вопросы о быстродействии, значит оно не сильно устраивает...


--------------------
Perestroika Affiliates - ведущая гемблинг-партнерка с выплатами до 60% от дохода казино!


Поблагодарили: (1)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
pastuhoff
pastuhoff
Topic Starter сообщение 11.8.2014, 16:19; Ответить: pastuhoff
Сообщение #7


Всем спасибо!
Зачения a и b (на самом деле там еще аналогичные c,d,...) меняются очень часто (процессор почти на 100% загружен почти 100% времени именно этими изменениями). Таблица пока на ~ 50 гигабайт (600+ миллионов записей). В перспективе - увеличение числа записей в пару раз. Думаю, доп. индексы при этом делать не нужно.
Сводная статистика указанными 7 запросами в первом посте нужна несколько десятков раз в день просто для контроля. Условия: тип таблицы не менять, индексы не менять, не замедлять изменение данных в таблице (как я понимаю, триггеры это дело замедлят). В принципе, пока устраивает вариант из 3-го поста. Но если его можно ускорить только изменив сам запрос на выборку - будет неплохо.


--------------------
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
mialpet
mialpet
сообщение 11.8.2014, 21:38; Ответить: mialpet
Сообщение #8


Ну не знаю как там с вашими миллионами, но кажется мне что вы в любом случае массив перебирать будете и как мне кажется первый вариант из 4 поста самый лучший. Несмотря даже на то что на сервер БД нужно перекладывать все что можно вы тут явно два раза одно поле вспахивать будете, но повторюсь я с миллонами данных увы еще не работал.


Поблагодарили: (1)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
pastuhoff
pastuhoff
Topic Starter сообщение 11.8.2014, 21:57; Ответить: pastuhoff
Сообщение #9


Цитата(mialpet @ 11.8.2014, 21:38) *
в любом случае массив перебирать будете

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


--------------------
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
LiveDew
LiveDew
сообщение 11.8.2014, 22:06; Ответить: LiveDew
Сообщение #10


Если не вдаваться в детали, любая субд оперирует двумя состояниями,
1)либо есть индекс (неважно какой, уникальные значения, примари, обычное бинарное дерево, любой другой индекс),
2)либо его нет,

Начнём со второго пункта - как не изменяйте запрос, Вы не увидите существенного изменения в скорости без добавления индексов, каждый раз СУБД полностью считывает инфу по столбцам, в которых нужно произвести поиск, с жесткого диска, это долгая дорогостоящая операция (один поиск нужного сектора в 10-20мс чего стоит), абсолютно любое сравнение ведёт именно к считыванию данных с винта, сравнению и повторению цикла пока не будут выполнены условия (лимит), просто примите это как факт, субд больше неоткуда взять эти данные. Если Вы заметили какие-то улучшения просто изменив запрос - в большинстве случаев это обычное кеширование часто выполняемых запросов либо самой СУБД, либо операционкой. Другое дело когда у Вас SSD, там Вы можете не заметить тормозов в подобных запросах без индекса.

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

Но Вы только представьте как СУБД насилует винт каждый раз пробегаясь по 50Гбайтной таблице в поисках совпадений, если есть перспектива увеличения кол-ва записей в 2 раза - без индекса не обойтись, по крайней мере стоит сделать срез ночью, полученый дамп залить на тестовую тачку и потестировать без индекса и с индексом, в различных комбинациях.
Если Вам нужно просто решение проблемы - кешируйте результат запроса в какое-либо хранилище, как уже подсказали - в отдельную таблицу, или любое хранилище ключ=значение, такое как memcached.
Надеюсь поиск по таблице Вы производите только через id в своих запросах, иначе понятно почему загрузка всё время под 100%.

Сообщение отредактировал LiveDew - 11.8.2014, 22:07


Поблагодарили: (2)
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
2 страниц V   1 2 >
Открыть тему
Тема закрыта
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0


Свернуть

> Похожие темы

  Тема Ответов Автор Просмотров Последний ответ
Открытая тема (нет новых ответов) Жители РФ не спешат отказываться от Gmail, хотя на размышления осталось всего несколько месяцев
20 Room 4113 11.3.2024, 16:00
автор: Lumex
Горячая тема (нет новых ответов) Сайты пролежали несколько месяцев, насколько реально восстановить трафик?
108 metvekot 21169 27.1.2024, 22:39
автор: Vmir
Горячая тема (нет новых ответов) Несколько площадок под ваши статьи и ссылки
119 slaru 54393 14.10.2022, 13:52
автор: slaru
Открытая тема (нет новых ответов) Несколько площадок под статьи (Беларусь)
5 vbiznese 1944 4.8.2022, 18:11
автор: vbiznese
Открытая тема (нет новых ответов) Куплю несколько сайтов
2 Svet2019 1476 31.10.2019, 0:05
автор: Rodiola


 



RSS Текстовая версия Сейчас: 28.3.2024, 14:12
Дизайн