Как оптимизировать update для таблицы с nested sets?

Question

[Alex]

Дано. MySQL, innoDB, таблица с деревом порядка 600 тыс. записей из которой много читают и время от времени туда добавляются записи в произвольные узлы дерева. Серверное железо вполне себе все это тянет.
Для ускорения чтения делается SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.
Проблема в обновлении таблицы. Сам по себе insert отрабатывает без проблем, судя по всему. А вот последующие update для left и right выполняются какое-то запредельное кол-во времени. Запросы на добавление берутся из очереди.
Что можно сделать для оптимизации добавления записей?

p.s. Наверно это важно. Библиотека, которая работает с деревом, лочит таблицу на момент update. Если этот lock убрать, то возникают дедлоки, т.е. ничего не работает.

Comments

[Daria Motorina]

Возможно стоит глянуть через explain, почему апдейты так долго отрабатывают...
Вопрос только ради интереса - а nested set действительно эффективен на чтение на таком большом дереве?

[Alex]

user_of_toster, дерево одно

[Alex]

Daria Motorina, там есть особенность. нужно знать в реальном времени сколько узлов находятся под данным узлом. и это лучше всего делается через nested sets вроде... довольно эффективен, отвечая на вопрос

Answer 1

[Anton]

Попробуйте спросить в телеграм канале https://t.me/ru_mysql
Где то слышал, что скорость update могут влиять индексы, ты если в базе много записей то перестройка индексов это очень дорогая операция.

Как решать не подскажу, но очевидно, что вам нужно просто понять по какой причине происходит замедление и как этого можно избежать, для этого нужно провести профилирование запросов чтобы видеть цифры и сделать соответствующие выводы, как по мне вопрос совсем непростой... Без профилирования и цифр тут нет смысла рассуждать.

Нет универсального решения тк каждая база уникальна по своему.

Напишите сюда решение для истории для потомков.

Comments

[Alex]

Сейчас у меня рабочая гипотеза - добавлять записи в дерево без обновления left и right. Просто parent_id задавать и все. А уже потом с какой-то периодичностью перестраивать left/right/level значения.
Потому что значительно оптимизировать update, который переписывает половину таблицы, довольно сложно.

[Anton]

Александр, Рад слышать, было бы неплохо посмотреть на конкретные примеры sql что было и как поменялось + комментарии как к этому пришли