Преимущества использования подготовленных утверждений по сравнению с обычными утверждениями mysqli?

Question

Я провел свое исследование и решил использовать подготовленные операторы в своих запросах, все, что я спрашиваю, есть ли что-то, что я должен знать, хорошее или плохое, о переходе к обычным запросам mysqli на подготовленные операторы.

ТакжеЯ не понимаю логику, почему нет необходимости избегать плохих персонажей?

Answer 1

Экранирование плохих символов все еще необходимо, но библиотека делает это автоматически для всех параметров, которые вы связываете.Это немного более удобно и не позволяет программисту забыть очистить значение.

Однако учтите, что этот автомат ограничен параметрами!

Следующий запрос безопасен, поскольку bind_param()заботится о экранировании:

$code = $_GET["code"];
$name= $_GET["name"];
$percentage= $_GET["percentage"];

$stmt = $mysqli->prepare("INSERT INTO items VALUES (?, ?, ?)");
$stmt->bind_param('iss', code, $name, $percentage);
$stmt->execute();

следующий запрос небезопасен , потому что все, что вы поместите непосредственно в запрос, не будет автоматически экранировано :

$tablename = $_GET["prefix"]."_items";  
$code = $_GET["code"];
$name= $_GET["name"];
$percentage= $_GET["percentage"];

                                    ---- UNSAFE! ----
$stmt = $mysqli->prepare("INSERT INTO `$tablename` VALUES (?, ?, ?)");
$stmt->bind_param('iss', $code, $name, $percentage);
$stmt->execute();

сказал, что не следует использовать имена динамических таблиц, как показано в этом примере в любом случае.Но точка зрения такова: Будьте осторожны, даже с параметризованными запросами!

Единственный недостаток, о котором я могу подумать, это то, что вы больше не видите окончательный запрос для отладки (потому что он получаетсобран только на стороне сервера).

Answer 2

Есть как минимум два преимущества:

• Вам не нужно иметь дело с экранированием значений : это делается автоматически (конечно, при использовании связанных параметров)
• Оператор отправляется на сервер SQL, подготовлен только один раз ;и, затем, может быть выполнено несколько раз - что прекрасно для исполнения (оператор анализируется только один раз, даже если выполняется много раз)

Answer 3

Большинство людей путают подготовленные заявления с заполнителями.

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

Заполнители великолепны, потому что:

• онибезопаснее, потому что они делают все правильное форматирование (не глупое «экранирование»!)
• их проще использовать, потому что они выполняют все правильное форматирование автоматически.
• они удобны, поскольку делают всеправильное форматирование только для значения, которое идет прямо в запрос, но не для исходной переменной.

Что касается проблем производительности, о которых все говорят, большинство подготовленных по времени операторов медленнее, чем обычный запрос.Однако в обоих случаях разница будет незаметной.

Answer 4

1. Если вы используете подготовленные операторы с заполнителями (? без имени или :name с именем), значения, которые вы вставляете, автоматически заключаются в кавычки.
2. Подготовленные операторы предварительно компилируются механизмом dbms. Таким образом, запрос анализируется только один раз, и при последующих вызовах он просто заменяет заполнители значениями.