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



 

Здравствуйте, гость ( Вход | Регистрация )

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


Участник
***

Группа: User
Сообщений: 198
Регистрация: 20.10.2009
Поблагодарили: 16 раз
Репутация:   2  


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

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


Участник
***

Группа: User
Сообщений: 122
Регистрация: 25.4.2008
Поблагодарили: 63 раза
Репутация:   19  


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


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


Участник
***

Группа: User
Сообщений: 198
Регистрация: 20.10.2009
Поблагодарили: 16 раз
Репутация:   2  


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


Новичок
*

Группа: User
Сообщений: 30
Регистрация: 29.6.2010
Поблагодарили: 11 раз
Репутация:   1  


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


Участник
***

Группа: User
Сообщений: 122
Регистрация: 25.4.2008
Поблагодарили: 63 раза
Репутация:   19  


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


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


Бывалый
****

Группа: User
Сообщений: 494
Регистрация: 27.3.2014
Поблагодарили: 102 раза
Репутация:   8  


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

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


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


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


Участник
***

Группа: User
Сообщений: 198
Регистрация: 20.10.2009
Поблагодарили: 16 раз
Репутация:   2  


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


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


Частый гость
**

Группа: User
Сообщений: 75
Регистрация: 2.8.2014
Поблагодарили: 14 раз
Репутация:   5  


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


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


Участник
***

Группа: User
Сообщений: 198
Регистрация: 20.10.2009
Поблагодарили: 16 раз
Репутация:   2  


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

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


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


Новичок
*

Группа: User
Сообщений: 33
Регистрация: 14.3.2011
Поблагодарили: 10 раз
Репутация:   3  


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

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

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

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

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


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


Свернуть

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

  Тема Ответов Автор Просмотров Последний ответ
Горячая тема (нет новых ответов) Xrumer 16.0 – лучшее обновление за несколько лет. Новые инструменты
88 AnnaYa 20895 27.11.2017, 22:07
автор: Botmaster
Горячая тема (нет новых ответов) Несколько площадок под ваши статьи и ссылки
79 slaru 16765 23.11.2017, 17:53
автор: kark
Открытая тема (нет новых ответов) Несколько вопросов о переезде на https
Как влияет на сайт и стоит ли оно того?
16 PostBrigada 3011 23.11.2017, 13:49
автор: SergeiVL
Открытая тема (нет новых ответов) Сайт на несколько городов - услуги
Сайт фирмы по городам. Как лучше сделать?
13 zlatgeorg 2412 28.10.2017, 12:00
автор: KirillTaranenko
Открытая тема (нет новых ответов) Требуется несколько рерайтеров на постоянной основе
Желательно девушек, но не принципиально
1 Ювелир 688 26.10.2017, 19:17
автор: Lokin


 



RSS Текстовая версия Сейчас: 16.12.2017, 17:30
Дизайн