Комментарии 3
Девиз статьи - "если трудностей нет - надо их создать" (и героически преодолевать с потерей большого количества серого вещества).
Для бухгалтерской отчетности нужно вычислять идентификатор следующего потенциального заказа. Вы храните это значение в отдельной таблице и после каждого заказа вычисляете его с помощью формулы last_order_id + 1. По мере роста нагрузки вам приходится слишком часто блокировать как таблицу заказов, так и таблицу, хранящую следующий идентификатор, пока он вычисляется.Де
Перед записью нового заказа получаете (мгновенно) новый сиквенс. По-хорошему заказы (зачем-то автор путает бухгалтерию, в которой нет вообще проблем обработать документы по факту их создания, и управление торговлей) надо писать в одном потоке. Фактически, будет единственный пользователь (ядро системы, обрабатывающее сложенные в асинхронную очередь новые заказы, а точнее, черновики), у которого особых проблем не будет ни с сиквенсом, ни с блокировками. Попытка нескольких пользователей заказать один и тот же товар - это скорее из области бизнес-логики (а также управления складскими остатками). Кто первый успел нажать Ок, тому и досталось, хотя видели остатки все одни и те же. Лояльный разработчик еще и подкрасит заканчивающийся товар. Эффективно работающая OLTP - это INSERT и больше (в идеале) ничего, проблемы с блокировками - это действительно проблемы плохой архитектуры.
MyISAM вообще не про финансовый учет, хотя для интернет-торговли можно и его использовать (ответственности не так уж много), но особого смысла нет. InnoDB в руки и вперед.
Я правильно понимаю, что при многопоточной работе с частыми UPDATE у MyISAM будут запросы висеть в Locked даже при UPDATE одной строки в таблице и параллельном SELECT других строк?
В то время как у InnoDB без транзакций будет блокировка только при UPDATE тех же строк, или не будет вообще?
Не совсем понимаю логику gap locks в плане предотвращения фантомов. Вот зачем? На мой взгляд, такой подход только вредит производительности. Не так сильно, как SQL Server конечно, но те же PostgreSQL и Oracle подощли к этому, на мой взгляд, лучше.
Потому что есть два конкретных инструмента - MVCC или снимки данных и предикатная блокировка. Предикатная блокировка в смысле такой блокировки определенного промежутка данных, при которой попытка выполнить команду Insert в другой транзакции заблокируется.
PostgreSQL подобный подход не использует, как и Oracle.
Потому что есть два разных понятия - 1) Возникновение фантома 2) Чтение фантома
И аномалия то, согласно Стандарту ISO/IEC 9075 - как раз таки чтение фантома
Так что необходимости использовать gap lock я не вижу совершенно. Как и Next-Key Locks
Блокировки MySQL: виды, проблемы и способы обнаружения