Удерживает ли два подключения MySQL одновременно одновременно на PHP-приложение?

Question

Мой PHP-код позволяет пользователям выполнять произвольный код SQL в режиме «только для чтения». Он также нуждается в доступе к пользователю, способному писать. Мой код выполняет команды в «пользователе, умеющем писать», а затем используя отдельное соединение, запрашивает db, используя «только для чтения». Затем он снова запрашивает пользователя «write able user» и выходит из сценария.

Он оставляет доступным для записи сообщение пользователя, когда он выполняет запросы пользователя только для чтения. Насколько мне известно, это лучший способ сделать это, но мой колледж обеспокоен тем, что это как-то плохое использование MySQL, и вы хотите закрыть соединение с возможностью записи и позднее его открыть (предположительно потому, что он удваивает количество одновременных подключений к MySQL.) Каков наилучший способ сделать это?

whats more efficient and why: one db connection per page or one db connection per function? говорит, что «Обычно соединения с базой данных дороги для создания».

Answer 1

Что более эффективно и почему: одно соединение db на страницу или одно соединение db для каждой функции? говорит: «Обычно подключения к базам данных очень дороги для создания».

Я бы бросил вызов этому заявлению. Это может быть правдой для некоторых баз данных, но это не обязательно для ВСЕХ из них. Известно, что MySQL очень легкий при создании подключений, и тем более при использовании локальных сокетов домена unix.

Что более интересно: что делать, если вы используете функцию, которая требует, чтобы соединение не менялось? Как вставка набора данных, а затем выбор LAST_INSERT_ID()? Если вы используете соединение только для чтения, это не сработает.

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

Кроме того, вы не сможете использовать операторы SELECT во время транзакций, если SELECT переходит к другому соединению.

В целом: использование нескольких соединений для того, что может сделать одно соединение, кажется плохой идеей - если вы не можете дать еще несколько причин, почему вы это делаете.

Снова повторив ваш вопрос, я случайно наткнулся на вашу конкретную причину: вы выполняете произвольные SQL-инструкции. Таким образом, имеет смысл использовать ограниченную учетную запись. Также нет смысла открывать и закрывать ожидающее соединение с записью. Единственная причина для этого - если сервер базы данных достигнет своего настроенного предела одновременных подключений.

Answer 2

Ваше текущее решение наглядно прекрасно, если вы можете четко отслеживать, какое соединение является, и даже имеет преимущество, позволяющее легко масштабировать сценарий master-slave (s). Там есть что-то сказать только для открытия связи для записи, когда вам это нужно, но в недолговечном мире веб-запросов (о чем я предполагаю, о чем мы говорим), как только вы открываете его, он просто отлично уходит он открывается, если вам это нужно, или автоматически закрывает его .5 секунд спустя, когда запрос предположительно закончился.

Если мы поговорим о постоянно работающих демонах, обязательно закройте соединение после N секунд/минут бездействия, и вы, вероятно, будете иметь более одного соединения в любом случае, что позволит вам асинхронно запускать несколько запросов.