Vitsliputsli, мое послание было не в том что нельзя мерять отклик буферного кеша. А в том что новички неверно понимают себе смысл результата измерения. Они запускают свой джоб. Прогревают кеш до предела. А после этого выходят с уверенной позицией о том что все оптимизировано и проблем нет. Так обычно и происходит после серии бенчмарков.
Ничего непонятно. Какой insert or update? Есть синтаксис типа "upsert" и он поддерживается в sqlite https://www.sqlite.org/lang_insert.html https://www.sqlite.org/syntax/upsert-clause.html
ПК менять нежелательно т.к. это влияет на ссылочную целостность. ПК - это не просто поле - это точка связи между разными таблицами. Вобщем это архитектурный вопрос. Если вы решили менять - то вы себе что-то отрезали навсегда.
Тут даёшь, даёшь рекомендации, а автор сидит, ручки певесил. Он так и не сделает explain. Сидит надеется на чудо. Думает что профессионалы будут играть в угадайку. "А вот попробуй это. А это.."
На сервере через докер работают несколько прог, но за несколько дней непрерывной работы docker сжирает огромное количество места на диске (100гб)
Можно отключить все проги кроме одной и подаблюдать. Потом включить вторую и понаблюдать.
Вот так за несколько итераций можно узнать кто вредитель. Ну и дальше по ситуации.
prewordeSSS, чтобы заниматься оптимизацией нужно знать цифры. А именно - сколько всего строк в таблице. Сколько в среднем будет выбирать типичный запрос который ты оптимизируешь. Допустим это 3% от общего объема таблицы - тогда индекс будет эффективен скорее всего. Это эвристика вобщем. Так. Чисто для начала разговора.
В общем случае... если тебе не чем заняться - то я-бы предложил построить композитный индекс по полям user_id type_id и посмотреть как это влияет на время отклика. В более сложном варианте - нужно знать какой тип БД (MySQL, Postgres e.t.c.) и смотреть план выполнения.
Тестовые запуски нужно делать по холодному. Тоесть по тем данным которые еще не запрашивались. Это гарантирует честность результата. В противном случае ты будешь мерять отклик буферного кеша вместо диска. И такой результат будет красив - но в будущем не будет отражать действительность.
Оптимизация обычно - это компромисс. Тоесть ты в одном месте в БД что-то ускоряешь. В другом что-то замедляется. Ускорять везде - не получится. И еще оптимизация делается согласовано в владельцем БД. Тоесть он должен быть в курсе чем ты занимаешся.
И для оптимизации нужно запросить у владельца БД все права на оптимизацию. Сбор статистики по таблицам. Возможность дропать и создавать новые таблицы. Иначе оптимизация теряет смысл.
Алексей, у тебя ошибка синтаксиса вложенного запроса. Я тебе предложил решение. Ты можешь обернуть один запрос другим и выбрать нужные поля. Сделай это.
Я услышал вопрос - как использовать жёлтое в квадратном? Или как сделать хлопок одной ладонью?
Такие вопросы - это настоящее НЛП оружие черт его дери! После прочтения можно зависнуть.
Слушай автор ты давай ссылку на какие-то статьи или учебные материалы. Просто так немотивироанные хотелки выглядят как челледжи из Тик-Тока.