Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Есть табличка остатки, там пишется движение по каждому штрихкоду, как он двигался с одного склада на другой или был отгружен клиенту. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. В Этой таблице 109 млн записей и два индекса: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Есть табличка справочник складов компании она просто таблица без индексов там 120 записей Код: sql 1. 2. 3. 4. 5. Есть табличка фирмы, там более укрупненное название складов. В этой таблице 10 тыщ записей Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Там есть 1 индекс Код: sql 1. 2. 3. 4. 5. Есть таблица с датами по документу, в этой таблице 2 млн записей Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Там есть 3 индекса Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Я просчитываю остаток, какие штрихкоды находились на складах компании на заданную дату. Код: sql 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. По коду поясняю, это длинная конструкция Код: sql 1. нужна для того чтобы убрать пропуски, нарушена целостность базы, некоторые движений внутри складов нету в таблице, сейчас приведу небольшой пример как обстоят таблицы Код: sql 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. Уже очень долгое время бьюсь над оптимизацией данного выше запроса План запроса прилагаю, закинул в рар, т.к. сам план весит 174 кб, превышает 150 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2018, 18:15 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
minya13_85, ничего не сделаете с запросами: или грубой силой - увеличением вычислительной мощности или считайте агрегацию заранее. Можно секционировать данные в остатках по masterID, если мало складов приходит во временную таблицу и данные об остатках более-менее распределены по ним. Будете просматривать меньший объём в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2018, 19:12 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, да вот же заранее не просчитать, это остаток на заданную дату, динамический запрос. Может еще есть варианты? как избавиться от параллелизма этого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2018, 08:49 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
minya13_85, Почему нет? Учётные системы именно так и делают. Например хранят рассчитанные остатки на начало каждого месяца. Тогда движений может быть хоть миллиард, а остатков на каждый месяц по разному: где густо, а где и пусто. Таким образом усложняются запросы, но скорость на высоте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2018, 20:24 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Я сделал так: Есть журнал движения (как в сабже) и есть журнал незакрытых партий, т.е. остаток партии без привязок "приход-расход". Незакрытые партии и есть "остаток на сейчас". А остаток на любое время это "сумма незакрытых партий" - "обороты от нужной даты до сейчас по журналу движения". Производительность плавно убывает с удаленностью даты "от сейчас", но старые даты редко нужны. Такая схема редко требует урезки. зы: если пришло 10 и ушло 10, то партия исчерпана и ее не нужно считать в остатках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2018, 22:04 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Можно задать маленький вопрос чтоб не создавать тему. В MSSQL 2012 есть в таблице некластеризованный индекс из 3х полей, одно из его полей C_Tov не имеет ограничения (NOT NULL). Фактически значений NULL в этом поле нет и не будет. Таблица довольно большая и поле C_Tov участвует во множестве выборок и джоинов. Будет ли лучше для производительности этих запросов если я поставлю на него ограничение NOT NULL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2018, 23:26 |
|
||
|
И снова здравствуйте, Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2018, 21:20 |
|
||
|
|

start [/forum/topic.php?fid=46&fpage=158&tid=1690053]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
27ms |
get topic data: |
7ms |
get forum data: |
3ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 318ms |

| 0 / 0 |
