|
ускорить запрос
|
|||
---|---|---|---|
#18+
изначально такой запрос Код: sql 1. 2. 3. 4. 5. 6.
в таблице до 20к записей пытаюсь ускорить заменил HAVING на where но время выполнения не сильно уменьшилось добавил индекс Код: sql 1.
тоже не особо помогло в ускорении explain id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE item range amountdma amountdma 772 NULL 1810 Using index condition Using where Using filesort ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 22:17 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top, Сколько записей подходит под условие, если убрать LIMIT ? Почему используете HAVING, а не WHERE? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 22:36 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
без лимита 514 записей запрос выполняется на странице, полей много, хотел сделать универсальный алиас amount и подставлять разные имена колонок amount1,amount2,amount3 where не фильтрует по алиасу,поэтому взял having ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 22:44 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
я писал что заменил having на where но не сильно помогло ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 22:49 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top, Попробуйте индекс (price, amount, stickerdma). Маловероятно, но вдруг поможет. После создания индекса не забудьте сделать ANALYZE TABLE. И покажите DDL таблицы полностью. А то смущает key_len=772 в вашем плане. Непонятно откуда так много. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 23:37 |
|
ускорить запрос
|
|||
---|---|---|---|
#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. 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2020, 23:59 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
miksoft zizi_top, Попробуйте индекс (price, amountdma, stickerdma). Маловероятно, но вдруг поможет. а как включение price в индекс может помочь ускорить запрос? имхо, в запросе ТС максимум, что можно сделать это проиндексировать только по amountdma (в данном запросе включение в индекс stickerdma скорее мешает, чем помогает) а вообще, супер-неудачная реализация. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 00:53 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
почему неудачная? почему индекс не добавляет скорость? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 06:58 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
Насколько критичен запрос для системы? Статичны ли условия отбора? А то ведь можно Код: sql 1. 2. 3.
и соответственно Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 07:33 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top почему неудачная? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 07:36 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_topALTER TABLE `item` ADD INDEX(`amountdma`, `stickerdma`, `pricedma`); Сделал бы вообще по всем полям таблицы индекс, чо мелочиться. Код: sql 1. 2. 3. 4. 5. 6.
Так это от того, что полей мало. MySql хорошо начинает работать когда от 512 полей. А вот динамический размер строки - наоборот очень хорошо. Через libastral субд прекрасно угадывает offset любой колонки. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 07:48 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
having без group by limit без order by запрос переписать бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 13:58 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
ScareCrow having без group by limit без order by запрос переписать бы. почему limit без order by? а если нужна сортировка ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 15:19 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
по сабжу первого поста. 1) сделать табличку, поддерживать или на триггерах или по крону. 2) закэшировать на APP слое ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 16:37 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
ScareCrow запрос переписать бы. И структуру сделать бы вместо всё-в-одной-таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 18:31 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
crutchmaster ScareCrow запрос переписать бы. И структуру сделать бы вместо всё-в-одной-таблице. как зависит скорость выборки от количество колонок? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 20:32 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top, правильнее сказать - зависит от "длинны записи" (сумма "длин" полей в записи) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 21:14 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
и опять вопрос- как зависит? какие допустимые ограничения? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2020, 22:14 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top crutchmaster пропущено... И структуру сделать бы вместо всё-в-одной-таблице. как зависит скорость выборки от количество колонок? О, госпади! 1. Почему плохо, когда в таблице много колонок: если индекс не покрывает все колонки, какие есть в выбираемых столбцах и в условии - то данные будут выбраны непосредственно из таблицы. Почему это плохо: данные физически в памяти лежат подряд, построчно. Если в таблице 50 колонок, а нужно выбрать 2 колонки, и при этом одной из них нет в используемом индексе - то из медленной памяти будут браться все 50 колонок для выбранных из индекса строк. Но и это не всё - СУБД может читать данные только страницами, вроде по 4 Кб. И если индекс разреженный и данные лежат не подряд - в худшем случае на 1 строку нужно будет по 4Кб на каждую строку читать из медленной памяти - а это одна из самых медленных операций в СУБД. А если ещё и индекс не подцепился - то придётся всю таблицу из памяти доставать и смотреть. 2. Индекс хорошо работает с условиями равно и BETWEEN. С больше или равно индекс работает хуже. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 00:30 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
Пишу с телефона - тут ужасный интерфейс - отправилось случайно, хотя всё не дописал. Хуже больше или равно - может быть только поиск по строке - это может замедлить работу раз в 20, по сравнению со сравнением с числом. 3. Уберите Having, напишите вместо него WHERE 4. Включите в индекс все используемые в условии и в Select столбцы. Так хотя бы из медленной памяти не будет лишние колонки читать. 5. Условие по текстовому полю замените на флаг. Его тоже включите в индекс. 6. Хотелось бы посмотреть план выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 00:38 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
Кстати, у вас первичный ключ по Id и нет на физическом уровне упорядочевания по полям из условия запроса - абсолютно точно будет проседать производительность из-за считывания лишних данных в страницах по 4Кб. Пихайте все выбираемые и фильтруемые поля в индекс - если удастся все данные из него взять - раз в 10 быстрее будет работать. А если он ещё и правильно отсортирован будет - то может и в 50 раз удастся ускорить... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 00:46 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top как зависит скорость выборки от количество колонок? То, что их много это одна беда. То, что они еще и без фиксированного размера - это вообще гемор. Как вычислить отступ с начала записи, где у тебя лежит stickerdma? Там до него 7 текстовых полей произвольного размера. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 05:10 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top Код: sql 1. 2. 3. 4.
Народ, а я правильно понимаю, что для исходного запроса в составном индексе достаточно (или целесообразнее) использовать stickerdma(1)? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 06:51 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
paver я правильно понимаю, что для исходного запроса в составном индексе достаточно (или целесообразнее) использовать stickerdma(1)? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 07:26 |
|
ускорить запрос
|
|||
---|---|---|---|
#18+
zizi_top и опять вопрос- 1. как зависит? 2. какие допустимые ограничения? 2. 4096 колумнов или 64 кб в строке в общем случае, InnoDB 1017, и т.д. и т.п. достаточно посмотреть документацию, там много интересного https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html Column Count Limits MySQL has hard limit of 4096 columns per table, but the effective maximum may be less for a given table. The exact column limit depends on several factors: The maximum row size for a table constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size. See Row Size Limits. The storage requirements of individual columns constrain the number of columns that fit within a given maximum row size. Storage requirements for some data types depend on factors such as storage engine, storage format, and character set. See Section 11.7, “Data Type Storage Requirements”. Storage engines may impose additional restrictions that limit table column count. For example, InnoDB has a limit of 1017 columns per table. See Section 15.22, “InnoDB Limits”. For information about other storage engines, see Chapter 16, Alternative Storage Engines. Functional key parts (see Section 13.1.15, “CREATE INDEX Statement”) are implemented as hidden virtual generated stored columns, so each functional key part in a table index counts against the table total column limit. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 09:06 |
|
|
start [/forum/topic.php?fid=47&msg=39993191&tid=1828396]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
135ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 265ms |
0 / 0 |