Rechercher dans le manuel MySQL
13.5 Prepared Statements
MySQL 8.0 provides support for server-side prepared statements. This support takes advantage of the efficient client/server binary protocol. Using prepared statements with placeholders for parameter values has the following benefits:
Less overhead for parsing the statement each time it is executed. Typically, database applications process large volumes of almost-identical statements, with only changes to literal or variable values in clauses such as
WHERE
for queries and deletes,SET
for updates, andVALUES
for inserts.Protection against SQL injection attacks. The parameter values can contain unescaped SQL quote and delimiter characters.
Prepared Statements in Application Programs
You can use server-side prepared statements through client
programming interfaces, including the MySQL C
API client library for C programs,
MySQL Connector/J for Java
programs, and MySQL Connector/NET for
programs using .NET technologies. For example, the C API provides a
set of function calls that make up its prepared statement API. See
Section 28.6.7, “C API Prepared Statements”. Other language
interfaces can provide support for prepared statements that use the
binary protocol by linking in the C client library, one example
being the
mysqli
extension, available in PHP 5.0 and later.
Prepared Statements in SQL Scripts
An alternative SQL interface to prepared statements is available. This interface is not as efficient as using the binary protocol through a prepared statement API, but requires no programming because it is available directly at the SQL level:
You can use it when no programming interface is available to you.
You can use it from any program that can send SQL statements to the server to be executed, such as the mysql client program.
You can use it even if the client is using an old version of the client library, as long as you connect to a server running MySQL 4.1 or higher.
SQL syntax for prepared statements is intended to be used for situations such as these:
To test how prepared statements work in your application before coding it.
To use prepared statements when you do not have access to a programming API that supports them.
To interactively troubleshoot application issues with prepared statements.
To create a test case that reproduces a problem with prepared statements, so that you can file a bug report.
PREPARE, EXECUTE, and DEALLOCATE PREPARE Statements
SQL syntax for prepared statements is based on three SQL statements:
PREPARE
prepares a statement for execution (see Section 13.5.1, “PREPARE Statement”).EXECUTE
executes a prepared statement (see Section 13.5.2, “EXECUTE Statement”).DEALLOCATE PREPARE
releases a prepared statement (see Section 13.5.3, “DEALLOCATE PREPARE Statement”).
The following examples show two equivalent ways of preparing a statement that computes the hypotenuse of a triangle given the lengths of the two sides.
The first example shows how to create a prepared statement by using a string literal to supply the text of the statement:
- +------------+
- | hypotenuse |
- +------------+
- | 5 |
- +------------+
- mysql> DEALLOCATE PREPARE stmt1;
The second example is similar, but supplies the text of the statement as a user variable:
- +------------+
- | hypotenuse |
- +------------+
- | 10 |
- +------------+
- mysql> DEALLOCATE PREPARE stmt2;
Here is an additional example that demonstrates how to choose the table on which to perform a query at runtime, by storing the name of the table as a user variable:
- mysql> EXECUTE stmt3;
- +----+
- | a |
- +----+
- | 4 |
- | 8 |
- | 11 |
- | 32 |
- | 80 |
- +----+
- mysql> DEALLOCATE PREPARE stmt3;
A prepared statement is specific to the session in which it was created. If you terminate a session without deallocating a previously prepared statement, the server deallocates it automatically.
A prepared statement is also global to the session. If you create a prepared statement within a stored routine, it is not deallocated when the stored routine ends.
To guard against too many prepared statements being created
simultaneously, set the
max_prepared_stmt_count
system
variable. To prevent the use of prepared statements, set the value
to 0.
SQL Syntax Allowed in Prepared Statements
The following SQL statements can be used as prepared statements:
For compliance with the SQL standard, which states that diagnostics statements are not preparable, MySQL does not support the following as prepared statements:
SHOW WARNINGS
,SHOW COUNT(*) WARNINGS
SHOW ERRORS
,SHOW COUNT(*) ERRORS
Statements containing any reference to the
warning_count
orerror_count
system variable.
Other statements are not supported in MySQL 8.0.
Generally, statements not permitted in SQL prepared statements are also not permitted in stored programs. Exceptions are noted in Section 24.8, “Restrictions on Stored Programs”.
Metadata changes to tables or views referred to by prepared statements are detected and cause automatic repreparation of the statement when it is next executed. For more information, see Section 8.10.3, “Caching of Prepared Statements and Stored Programs”.
Placeholders can be used for the arguments of the
LIMIT
clause when using prepared statements. See
Section 13.2.10, “SELECT Statement”.
In prepared CALL
statements used with
PREPARE
and
EXECUTE
, placeholder support for
OUT
and INOUT
parameters is
available beginning with MySQL 8.0. See
Section 13.2.1, “CALL Statement”, for an example and a workaround for earlier
versions. Placeholders can be used for IN
parameters regardless of version.
SQL syntax for prepared statements cannot be used in nested fashion.
That is, a statement passed to
PREPARE
cannot itself be a
PREPARE
,
EXECUTE
, or
DEALLOCATE PREPARE
statement.
SQL syntax for prepared statements is distinct from using prepared
statement API calls. For example, you cannot use the
mysql_stmt_prepare()
C API function
to prepare a PREPARE
,
EXECUTE
, or
DEALLOCATE PREPARE
statement.
SQL syntax for prepared statements can be used within stored
procedures, but not in stored functions or triggers. However, a
cursor cannot be used for a dynamic statement that is prepared and
executed with PREPARE
and
EXECUTE
. The statement for a cursor
is checked at cursor creation time, so the statement cannot be
dynamic.
SQL syntax for prepared statements does not support multi-statements
(that is, multiple statements within a single string separated by
;
characters).
To write C programs that use the CALL
SQL statement to execute stored procedures that contain prepared
statements, the CLIENT_MULTI_RESULTS
flag must be
enabled. This is because each CALL
returns a result to indicate the call status, in addition to any
result sets that might be returned by statements executed within the
procedure.
CLIENT_MULTI_RESULTS
can be enabled when you call
mysql_real_connect()
, either
explicitly by passing the CLIENT_MULTI_RESULTS
flag itself, or implicitly by passing
CLIENT_MULTI_STATEMENTS
(which also enables
CLIENT_MULTI_RESULTS
). For additional
information, see Section 13.2.1, “CALL Statement”.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-sql-prepared-statements.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.