|
|
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Как выбрать число подходящих под условие WHERE записей и сами эти записи одним запросом? Сейчас я для этого использую два запроса: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2007, 11:59 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Или, например, так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2007, 12:19 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
> >...Или, например, так:... Уважаемый softwarer ! Если не затруднит, не могли бы Вы дать оценку эффективности и скорости построения выборки для следующего варианта по сравнению с одним SELECT: Вызывается хранимая процедура и первый Select строит представление выборки из двух столбцов - номер строки и суррогатный ключ, второй SELECT восстанавливает полную выборку (все поля). С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2007, 13:21 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
ВМоисеевЕсли не затруднит, не могли бы Вы дать оценку эффективности и скорости построения выборки для следующего варианта по сравнению с одним SELECT Существенно зависит от деталей запроса и реализации. Можно построить пример, в котором оверхед будет практически незаметен, и можно построить пример, в котором будет разница раза в три. "В среднем" я бы ожидал результат ближе ко второму случаю - в основном потому, что в запросе как правило участвует несколько таблиц, и при таком подходе их придется join-ить дважды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2007, 16:06 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
А варианты для MySQL есть? Еще раз поясню задачу: мне нужно знать общее число подходящих под условие записей, и содержимое самих записей в некотором интервале (скажем, записи с десятой по двадцатую - я постранично вывожу результаты запроса). Вариант GROUP BY ... WITH ROLLUP в силу ряда причин не подходит (проблемы с ORDER BY и LIMIT). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2007, 20:36 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
>softwarer >Существенно зависит от деталей запроса и реализации. У меня в строке базовой таблице много полей содержат значения внешних ключей справочников. SELECT содержат условие 'Like' и сортировку по полю(ам). Думал, что основную работу выполняет первый SELECT. Задача в общем таже, что и у КосТ. Заливаю во временную таблицу номер записи выборки и ключ. Обидно, что такой разброс по производительности. С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 13:37 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
KocT пишет: > Как выбрать число подходящих под условие WHERE записей и сами эти записи > одним запросом? Сейчас я для этого использую два запроса: > А не надо это писать. Выбери сами подходящие под условие WHERE записи и на клиенте посчитаешь их количество. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 14:57 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
ВМоисеевДумал, что основную работу выполняет первый SELECT. Это зависит от ситуации. В такой схеме я бы выделил три задачи: первый селект, работу с временной таблицей, второй селект. Как распределятся усилия между ними - большой вопрос. Скажем, если в результат запроса должно попасть 20% записей базовой таблицы, сервер скорее всего использует full scan и скорее всего не закеширует таблицу целиком после первого селекта. А значит, второй селект будет повторно читать с диска те же данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 14:01 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
>softwarer >... не закеширует таблицу целиком после первого селекта. ... Правильно ли я понимаю - первый SELECT (SELECT ... INTO TABLE) в хранимой процедуре может и не построить временную таблицу ? С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 19:13 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Временную таблицу он построит (и, отметим, не обязательно в оперативке). Но затем Вы захотите, опираясь на ось временной таблицы, запросить из базовой "остальные поля" - и вот тут вполне может пойти новое чтение с диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 19:20 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Уважаемый softwarer! Просветите меня вот в каком вопросе - временная таблица по полной выборке построена (первый SELECT). Из временной таблицы "вырезаю" страницу. Далее строю полную таблицу значений страницы и передаю сиё клиенту. Возможно, что вся базовая таблица будет просканирована, или строки будут "надергиваться" исходя из страницы временной таблицы? С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 20:25 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
ВМоисеевВозможно, что вся базовая таблица будет просканирована, или строки будут "надергиваться" исходя из страницы временной таблицы? Возможно, но маловероятно. Оверхед в этом случае пооптимистичнее, хотя вовсе не факт, что будет незаметен; впрочем, говорить о нем глупо просто потому, что схема некорректна с точки зрения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2007, 21:51 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Вобщем я нашел как это сделать под мускулем: mysql> SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE ... LIMIT ...; mysql> SELECT FOUND_ROWS(); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 06:57 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
>softwarer >Возможно, но маловероятно. Уважаемый softwarer! Я небольшой специалист по базам (серверам) данных. Меня интересует минимизация трафика глобальной сети. Сжимаю конечно. Но лишнего передавать не хочется. Передаю клиенту станицу - тестирую 240 строк. У меня датчики (типа температура, давление, расход) имеют 3 идентификатора - индекс датчика (проект, без бутылки не разберешься), название короткое (<=24 символов), для специалистов (по проекту, здесь корпуса, цеха и т.п. идентифицируются короткими последовательностями символов -2,3) и длинный <=150 символов - это для людей. Если хочу посмотреть номенклатуру датчиков по расходу пара в цехе X, то хочу передать выборку из базовой таблицы датчиков с полями внешних ключей по цеху и датчику и выборку из таблицы справочника (справочников, есть та и другая версия) по разрешению внешних ключей. В MS SQL две выборки строю одним обращением к внешней процедуре. Передаю сиё клиенту в локальный DataSet и только здесь заменяю внешние ключи на соответствующие значения из локальной таблицы выборки из справочника. Извините за корявый стиль - время поджимает. С уважением, Владимир. p.s. Занимаюсь шлифовкой прототипа. Теперь запрос обрабатывается не 2 сек, а менее 1 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2007, 22:58 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Я, признаться, не очень понял, что Вы от меня хотите. Относительно частая практика - кеширование справочников. То есть, если по траффику не хочется гнать одни и те же строки, справочник передается один раз, а дальше подставляется на клиенте. Понятно, при этом надо думать о корректном обновлении кэша в случае изменения справочника. Если Вы хотите каждый раз передавать выборку и справочник, экономя лишь на многократном вхождении строки в результат..... не знаю, мне так представляется, сжатие должно справиться с этим не хуже с точки зрения траффика и лучше с точки зрения универсальности-удобства-экстравагантных вариантов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2007, 10:54 |
|
||
|
Число подходящих записей и сами записи в одном запросе
|
|||
|---|---|---|---|
|
#18+
Уважаемый softwarer ! Спасибо за ответы. Я на самом деле передаю за один запрос страницу выборки и фрагмент справочника, соответствующего данной страницы. Не знаю, будет ли запрос на следующую страницу. Хочу сэкономить трафик на многократном вхождении строки в результат. С уважением, Владимир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2007, 12:51 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34692921&tid=1544366]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
91ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 432ms |

| 0 / 0 |
