|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
написал хранимку, по функционалу она полностью меня устраивает.... все хорошо работало на небольших выборках, сейчас у меня выборки примерно по 10...20 тысяч строк, в каждой строке данная хранимка обрабатывает 5 полей (каждое из полей сравнивает с одним общим ключем полученным из вне), время выполнения сейчас примерно 20 сек (с учетом, что это не сервер а NAS у меня нет возможности бороть проблему железом), в перспективе выборка будет расти, надо расчитывать на х10, возможно будут советы по оптимизации таблицы? вот хранимка Код: 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.
вот таблица, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
-------------------------------------------------------- Хороший программист должен уметь не только пользоваться инструментами, но и уметь обходиться БЕЗ НИХ! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 11:41 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 13:29 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Значения всегда строго 9-символьные? Почему CHAR(9), не VARCHAR(9) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 13:44 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Я думаю, что намного разумнее описывать ЗАДАЧУ. CREATE TABLE есть, дайте к нему INSERT INTO с примером данных и желаемый ответ на именно этих данных, с пояснением, что собственно считается и как. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 14:29 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
miksoft Значения всегда строго 9-символьные? Почему CHAR(9), не VARCHAR(9) ? да всегда 9 символов, это своеобразный хеш miksoft Хоть это и копейки, но ABS тут не нужен. попробую ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 16:37 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina есть, дайте к нему I у меня не инсерт а селект, ну примерно вот такой, в нем наверно есть ошибки, собирал из кода PHP Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 16:46 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 у меня не инсерт а селект Я просил (читайте по буквам) INSERT INTO с примером данных . Ещё лучше - сразу ссылку на fiddle. Вот как тут или тут . И видно, с чем работаем, и запрос попробовать можно... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 19:10 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina Отчасти я понимаю чего Вы хотите, сделать копию и покрутить на ней на реальных данных, но тут проблема, что 100 записей ровным образом ничего не показывают, скорость выполнения менее 0.1 сек, да и сам запрос очень простой (ниже переформатировал его в красивый вид), я понимаю, что у меня идет фул скан с примерно с 50тыс вызовами моей ХП, проблема исключительно в этом. Тут вопрос как-бы в другом, может как-то переделать хранимку и сделать ее не на 2 параметра а сразу на 10 (на 1 строчку), или вообще вложеный селект поместить вовнутрь хранимки и там в цикле формировать? в MSSQL я бы и сам разобрался, а тут и среда другая и всякие няшки непонятные, короче мне нужна не конкретика а направление (только не в лес) мой запрос Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 20:18 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 20:39 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 100 записей ровным образом ничего не показывают Во-вторых, дамп пять тысяч записей мы уже с одним товарищем крутили. В третьих, таблицу с полумиллионом рандомов, нагенерённых в СТЕ, мы тоже крутили (с другим, правда, товарищем). ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 20:47 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
это Код: sql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 20:50 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
miksoft vde69 Код: sql 1.
нет, но желательно... дело в том, что по нему изначально формируются записанные ключи. в кратце условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 20:53 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 miksoft пропущено... А обязательно использовать именно эту последовательность? нет, но желательно... дело в том, что по нему изначально формируются записанные ключи. в кратце условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. стало покрасивее, но скорость примерно та-же 19,7 сек ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:13 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:19 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
А ещё - сам текст запроса просто-таки требует, чтобы всякая фигня типа Код: sql 1. 2. 3. 4. 5.
была рассчитана заранее (см. Generated Columns). ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:21 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina А ещё - сам текст запроса просто-таки требует, чтобы всякая фигня типа Код: sql 1. 2. 3. 4. 5.
была рассчитана заранее (см. Generated Columns). тут единственный вариант сделать предварительно рассчитанную таблицу на очень много сзначений, но это не подходит, допустим в таблице 100к значений, значит в такой таблице будет 100*100/2 лямов .... не мой вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:31 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina vde69 условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. переделать наверно можно, но только наверно надо понимать какой прирост скорости будет.... сейчас у меня есть более менее читабельный код и возможность проверить например в екселе, если прирост 5% то смысла нет... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:36 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Основной расход - это вызов процедуры (её использование превращает работу с массивами данных в набор тупых итераций) и проистекающие из этого фуллскан и похрен индексы. Так что пока Вы не начнёте мыслить массивами данных, а не итерациями, ни хрена и не получится. И больше 10% никакая оптимизация из ЭТОГО не выдавит - надо менять подход, ибо ты попал в вотчину с иной идеологией. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 21:58 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina, спасибо, в целом согласен на 100%, буду думать... пока оставлю как есть, по мере роста проекта может вернусь к проблеме. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2020, 22:19 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
Akina vde69 условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. Даже если бы вместо символьных строк были строки байт со значениями от 0 до N-1, то это сэкономило бы оба LOCATE-а в процедуре. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2020, 08:03 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 miksoft Значения всегда строго 9-символьные? Почему CHAR(9), не VARCHAR(9) ? да всегда 9 символов, это своеобразный хеш ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2020, 08:06 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 с учетом, что это не сервер а NAS у меня нет возможности бороть проблему железом), Ты рутонул NAS и поднял там MySQL, а теперь жалуешься, что эта жалкая железка медленно работает? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2020, 11:31 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 возможно будут советы по оптимизации таблицы? Здесь у тебя просто тупой цикл по длине ключа, тут даже нет работы ни с одной таблицей! Ты вообще о чём? ЧТО тут можно оптимизировать? (подсказка: ничего нельзя). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2020, 11:33 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
vde69 vde69 пропущено... нет, но желательно... дело в том, что по нему изначально формируются записанные ключи. в кратце условие у меня было такое - 1 символ до 32 значений, сейчас реально используется 16, но в будующем возможно увеличу разрядность до планируемых 32, по факту это градиент одной точки, в картинке он 255, но де факто я его пересчитываю к более приемлемым значениям. стало покрасивее, но скорость примерно та-же 19,7 сек Так эта твоя хренотень в принципе неопримизируема. Чего ты ждёшь, чуда? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2020, 11:40 |
|
помогите ускорить хранимку, или запрос
|
|||
---|---|---|---|
#18+
MasterZiv vde69 пропущено... стало покрасивее, но скорость примерно та-же 19,7 сек Так эта твоя хренотень в принципе неопримизируема. Чего ты ждёшь, чуда? Значит у меня все нормально, это хорошо... в смысле - у меня нет особых промашек в языке, а проблема в самом подходе, для меня это хорошо так как к этому я изначально был готов и другого решения я пока не вижу в прицепе. в кратце задача - это поиск похожих картинок, сейчас у меня на моем массиве (в 10тыс фото) в 90% запросов он в первых 10 значениях находит все похожие (визуально на мой взгляд) картинки, и остальные 10% находит но не все... и что самое главное у меня время поиска линейно от размера базы, то есть можно прогнозировать... в голове еще бродят идеи как изменить алгоритм и структуру базы, но им надо отлежатся, пока решения нет, если все-же придумаю как сделать, то вернусь к теме ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2020, 22:03 |
|
|
start [/forum/topic.php?fid=47&msg=39930478&tid=1828723]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
148ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 261ms |
0 / 0 |