Увеличивают ли транзакции накладные расходы на БД?

Вы правы, при автокоммите каждый оператор оборачивается в транзакцию. Если ваши методы службы выполняют несколько операторов sql, было бы хорошо превратить их в транзакцию. Взгляните на this ответ для получения дополнительных сведений и здесь хороший пост в блоге на эту тему.

И чтобы ответить на ваш вопрос, да, транзакции добавляют накладные расходы на производительность, но в вашем конкретном случае вы не заметите разницы, так как у вас уже включен автокоммит, если у вас нет длительных операторов в методах обслуживания, что приведет к более длительным блокировкам таблиц. участие в сделках. Если вы просто заключите несколько операторов внутри транзакции, вы получите одну транзакцию (вместо транзакции для каждого отдельного оператора), как указано здесь (" Сеанс, в котором включена автоматическая фиксация, может выполнить транзакцию с несколькими операторами, запустив ее с явным оператором START TRANSACTION или BEGIN и завершив ее с помощью оператора COMMIT или ROLLBACK "), и вы достигнете атомарности на уровне метода обслуживания ...

В конце я бы выбрал ваше решение, если это имеет смысл с точки зрения достижения атомарности на уровне метода обслуживания (что, я думаю, вы хотите достичь), но есть + и - эффекты на производительность, в зависимости от вашего запросы, запросы / с и т. д.

Да, они могут добавить накладные расходы. Дополнительная «бухгалтерия», необходимая для изоляции транзакций друг от друга, может стать значительной, особенно если транзакции остаются открытыми в течение длительного времени.

Короткий ответ: это зависит от типа вашего стола. Если вы используете MyISAM, по умолчанию, на самом деле транзакций нет, поэтому это не должно влиять на производительность.

Но вы все равно должны их использовать. Без транзакций нет разграничения работы. Если вы обновитесь до InnoDB или реальной базы данных, такой как PostgreSQL, вы все равно захотите добавить эти транзакции в свои методы обслуживания, так что вы можете сделать это привычкой сейчас, пока это вам ничего не стоит.

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

Как и все, что касается баз данных, единственный окончательный ответ - это тестирование с реалистичными данными и реалистичными нагрузками. Я рекомендую делать это всегда, независимо от того, что вы подозреваете, потому что, когда дело доходит до баз данных, активируются очень разные пути кода, когда данные большие, а когда нет. Но я сильно подозреваю, что стоимость использования транзакций даже с InnoDB невелика. В конце концов, эти системы интенсивно используются постоянно, каждый день большими и маленькими организациями, которые зависят от успешной работы транзакций. MVCC добавляет очень мало накладных расходов. Преимущества огромны, затраты низкие - используйте их!