Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Подскажите, пожалуйста, где рыть в следующей ситуации. Имеется база с двумя таблицами. В обе таблицы каждые 5 минут выполняется INSERT нескольких сотен/тысяч позиций. На данный момент в таблицах несколько миллионов позиций. Созданы индексы по ключевым полям. SELECT из обеих таблиц с JOIN по ключевым полям выполняется около 20 минут. При выполнении SELECT возникают блокировки, вероятнее всего из-за INSERT. Подскажите, пожалуйста, как можно добиться быстрого выполненич SELECT. Возможно вопрос детский, т.к. не сталкивался с подобным ситуациям. Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 20:48 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, Структуру таблиц и запрос покажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 20:54 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:06 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
впервые вижу, чтобы таблицу проектировал человек с подобным раздвоением личности. вроде знает, что есть varchar(max) , и его использует. а вроде как и не знает, и использует еще и text . ---- но вот человека, который еще и группирует по полю типа текст(даже отконвертировав его), к серверу не надо подпускать вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:35 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Yasha123, да, выражение группировки - просто жесткач даже не для миллионов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:40 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовда, выражение группировки - просто жесткач даже не для миллионов. на самом деле, это у него такой DISTINCT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:44 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, ИМХО тут проблема не в соединении. Даже для нескольких миллионов 20 минут было бы слишком. Выполните свой запрос без... группировки и посмотрите, сколько времени займет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:57 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, на мой взгляд, так может как-то помочь покрывающий индекс parameter_per.id include (parameter_per.NAME, parameter_per.value) но из-за интенсивной вставки обслуживание индекса может вызвать еще большие проблемы. Чтобы развязать запись и чтение можете попробовать перевести таблицу в in memory. Однако, это будет иметь свои последствия. У Вас сильно нагружена tempdb, попробуйте добавить количество файлов по рекомендациям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 21:58 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32Подскажите, пожалуйста, как можно добиться быстрого выполненич SELECTНикак. Такой запрос быстро выполняться не сможет. Избавиться от влияния конкурентных insert'ов можно: - хинтом nolock на таблицы, если допустимы грязные данные. - включением у БД RCSI, если грязные данные недопустимы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 22:05 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, ЗЫ. А вы действительно поднимаете все "несколько миллионов позиций" с CONVERT(varchar(512), description) ? Это у вас просто обрезается description или у вас не может там быть больше varchar(512) ? Просто ради интереса, а зачем вам (периодически) выбирать все описания для миллионов позиций ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 22:12 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, попытка сделать витрину для сайта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 22:15 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовPizzaPizza, попытка сделать витрину для сайта? Для витрины все миллионы не нужны сразу. Возможно этот запрос есть выгрузка в другую бд которая уже и обслуживает сайт, но судя по примененной архитектуре varchar, этот вариант сомнителен. Можно подумать, что это какой то отчет. Но опять же - зачем в отчете текстовые описания позиций. Загадка прям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2018, 22:30 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Например, это может быть самопальный кэш в приложении, который он обновляет таким образом. В порядке бреда, такскать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 01:47 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Ennor Tiegael, все варианты какие то архитектурно сомнительные. Я б посоветовал UncleFedor32 задать вопрос в разделе Проектирование БД для начала. Я б сказал даже, что это надо делать asap т.к. "каждые 5 минут выполняется INSERT нескольких сотен/тысяч позиций" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 02:18 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Yasha123, Попробую отказаться от типа text. Спасибо. Yasha123,PizzaPizza Разумеется сначала использовался distinct. Но с ним запрос выполнялся ещё дольше. Group by применился как искусственный вариант при поиске решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 05:55 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32Yasha123, Попробую отказаться от типа text. Спасибо. Yasha123,PizzaPizza Разумеется сначала использовался distinct. Но с ним запрос выполнялся ещё дольше. Group by применился как искусственный вариант при поиске решения. Distinct применяется для фильтрации уникальных значений. Задайте себе вопрос: откуда у вас дубли по многим полям в таблице и зачем вы их там храните и заставляете сервер проверять каждое! varchar! поле на уникальность и потом ещё по сочетанию полей. Ваша архитектура при миллионах записей и с такой динамикой наполнения скоро приведет к тому, что элементарные запросы по часу будут выполняться. Хранение в поле metro VARCHAR(64) значений типа "Алексеевская" означает перерасход памяти, как ЖД так и оперативной и при выборках повышает нагрузку на процессор. В вашей таблице такие поля... все. Начните с азов, почитайте про нормальные формы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 06:28 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, В таблицах есть другие поля, которых нет в селект и которые не повторяются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 15:01 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, значит у Вас данные не по канону и они требуют нормализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 15:10 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
Заменил тип text на varchar, пробовал nolock, rcsi, на всякий случай опять попробовал нормальный distinct вместо ненормального group by. Результат тот же. Ради интереса выполнил select * from board. Запрос выполнялся 6 минут. Результат 2.7 миллионов строк. Такая низкая скорость выполнения запроса без join и where ещё больше настораживает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 19:37 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, "заменил" это как, данные перелил в новую таблицу или просто alter table alter column сделал? второе вообще ничего не поменяло для имеющихся данных, как лежали в блоб-страницах, так и лежат. тормознее чтения блобов с диска может быть только их сортировка (хоть gruop by, хоть distinct) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 19:44 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32Ради интереса выполнил select * from board. Запрос выполнялся 6 минут. Результат 2.7 миллионов строк. Такая низкая скорость выполнения запроса без join и where ещё больше настораживает. Какой у вас размер таблицы в гигабайтах? Если грубо прикинуть у вас минимум 4,3 кб памяти на строку * 2700000 это, если я проснулся уже, = 11 Гб. Вы хотите, что бы база перечитала вам 11 гигов данных и выдала их меньше, чем за 6 минут? Почитайте уже про нормализацию данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 20:18 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Изначально не нормализовали структуру, т.к. данные абсолютно неоднородны и неклассифицированы. Характер вводимых данных хаотичен, названия полей очень слабо отражают суть данных, которые в них содержатся. Попробую нормализовать, но ожидаю негативный результат. Как сделаю напишу. Спасибо большое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 21:31 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32PizzaPizza, Изначально не нормализовали структуру, т.к. данные абсолютно неоднородны и неклассифицированы. Характер вводимых данных хаотичен, названия полей очень слабо отражают суть данных, которые в них содержатся. Попробую нормализовать, но ожидаю негативный результат. Как сделаю напишу. Спасибо большое. Аксиома "данные абсолютно неоднородны и неклассифицированы" означает, что РБД (в частности ms sql) не подходит для ваших задач вообще. Реляционная модель данных - это всё только про однородность и классификацию, читай нормализацию. Использовать SQL как строковую помойку для миллионов записей - просто глупо, т.к. оно не заточено для работу с такими данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2018, 21:55 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, Выгрузите для начала результат этого ужасного селекта в отдельную таблицу, с которой вы можете начать профилирование данных. Серверу полегчает без экспериментальных запросов. Непонятно, кстати, кто у вас данные в эту кучу валит. Чья-то чужая аппликуха или ее тоже можно пофиксить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 01:10 |
|
||
|
Долгое выполнение SELECT при частых INSERT
|
|||
|---|---|---|---|
|
#18+
UncleFedor32, для хранения несистематизированных данных используются нереляционные БД, например, текстовые. Там все намного быстрее работает на больших объемах. Обычно в таких базах хранят журналы подключений, web запросов пользователей и другие подобные данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2018, 12:37 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39743562&tid=1688645]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 388ms |

| 0 / 0 |
