Помощник
Здравствуйте, гость ( Вход | Регистрация )
|
![]() |
![]() |
Сообщение
#1
|
||
![]() |
|
||
|
|||
![]() |
![]()
Сообщение
#2
|
![]() |
думаю, union select - то, что тебе нужно
|
|
|
![]() |
Сообщение
#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 Это ведь уже нельзя ускорить? -------------------- |
|
|
![]() |
![]() ![]()
Сообщение
#4
|
![]() |
pastuhoff,
Не пробовали сделать только SELECT * FROM `z` WHERE x=1, все равно в следующих запросах Вы делаете выборку по x=1 и полученный массив данных уже разобрать циклом? Или как вариант сделать выборку по WHERE x=1 в таблицу в памяти и уже по ней пройтись SELECT COUNT(*).... Сообщение отредактировал Neolands - 11.8.2014, 11:18 |
|
|
![]() |
![]()
Сообщение
#5
|
![]() |
если искомый запрос будет выполняться достаточно часто - имеет смысл завести отдельную таблицу, в которой хранить нужные тебе 7 чисел, и при изменении таблицы z пересчитывать соответствующие значения. тогда искомые суммы можно будет взять простым селектом из таблицы с 7ю строками
|
|
|
![]() |
![]()
Сообщение
#6
|
![]() |
в один, дабы уменьшить общее время выполнения всех этих селектов (новые индексы создавать нельзя). Для COUNT(*) очень важен размер БД! Каков он у вас? Каков прогноз по размеру? Возможно, имеет смысл для большой базы найти принципиально другое решение, и извлечение результатов возлагать не на "плечи БД"... Тем более, если у вас возникают вопросы о быстродействии, значит оно не сильно устраивает... -------------------- |
|
|
![]() |
Сообщение
#7
|
![]() |
Всем спасибо!
Зачения a и b (на самом деле там еще аналогичные c,d,...) меняются очень часто (процессор почти на 100% загружен почти 100% времени именно этими изменениями). Таблица пока на ~ 50 гигабайт (600+ миллионов записей). В перспективе - увеличение числа записей в пару раз. Думаю, доп. индексы при этом делать не нужно. Сводная статистика указанными 7 запросами в первом посте нужна несколько десятков раз в день просто для контроля. Условия: тип таблицы не менять, индексы не менять, не замедлять изменение данных в таблице (как я понимаю, триггеры это дело замедлят). В принципе, пока устраивает вариант из 3-го поста. Но если его можно ускорить только изменив сам запрос на выборку - будет неплохо. -------------------- |
|
|
![]() |
![]()
Сообщение
#8
|
![]() |
Ну не знаю как там с вашими миллионами, но кажется мне что вы в любом случае массив перебирать будете и как мне кажется первый вариант из 4 поста самый лучший. Несмотря даже на то что на сервер БД нужно перекладывать все что можно вы тут явно два раза одно поле вспахивать будете, но повторюсь я с миллонами данных увы еще не работал.
|
|
|
![]() |
Сообщение
#9
|
![]() |
в любом случае массив перебирать будете Данные запросы нужны для контроля и массивы перебираться не будут. Просто фиксирование сводной статистики на некоторые моменты времени. -------------------- |
|
|
![]() |
![]()
Сообщение
#10
|
![]() |
Если не вдаваться в детали, любая субд оперирует двумя состояниями,
1)либо есть индекс (неважно какой, уникальные значения, примари, обычное бинарное дерево, любой другой индекс), 2)либо его нет, Начнём со второго пункта - как не изменяйте запрос, Вы не увидите существенного изменения в скорости без добавления индексов, каждый раз СУБД полностью считывает инфу по столбцам, в которых нужно произвести поиск, с жесткого диска, это долгая дорогостоящая операция (один поиск нужного сектора в 10-20мс чего стоит), абсолютно любое сравнение ведёт именно к считыванию данных с винта, сравнению и повторению цикла пока не будут выполнены условия (лимит), просто примите это как факт, субд больше неоткуда взять эти данные. Если Вы заметили какие-то улучшения просто изменив запрос - в большинстве случаев это обычное кеширование часто выполняемых запросов либо самой СУБД, либо операционкой. Другое дело когда у Вас SSD, там Вы можете не заметить тормозов в подобных запросах без индекса. Первый пункт - здесь всё просто, субд создаёт индекс (бинарное дерево) и по максимому хранит его в оперативной памяти, каждое сравнение происходит без чтения с жесткого диска, получаем просто мощнейшее оружие при выборках, единственный минус - дерево нужно перестраивать при добавлении новых записей или изменении по столбцу, в котором используется индекс, поэтому нужно искать золотую середину. Но Вы только представьте как СУБД насилует винт каждый раз пробегаясь по 50Гбайтной таблице в поисках совпадений, если есть перспектива увеличения кол-ва записей в 2 раза - без индекса не обойтись, по крайней мере стоит сделать срез ночью, полученый дамп залить на тестовую тачку и потестировать без индекса и с индексом, в различных комбинациях. Если Вам нужно просто решение проблемы - кешируйте результат запроса в какое-либо хранилище, как уже подсказали - в отдельную таблицу, или любое хранилище ключ=значение, такое как memcached. Надеюсь поиск по таблице Вы производите только через id в своих запросах, иначе понятно почему загрузка всё время под 100%. Сообщение отредактировал LiveDew - 11.8.2014, 22:07 |
|
|
|
Похожие темы
Тема | Ответов | Автор | Просмотров | Последний ответ | |
---|---|---|---|---|---|
![]() |
![]() |
223 | AnnaYa | 101776 | 21.1.2021, 21:46 автор: dtokinov |
![]() |
Необходимо нарисовать несколько иконок. | 1 | PavlivGroup | 299 | 26.12.2020, 16:13 автор: 0pium |
![]() |
![]() cpa-rating.ru - рейтинг партнерских программ |
2 | airman | 494 | 23.11.2020, 9:49 автор: airman |
![]() |
Несколько площадок под ваши статьи и ссылки | 109 | slaru | 34088 | 16.7.2020, 16:17 автор: slaru |
![]() |
Продам 2 домена женской тематики, продлены на несколько лет вперед letwoman.com , iwoman.sexy |
0 | Sostavitel | 984 | 20.2.2020, 20:04 автор: Sostavitel |
![]() |
Текстовая версия | Сейчас: 23.1.2021, 9:21 |