[X] Помощник

[pastuhoff Topic Starter]

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

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

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

[Karlasan]

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

[pastuhoff Topic Starter]

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]

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

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

[Karlasan]

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

[VulkanPartner]

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

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

[pastuhoff Topic Starter]

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

[mialpet]

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

[pastuhoff Topic Starter]

в любом случае массив перебирать будете

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

[LiveDew]

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

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

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

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

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