|
|
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Очень нужна помощь в оптимизации sql-запроса. размеры таблиц: от 1 млн до 30 млн. Выполняется очень долго. Код: 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. Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:13 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Для ответа на ваш вопрос необходимо как минимум увидеть план запроса. Так же желательно знать структуру и кол-во строк всех таблиц, кчаствующих в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:15 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Alexey1st, используйте тег src для sql-запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:18 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
И еще какие индексы стоят и поставьте корректно задачу, может можно будет обоит внешним соединением? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:22 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Таблица STORE_SALDO (31 377 889 ЗАПИСЕЙ) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Таблица ARTIKUL_CATALOG (4 138 820 ЗАПИСЕЙ) Код: 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. Таблица SPEC_INDOC(4 049 444 ЗАПИСЕЙ) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Таблица INDOC(266 032 ЗАПИСЕЙ) Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:32 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Вообще, у меня в сообщении на первом месте стоял ПЛАН ЗАПРОСА. А под структурой таблиц понимался код, который создает эту таблицу(что бы уыидить типы полей и тд). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:35 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
План запроса: QUERY PLAN FOR STATEMENT 1 (at line 1). Executed in parallel by coordinating process and 5 worker processes. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:36 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Alexey1stПлан запроса: QUERY PLAN FOR STATEMENT 1 (at line 1). Executed in parallel by coordinating process and 5 worker processes. http://www.sql.ru/faq/faq_topic.aspx?fid=393 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:37 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Ты издеваешься* Кто такой план читать будет? Давай текстовый план ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:37 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Glory В обще образовательных целях, могли бы вы пояснить, как этот человек смог получить в MS SQL Sever такой "чудесный" план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:38 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Хорошо: Код: 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. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:40 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
QUERY PLAN FOR STATEMENT 1 (at line 1). Executed in parallel by coordinating process and 5 worker processes. STEP 1 The type of query is INSERT. The update mode is direct. Executed by coordinating process. Worktable1 created for REFORMATTING. FROM TABLE SPEC_INDOC si Nested iteration. Index : UNIQUE_ART_SUBART Forward scan. Positioning at index start. Index contains all needed columns. Base table will not be read. Using I/O Size 64 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. TO TABLE Worktable1. STEP 2 The type of query is SELECT. Executed in parallel by coordinating process and 5 worker processes. FROM TABLE STORE S Nested iteration. Table Scan. Forward scan. Positioning at start of table. Using I/O Size 64 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE RETAIL_PARAMETERS RP Nested iteration. Using Clustered Index. Index : PK_RETAIL_PARAMETERS Forward scan. Positioning by key. Index contains all needed columns. Base table will not be read. Keys are: ID_SUBJECT ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. FROM TABLE SUBJECTS sj Nested iteration. Using Clustered Index. Index : PK_SUBJECTS Forward scan. Positioning by key. Keys are: ID_SUBJECT ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE REGION r Nested iteration. Table Scan. Forward scan. Positioning at start of table. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE RETAIL_SALES RS Nested iteration. Index : RS_STORE_IND Forward scan. Positioning by key. Keys are: ID_STORE ASC SALE_DATE ASC Executed in parallel with a 5-way hash scan. Using I/O Size 64 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 64 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE DISCOUNTS D Nested iteration. Using Clustered Index. Index : PK_DISCOUNTS Forward scan. Positioning by key. Keys are: ID_CHEQUE ASC ID_SUBJECT ASC Using I/O Size 64 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 64 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE CHEQUE_TYPE CT Nested iteration. Using Clustered Index. Index : PK_CHEQUE_TYPE Forward scan. Positioning by key. Index contains all needed columns. Base table will not be read. Keys are: ID_CHEQUE_TYPE ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. FROM TABLE ARTIKUL_CATALOG ac Nested iteration. Using Clustered Index. Index : PK_ARTIKUL_CATALOG Forward scan. Positioning by key. Keys are: ARTIKUL ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE GOODS g Nested iteration. Using Clustered Index. Index : PK_GOODS Forward scan. Positioning by key. Index contains all needed columns. Base table will not be read. Keys are: ID_GOODS ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. FROM TABLE SUBJECTS sjs Nested iteration. Using Clustered Index. Index : PK_SUBJECTS Forward scan. Positioning by key. Keys are: ID_SUBJECT ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE Worktable1. Nested iteration. Using Clustered Index. Forward scan. Positioning by key. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. FROM TABLE INDOC i Nested iteration. Using Clustered Index. Index : PK_INDOC Forward scan. Positioning by key. Keys are: ID_INDOC ASC Using I/O Size 8 Kbytes for index leaf pages. With LRU Buffer Replacement Strategy for index leaf pages. Using I/O Size 8 Kbytes for data pages. With LRU Buffer Replacement Strategy for data pages. Parallel network buffer merge. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:42 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Настойчивый какой )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:44 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Прошу модераторов перенести раздел в sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:44 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Дайте план в текстовом виде в какой структуре выдает SSMS (просто Copy/Paste). И используйте тег для оформления постов SRC. Пример ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:45 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
HamletДайте план в текстовом виде в какой структуре выдает SSMS (просто Copy/Paste). И используйте тег для оформления постов SRC. Пример Человек жен сказал, что ветки форума попутал. У него SyBase. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:46 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Alexey1st, Можно воспользоваться DataBase Ingine Tuning Advisor. В 2005 Sql Managment Studio его можно вызвать через меню - Tools -> DataBase Ingine Tuning Advisor. Если перед этим выфделить в Studio текст запроса он сразу окажется в Tuning Advisor. Tuning Advisor в качестве результата своей работы предлагает рекомендации по созданию статистики и индексов. Думать практически не надо :) Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2009, 10:49 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
To Alexey1st Где скрипт для таблицы STORE ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 11:06 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Прежде всего вам надо избавиться от этого в плане: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Это -- т.н. создание временного индекса. А по сути - копирование всей таблицы в рабочуу таблицу и сортировка её. Сами понимаете, с вашими объёмами ( 4 миллиона ) это, скажем так, не очень хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 17:35 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Ещё выполните на все таблицы Код: plaintext 1. и пошлите сюда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 17:37 |
|
||
|
Огромная БД. Оптимизация sql-запроса
|
|||
|---|---|---|---|
|
#18+
Много ли в таблице STORE_SALDO записей с DATE_SAL <= '#UnloadDate#' Много ли в таблице STORE_SALDO записей с DATE_SAL <= '#UnloadDate#' и с DATE_NEXT > '#UnloadDate#' ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 17:42 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=39&tid=2011087]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
102ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
101ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 489ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...