Помощник
MariaDB: несколько SELECT COUNT(*) |
pastuhoff
|
Сообщение
#1
|
||
|
|
||
|
|||
Karlasan |
11.8.2014, 7:00;
Ответить: Karlasan
Сообщение
#2
|
|
думаю, union select - то, что тебе нужно
|
|
|
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 |
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 |
|
|
Karlasan |
11.8.2014, 12:29;
Ответить: Karlasan
Сообщение
#5
|
|
если искомый запрос будет выполняться достаточно часто - имеет смысл завести отдельную таблицу, в которой хранить нужные тебе 7 чисел, и при изменении таблицы z пересчитывать соответствующие значения. тогда искомые суммы можно будет взять простым селектом из таблицы с 7ю строками
|
|
|
VulkanPartner |
11.8.2014, 15:03;
Ответить: VulkanPartner
Сообщение
#6
|
|
в один, дабы уменьшить общее время выполнения всех этих селектов (новые индексы создавать нельзя). Для COUNT(*) очень важен размер БД! Каков он у вас? Каков прогноз по размеру? Возможно, имеет смысл для большой базы найти принципиально другое решение, и извлечение результатов возлагать не на "плечи БД"... Тем более, если у вас возникают вопросы о быстродействии, значит оно не сильно устраивает... -------------------- |
|
|
pastuhoff
|
Сообщение
#7
|
|
Всем спасибо!
Зачения a и b (на самом деле там еще аналогичные c,d,...) меняются очень часто (процессор почти на 100% загружен почти 100% времени именно этими изменениями). Таблица пока на ~ 50 гигабайт (600+ миллионов записей). В перспективе - увеличение числа записей в пару раз. Думаю, доп. индексы при этом делать не нужно. Сводная статистика указанными 7 запросами в первом посте нужна несколько десятков раз в день просто для контроля. Условия: тип таблицы не менять, индексы не менять, не замедлять изменение данных в таблице (как я понимаю, триггеры это дело замедлят). В принципе, пока устраивает вариант из 3-го поста. Но если его можно ускорить только изменив сам запрос на выборку - будет неплохо. -------------------- |
|
|
mialpet |
11.8.2014, 21:38;
Ответить: mialpet
Сообщение
#8
|
|
Ну не знаю как там с вашими миллионами, но кажется мне что вы в любом случае массив перебирать будете и как мне кажется первый вариант из 4 поста самый лучший. Несмотря даже на то что на сервер БД нужно перекладывать все что можно вы тут явно два раза одно поле вспахивать будете, но повторюсь я с миллонами данных увы еще не работал.
|
|
|
pastuhoff
|
Сообщение
#9
|
|
в любом случае массив перебирать будете Данные запросы нужны для контроля и массивы перебираться не будут. Просто фиксирование сводной статистики на некоторые моменты времени. -------------------- |
|
|
LiveDew |
11.8.2014, 22:06;
Ответить: LiveDew
Сообщение
#10
|
|
Если не вдаваться в детали, любая субд оперирует двумя состояниями,
1)либо есть индекс (неважно какой, уникальные значения, примари, обычное бинарное дерево, любой другой индекс), 2)либо его нет, Начнём со второго пункта - как не изменяйте запрос, Вы не увидите существенного изменения в скорости без добавления индексов, каждый раз СУБД полностью считывает инфу по столбцам, в которых нужно произвести поиск, с жесткого диска, это долгая дорогостоящая операция (один поиск нужного сектора в 10-20мс чего стоит), абсолютно любое сравнение ведёт именно к считыванию данных с винта, сравнению и повторению цикла пока не будут выполнены условия (лимит), просто примите это как факт, субд больше неоткуда взять эти данные. Если Вы заметили какие-то улучшения просто изменив запрос - в большинстве случаев это обычное кеширование часто выполняемых запросов либо самой СУБД, либо операционкой. Другое дело когда у Вас SSD, там Вы можете не заметить тормозов в подобных запросах без индекса. Первый пункт - здесь всё просто, субд создаёт индекс (бинарное дерево) и по максимому хранит его в оперативной памяти, каждое сравнение происходит без чтения с жесткого диска, получаем просто мощнейшее оружие при выборках, единственный минус - дерево нужно перестраивать при добавлении новых записей или изменении по столбцу, в котором используется индекс, поэтому нужно искать золотую середину. Но Вы только представьте как СУБД насилует винт каждый раз пробегаясь по 50Гбайтной таблице в поисках совпадений, если есть перспектива увеличения кол-ва записей в 2 раза - без индекса не обойтись, по крайней мере стоит сделать срез ночью, полученый дамп залить на тестовую тачку и потестировать без индекса и с индексом, в различных комбинациях. Если Вам нужно просто решение проблемы - кешируйте результат запроса в какое-либо хранилище, как уже подсказали - в отдельную таблицу, или любое хранилище ключ=значение, такое как memcached. Надеюсь поиск по таблице Вы производите только через id в своих запросах, иначе понятно почему загрузка всё время под 100%. Сообщение отредактировал LiveDew - 11.8.2014, 22:07 |
|
|
|
Похожие темы
Тема | Ответов | Автор | Просмотров | Последний ответ | |
---|---|---|---|---|---|
Жители РФ не спешат отказываться от Gmail, хотя на размышления осталось всего несколько месяцев | 20 | Room | 4178 | 11.3.2024, 16:00 автор: Lumex |
|
Сайты пролежали несколько месяцев, насколько реально восстановить трафик? | 108 | metvekot | 21394 | 27.1.2024, 22:39 автор: Vmir |
|
Несколько площадок под ваши статьи и ссылки | 119 | slaru | 54625 | 14.10.2022, 13:52 автор: slaru |
|
Несколько площадок под статьи (Беларусь) | 5 | vbiznese | 1985 | 4.8.2022, 18:11 автор: vbiznese |
|
Куплю несколько сайтов | 2 | Svet2019 | 1486 | 31.10.2019, 0:05 автор: Rodiola |
Текстовая версия | Сейчас: 23.4.2024, 10:51 |