У меня есть таблица audit, которая имеет id в качестве первичного ключа, user_id в качестве foreign key и одномерные индексы для tableId, tableName и parentTableId.Итак:
id: primary keyuser_id: foreign key до table, где хранятся пользователи, показывая, кто выполнил действие для записи вaudit table представляет tableId: bigint проиндексирован column, а не foreign key, потому что audit table хранит audit всех таблиц и tableId представляет данную запись в table, где произошло событие tableName: varchar(255) проиндексировано column, отмечая, где измененная запись принадлежит parentTableId:bigint проиндексировано column, а не foreign key.Родитель table определяется логикой приложения, основанной на tableName
Также существует множество других column s, и таблица содержит приблизительно 20 миллионов записей.Теперь tableName имеет около 20 возможных значений, а в случае 'concert' значение parentTableId было равно -1, однако таблица концерта parent равна 'tour' (я знаю, что могу улучшить производительность, еслисоздание table для table имен и использование foreign key для этого в audit table, но это требует большого рефакторинга, который не обязательно будет утвержден).Хотя старые записи audit имели правильный tableId, но неправильный parentTableId, я смог update проверок where tableName = 'concert' and parentTableId = -1 до правильных parentTableId, используя соотношение между concert иtour table.Пока все хорошо.
Однако клиент сообщил о замедлении при создании concert записей.Поскольку практически все мои другие изменения были связаны с отображением страницы audit, которая не выполняется во время создания записи концерта, можно предположить, что ни одно из моих других изменений не вызвало замедления.Чтобы быть точным, некоторые незначительные изменения были сделаны с точки зрения хранения audit, который фактически выполняется при создании записи concert, это небольшие текстовые и расчетные настройки, которые невозможно вызвать замедление при concertзапись сохраняется.Итак, либо замедление произошло случайно, либо мой большой update на проверках вызвал замедление впоследствии из-за увеличения дисперсии в индексированных значениях.
Я не даю код update, потому что этопросто изменив parentTableId в правильную форму, и он был выполнен только один раз, он не работал, когда клиент начал выполнять тестирование, поэтому это не имеет значения с нашей точки зрения.
Так что мне интересно,index может быть причиной замедления.Мы знаем, что разные значения tableId могут быть связаны с одним и тем же parentTableId, но инвертировать невозможно.
Мой вопрос: вызывает ли индексация медлительность в случае записи в моем случае иесли так, то изменение индексов улучшит производительность записи?
Я думаю об изменении порядка индексов, поэтому сразу после проверки ограничения user_id для обработки parentTableId, затем tableId и наконец tableName.Должно ли это в теории улучшить производительность?