Тут даёшь, даёшь рекомендации, а автор сидит, ручки певесил. Он так и не сделает explain. Сидит надеется на чудо. Думает что профессионалы будут играть в угадайку. "А вот попробуй это. А это.."
На сервере через докер работают несколько прог, но за несколько дней непрерывной работы docker сжирает огромное количество места на диске (100гб)
Можно отключить все проги кроме одной и подаблюдать. Потом включить вторую и понаблюдать.
Вот так за несколько итераций можно узнать кто вредитель. Ну и дальше по ситуации.
prewordeSSS, чтобы заниматься оптимизацией нужно знать цифры. А именно - сколько всего строк в таблице. Сколько в среднем будет выбирать типичный запрос который ты оптимизируешь. Допустим это 3% от общего объема таблицы - тогда индекс будет эффективен скорее всего. Это эвристика вобщем. Так. Чисто для начала разговора.
В общем случае... если тебе не чем заняться - то я-бы предложил построить композитный индекс по полям user_id type_id и посмотреть как это влияет на время отклика. В более сложном варианте - нужно знать какой тип БД (MySQL, Postgres e.t.c.) и смотреть план выполнения.
Тестовые запуски нужно делать по холодному. Тоесть по тем данным которые еще не запрашивались. Это гарантирует честность результата. В противном случае ты будешь мерять отклик буферного кеша вместо диска. И такой результат будет красив - но в будущем не будет отражать действительность.
Оптимизация обычно - это компромисс. Тоесть ты в одном месте в БД что-то ускоряешь. В другом что-то замедляется. Ускорять везде - не получится. И еще оптимизация делается согласовано в владельцем БД. Тоесть он должен быть в курсе чем ты занимаешся.
И для оптимизации нужно запросить у владельца БД все права на оптимизацию. Сбор статистики по таблицам. Возможность дропать и создавать новые таблицы. Иначе оптимизация теряет смысл.
Алексей, у тебя ошибка синтаксиса вложенного запроса. Я тебе предложил решение. Ты можешь обернуть один запрос другим и выбрать нужные поля. Сделай это.
Я услышал вопрос - как использовать жёлтое в квадратном? Или как сделать хлопок одной ладонью?
Такие вопросы - это настоящее НЛП оружие черт его дери! После прочтения можно зависнуть.
Слушай автор ты давай ссылку на какие-то статьи или учебные материалы. Просто так немотивироанные хотелки выглядят как челледжи из Тик-Тока.
В роли коррекции может выступать длина окружности. По сути нам надо разбить круг на набор бубликов (количество и ширина задается как пользовательские параметры). Далее рассматривать эти бублики как независимые графы которые имеют точки соединения на границах бубликов.
Есть такой чувак Conor Hoekstra. Он увлекается сравнением какого-то алгоритма в разных ЯП. У него куча публикаций в youtube. И вот я смотрю что с С++11 исходники C++ в его публикациях приобретают такой себе изящный ФП-style. Им конечно еще далеко до Haskell но тем не менее. Выглядят компактно. Я думаю что checkRepeat можно переписать в 3-4 строки без потери смысла.
А данный императивный алгоритм - фуфу. Эти переменные типа flag. Эти индексы. Все от недостатка выразительности. И неужели со времен Visual Studio 6.0 мы так и не получили функциональной выразительности?
Не могу проголосовать ответом потому что в тексте не звучит ответ. Звучит просто набор рекомендаций. Я думаю что лучше все таки приаттачить сорцы и тогда можно и голосовать.