|
|
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
запрос Код: 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. коллеги, кто сможет оптимизировать этот запрос или предложить альтернативный более быстрый вариант? сейчас данный запрос выполняется 37секунд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 13:59 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011, Показывайте план этого кошмара. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:31 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011кто сможет оптимизировать этот запросВсе LEFT JOIN, для которых Вы не сможете ДОКАЗАТЬ необходимость именно LEFT, заменить на INNER JOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:32 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
И для этих связей условия отбора попробовать перенести из WHERE в ON. Причём каждый перенос рассматривать отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:34 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
AkinaВсе LEFT JOIN, для которых Вы не сможете ДОКАЗАТЬ необходимость именно LEFT, заменить на INNER JOIN.В текущем виде запроса, если не ошибаюсь, все LEFT JOIN можно заменить на JOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14: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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:39 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
как видно п 27 Statistics 35.7 s ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:41 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011 Код: plaintext Но это все равно не то, нужен именно план. Добавьте слово EXPLAIN в начале запроса и выполните. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:41 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
этот чудо запрос формируется внедрах модуля FilterPro опенкарт :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:45 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011этот чудо запрос формируется внедрах модуля FilterPro опенкарт :)Тогда рассказывайте, какие телодвижения вообще возможны? Переписывать запрос одновременно с перепроектированием базы, как я понимаю, уже можно не предлагать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:48 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
при замене всех LEFT на INNER "MySQL вернула пустой результат (т.е. ноль строк). (Запрос занял 44.7335 сек.)" т.е. мало того что работает не правильно так еще и дольше)) это с explain ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:50 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
для запроса с простыми JOIN время 45сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 14:58 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011, Строку "LEFT JOIN oc_product_option_value pov ON (pov.product_id=p.product_id)" либо оставьте как есть, либо выкиньте вообще, т.к. эта таблица не используется больше ни для чего. В таблице oc_product_option_value нет записей и переход от LEFT JOIN к JOIN приводит к пустому результату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 15:01 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
miksoftphpcoder2011этот чудо запрос формируется внедрах модуля FilterPro опенкарт :)Тогда рассказывайте, какие телодвижения вообще возможны? Переписывать запрос одновременно с перепроектированием базы, как я понимаю, уже можно не предлагать? сложно сказать, думаю очень ограничены, дело в том что этот запрос портянка формируется другой рнр портянкой Код: php 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. 195. 196. 197. 198. 199. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 15:05 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
miksoftphpcoder2011, Строку "LEFT JOIN oc_product_option_value pov ON (pov.product_id=p.product_id)" либо оставьте как есть, либо выкиньте вообще, т.к. эта таблица не используется больше ни для чего. В таблице oc_product_option_value нет записей и переход от LEFT JOIN к JOIN приводит к пустому результату. да, я рассматривал и этот вариант (с выкидыванием ненужных таблиц, а также выкидыванием ненужных столбцов), но если посмотреть рнр портянку, то станет понятно, что она все такие иногда используется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 15:16 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011miksoftphpcoder2011, Строку "LEFT JOIN oc_product_option_value pov ON (pov.product_id=p.product_id)" либо оставьте как есть, либо выкиньте вообще, т.к. эта таблица не используется больше ни для чего. В таблице oc_product_option_value нет записей и переход от LEFT JOIN к JOIN приводит к пустому результату. да, я рассматривал и этот вариант (с выкидыванием ненужных таблиц, а также выкидыванием ненужных столбцов), но если посмотреть рнр портянку, то станет понятно, что она все такие иногда используетсяТогда оставьте LEFT JOIN для нее. MySQL сам успешно выкидывает ее из запроса. Хотя что толку использовать пустую таблицу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 15:19 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011, И попробуйте сделать OPTIMIZE TABLE для всех таблиц в запросе. Возможно, это облегчит жизнь оптимизатору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 15:28 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
а по explain'ну получается mysql каждый джойн рассматривает как отдельный запрос, и уже потом делает объединение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 19:11 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011по explain'ну получается mysql каждый джойн рассматривает как отдельный запрос, и уже потом делает объединение?Нет. Каждая таблица отдельно готовится для использования в запросе. С учётом её наполнения, статистики, типа связи и использованных условий отбора и связывания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 21:12 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
miksoftphpcoder2011, И попробуйте сделать OPTIMIZE TABLE для всех таблиц в запросе. Возможно, это облегчит жизнь оптимизатору. вы будете смеяться, но это реально помогло :) на двух серверах результат одинаково положительный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 22:06 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
phpcoder2011miksoftphpcoder2011, И попробуйте сделать OPTIMIZE TABLE для всех таблиц в запросе. Возможно, это облегчит жизнь оптимизатору. вы будете смеяться, но это реально помогло :) на двух серверах результат одинаково положительныйНасколько положительный? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2016, 22:23 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, ну вместо 37секунд меньше теперь время выполнения меньше 1 секунды ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2016, 18:59 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
я так понимаю БД никогда не оптимизировалась, а вот операции модификации совершались регулярно и видимо одна из таблиц обросла мхом) какая именно таблица тормозила весь процесс сейчас уже не выяснить, могу сказать только что я пробовал выкинуть из запроса все что только можно: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. и в таком виде он выполнялся 3+сек до оптимизации таблиц. сейчас же даже без модификации запроса время выполнения менее 0,02сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2016, 19:19 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
еще был эксперимент: создана таблица oc_product_attribute2 аналог oc_product_attribute, только в ней на 50% больше строк дело в том что поле text содержит название атрибутов и иногда атрибуты составные (через двоеточие) например ЛПО:220В, вот эти составные атрибуты разбиты на отдельные строки собственно проверялось предположение о тормозах лайков запроса вида: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. теперь выполняется за 0.1042 сек (что в разы медленнее по сравнению с оригиналом), а раньше (до оптимизации таблиц) разницы не было ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2016, 19:43 |
|
||
|
оптимизация SQL запроса
|
|||
|---|---|---|---|
|
#18+
И тем не менее я бы предложил всё же привести в соответствие логику и текст запроса. Это про замену левых связываний на внутренние. Код: 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. Зачем заставлять сервер делать лишнюю работу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2016, 19:45 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39313516&tid=1831373]: |
0ms |
get settings: |
5ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
164ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 467ms |

| 0 / 0 |
