- 27.7.1 MySQL C API Implementations
- 27.7.2 Simultaneous MySQL Server and Connector/C Installations
- 27.7.3 Example C API Client Programs
- 27.7.4 Building and Running C API Client Programs
- 27.7.5 C API Data Structures
- 27.7.6 C API Function Overview
- 27.7.7 C API Function Descriptions
- 27.7.8 C API Prepared Statements
- 27.7.9 C API Prepared Statement Data Structures
- 27.7.10 C API Prepared Statement Function Overview
- 27.7.11 C API Prepared Statement Function Descriptions
- 27.7.12 C API Threaded Function Descriptions
- 27.7.13 C API Client Plugin Functions
- 27.7.14 C API Binary Log Interface
- 27.7.15 C API Binary Log Data Structures
- 27.7.16 C API Binary Log Function Overview
- 27.7.17 C API Binary Log Function Descriptions
- 27.7.18 C API Encrypted Connection Support
- 27.7.19 C API Multiple Statement Execution Support
- 27.7.20 C API Prepared Statement Handling of Date and Time Values
- 27.7.21 C API Prepared CALL Statement Support
- 27.7.22 C API Prepared Statement Problems
- 27.7.23 C API Optional Result Set Metadata
- 27.7.24 C API Automatic Reconnection Control
- 27.7.25 C API Common Issues
The C API provides low-level access to the MySQL client/server
protocol and enables C programs to access database contents. The C
API code is distributed with MySQL and implemented in the
libmysqlclient library. See
Section 27.7.1, “MySQL C API Implementations”.
Most other client APIs use the
library to communicate with the MySQL server. (Exceptions are
Connector/J and Connector/NET.) This means that, for example, you can take
advantage of many of the same environment variables that are used by
other client programs because they are referenced from the library.
For a list of these variables, see
Section 4.1, “Overview of MySQL Programs”.
For instructions on building client programs using the C API, see Section 188.8.131.52, “Building C API Client Programs”. For programming with threads, see Section 184.108.40.206, “Writing C API Threaded Client Programs”.
If, after an upgrade, you experience problems with compiled client
programs, such as
Commands out of sync or
unexpected core dumps, the programs were probably compiled using
old header or library files. In this case, check the date of the
mysql.h file and
libmysqlclient.a library used for compilation
to verify that they are from the new MySQL distribution. If not,
recompile the programs with the new headers and libraries.
Recompilation might also be necessary for programs compiled
against the shared client library if the library major version
number has changed (for example, from
libmysqlclient.so.18). For additional
compatibility information, see
Section 220.127.116.11, “Running C API Client Programs”.
Clients have a maximum communication buffer size. The size of the buffer that is allocated initially (16KB) is automatically increased up to the maximum size (16MB by default). Because buffer sizes are increased only as demand warrants, simply increasing the maximum limit does not in itself cause more resources to be used. This size check is mostly a precaution against erroneous statements and communication packets.
The communication buffer must be large enough to contain a single
SQL statement (for client-to-server traffic) and one row of returned
data (for server-to-client traffic). Each session's communication
buffer is dynamically enlarged to handle any query or row up to the
maximum limit. For example, if you have
BLOB values that contain up to 16MB
of data, you must have a communication buffer limit of at least 16MB
(in both server and client). The default maximum built into the
client library is 1GB, but the default maximum in the server is 1MB.
You can increase this by changing the value of the
max_allowed_packet parameter at
server startup. See Section 5.1.1, “Configuring the Server”.
The MySQL server shrinks each communication buffer to
net_buffer_length bytes after each
query. For clients, the size of the buffer associated with a
connection is not decreased until the connection is closed, at which
time client memory is reclaimed.