Подводный камень в Default-настройках СУБД | OTUS
⚡ Открываем подписку на курсы!
Проходите параллельно 3 онлайн-курса в месяц по цене одного.
Подробнее

Курсы

Программирование
iOS Разработчик. Продвинутый курс Программист 1С Реверс-инжиниринг. Продвинутый курс
-16%
Java Developer. Professional
-17%
JavaScript Developer. Professional
-18%
Flutter Mobile Developer
-15%
MS SQL Server Developer
-14%
Unity Game Developer. Basic
-19%
Супер - практикум по использованию и настройке GIT
-18%
Супер-интенсив "СУБД в высоконагруженных системах"
-18%
Web-разработчик на Python
-11%
Backend-разработчик на PHP
-8%
PostgreSQL
-10%
Базы данных
-19%
Android-разработчик. Базовый курс Разработчик Python. Продвинутый курс Разработчик на Spring Framework AWS для разработчиков Cloud Solution Architecture CI/CD Vue.js разработчик Разработчик Node.js Scala-разработчик Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Подводный камень в Default-настройках СУБД

PythonDeep_22.05_Site.png

Все мы рано или поздно сталкиваемся с необходимостью сохранить какую-то информацию, да так, чтобы намертво, чтобы внуки потом ещё прочитать смогли. А если ещё нужно делать хитрые выборки по сохранённому, то обычно мы приходим к использованию реляционных СУБД. Чаще всего, если посмотреть рейтинги популярности, это MySQL.

Что может быть проще?

Качаем последний MySQL и запускаем. И вот уже где-то в коде устанавливается соединение с БД, выполняется простой запрос:

import MySQLdb …. cursor.execute("UPDATE User SET likes=likes+1 WHERE Id=%s", (user_id,))

Кажется, всё хорошо. Даже если тут же сделать SELECT, то можно убедиться, что у пользователя увеличилось число «лайков». Но есть нюанс: если тот же SELECT сделать из консольного клиента, то пользователь как будто и не обновлялся. А если посмотреть SHOW PROCESSLIST, то видно, что запрос в состоянии «Waiting for table metadata lock».

А вся штука в настройках по умолчанию, о которых часто забывают. В частности, в MySQL последних версий по умолчанию движок таблицы InnoDB транзакционный. А в питонячьем MySQLdb с версии 1.2.0 опция autocommit выставлена в False.

Что же получается?

Получается, что все ваши запросы в таком случае выполняются в рамках одной транзакции и не видны другим транзакциям до явного вызова commit (или rollback). Плюс, лочатся метаданные используемой таблицы, что отображается в processlist’е.

Что делать?

Можно вызывать conn.commit() в конце транзакции, а можно сразу после установления соединения выставить conn.autocommit(True), тогда каждый запрос будет завершаться коммитом прозрачно для вас. Ну и конечно, нужно внимательно читать документацию и changelog’и.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
1 комментарий
0

Кадр из фильма "Копы в глубоком запасе"

Для комментирования необходимо авторизоваться