Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
День добрый. Столкнулся с таким моментом. Выполняется выборка на CLI. Сам Execute занимает допустим 2 сек (250к записей), а вот SQLRowCount выполняется 20-30сек. Т.е. получается, что выборка с сортировкой занимает 2 сек , а узнать кол-во записей в этой выборке надо 20-30сек. Или есть иной, более правильный, способ узнать кол-во записей? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 20:05 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Вы используете SQLRowCount() для селектов? И что, она что-то похожее на правду при этом возвращает? Тут написано, что она должна для UPDATE, INSERT, DELETE, MERGE команд работать... Если так уж охота точное кол-во записей узнать, может, можно запрос типа Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 12:25 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
автор Вы используете SQLRowCount() для селектов? И что, она что-то похожее на правду при этом возвращает? Как это не странно - правду:) Просто дико тормозит при больших запросах. Как будто пытается все считать до конца - а потом возвращает значение. Понятно, что можно запрос напичать так - чтобы он возвращал кол-во записей. Но я как то привык, что такого рода информация, где то должна лежать в самом statement. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 19:15 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
И еще. Код: plaintext 1. 2. 3. 4. 5. 6. Первый fetch из такой выборки занимает те самые 30 сек. Остальные мгновенно:) Очень странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 05:45 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Вывод такой - информация о кол-ве записей в запросе, более ресурсоемкая, чем сам запрос. Но как так получается, для меня загадка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 06:17 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Dmitry Y.Вывод такой - информация о кол-ве записей в запросе, более ресурсоемкая, чем сам запрос. Но как так получается, для меня загадка. Это иллюзия. Если в запросе нет никаких операций, требующих его полной материализации (сортировки, агрегации и т.п.), то ДБ2 может начать возвращать записи, не дожидаясь полной обработки запроса. Иначе говоря, первая запись может быть возвращена еще до того, как последняя прочитана с диска. В вашем случае, чтобы определить результат, ДБ2 приходится сначала прочитать _все_ записи, прежде чем вернуть хоть что-нибудь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 20:35 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
В запросе присутствует и сортировка и выборка из нескольких таблиц и условие. Агрегации нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2007, 06:35 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Dmitry Y.Агрегации нет. Как это "нет"? А COUNT(1) - это что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2007, 20:06 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
mustaccio Dmitry Y.Агрегации нет. Как это "нет"? А COUNT(1) - это что? Мух с котлетами не путайте. Вопрос в том, почему запрос исполняется за 2сек, а кол-во записей в запросе 20-30сек при сортировках, сложных выборках и тп. COUNT(1) один из способов узнать кол-во записей в запросе. SQLRowCount тоже работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2007, 02:27 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Ладно, попробую объяснить еще раз. Если в запросе нет сортировки или агрегатных функций, таких как, например, COUNT(), первые записи возвращаются клиенту, как только они прочитаны с диска (или из буфера). У наблюдателя создается иллюзия мгновенного возврата результатов, тогда как запрос на самом деле продолжает работать и выбирать дополнительные данные. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. Если в запросе есть сортировка или агрегатная функция, как в вашем примере, результат не может быть возвращен клиенту до тех пор, пока _все_ подходящие записи не будут выбраны и отсортированы (сгруппированы, посчитаны и т.д.), поэтому наблюдателю кажется, будто запрос работает существенно медленнее. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 15:55 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Ситуация немного поменялась. Теперь первый fetch тормозит. Вот кучочек отладочного лога: Создали временную талицу. BEGIN SendQuery2 2007-02-26 15:24:59 ======================================= QUERY: DECLARE GLOBAL TEMPORARY TABLE session.controltape( END Elapsed :32 ms ============================================== Туда закинули 250к записей. BEGIN SendQuery2 2007-02-26 15:25:02 ======================================= QUERY: insert into session.controltape select check_num, END Elapsed :2860 ms ============================================== Посчитали там кол-во записей за 109 мс :) BEGIN SendInsertQuery 2007-02-26 15:25:02 ======================================= QUERY: SELECT count(*) FROM session.controltape END Elapsed :109 ms ============================================== Сделали выборку. BEGIN SendQuery 2007-02-26 15:25:02 ======================================= QUERY: SELECT check_num,CHAR(dates) as dates,cash_code,casher_code,sect,smena,group_s,plu,names,izm,cnt/1000.0 as cnt,prr/100.0 as prr, sk/100.0 as sk,sumr/100.0 as sumr,CHAR(rowid) as rowid FROM session.controltape ORDER BY UPPER(plu) ASC,rowid ASC END Elapsed Execute :32 ms Rowcount :0 ms ========================= Считали первые 100 строк за 11 сек!!!!! BEGIN Fetch 2007-02-26 15:25:13 ======================================= END Elapsed :11047 ms ============================================== Следующие 100 строк. BEGIN Fetch 2007-02-26 15:25:24 ======================================= END Elapsed :93 ms ============================================== Откуда на первом fetch 11сек? Вот отсюда все грабли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 23:07 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
Dmitry Y.ORDER BY UPPER(plu) ASC,rowid ASC END Elapsed Execute :32 ms Rowcount :0 ms ========================= Считали первые 100 строк за 11 сек!!!!! BEGIN Fetch 2007-02-26 15:25:13 ======================================= END Elapsed :11047 ms ============================================== Следующие 100 строк. BEGIN Fetch 2007-02-26 15:25:24 ======================================= END Elapsed :93 ms ============================================== Откуда на первом fetch 11сек? Вот отсюда все грабли. Вам, безусловно, откроется истина, когда вы научитесь пользоваться EXPLAIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 02:57 |
|
||
|
CLI и SQLRowCount
|
|||
|---|---|---|---|
|
#18+
mustaccio Dmitry Y. Откуда на первом fetch 11сек? Вот отсюда все грабли. Вам, безусловно, откроется истина, когда вы научитесь пользоваться EXPLAIN. Ну как расскажите, как я сделаю explain на fetch? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 13:19 |
|
||
|
|

start [/forum/topic.php?fid=43&fpage=117&tid=1604758]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 361ms |

| 0 / 0 |
