Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
CALLОператоры API C обеспечивает низкоуровневый доступ к протоколу клиента/сервера MySQL и позволяет программам C получить
доступ к содержанию базы данных. Код API C распределяется с MySQL и реализуется в libmysqlclient
библиотека Видит Раздел 21.8.1, "Реализации API MySQL C".
Большинство других клиентских API использует libmysqlclient библиотека, чтобы
связаться с сервером MySQL. (Исключения кроме Connector/J и Соединителя/Сети.) Это означает, что, например,
можно использовать в своих интересах многие из тех же самых переменных окружения, которые используются другими
клиентскими программами, потому что на них ссылаются от библиотеки. Для списка этих переменных см. Раздел 4.1,
"Краткий обзор MySQL Programs".
Для получения инструкций по созданию клиентских программ, используя API C, см. Раздел 21.8.4.1, "Создавая C Клиентские Программы API". Для того, чтобы запрограммировать с потоками, см. Раздел 21.8.4.2, "Пишущий C API Поточные Клиентские Программы". Чтобы создать автономное приложение, которое включает "сервер" и "клиент" в той же самой программе (и не связывается с внешним сервером MySQL), см. Раздел 21.7, "libmysqld, Библиотека Сервера MySQL Embedded".
Если после обновления Вы испытываете проблемы со скомпилированными клиентскими программами, такой
как Commands out of sync или неожиданные дампы ядра, программы были, вероятно,
скомпилированы, используя старый заголовок или файлы библиотеки. В этом случае проверьте дату mysql.h файл и libmysqlclient.a библиотека,
пользовавшаяся для компиляции, чтобы проверить, что они от нового распределения MySQL. В противном случае
перекомпилируйте, он программирует с новыми заголовками и библиотеками. Перекомпиляция могла бы также быть
необходимой для программ, скомпилированных против совместно используемой клиентской библиотеки, если номер
основной версии библиотеки изменился (например, от libmysqlclient.so.15 к
libmysqlclient.so.16).
У клиентов есть максимальный коммуникационный размер буфера. Размер буфера, который выделяется первоначально (16 Кбит), автоматически увеличивается до максимального размера (16 МБ по умолчанию). Поскольку буферные размеры увеличиваются только, поскольку требование гарантирует, просто увеличивая максимальный предел сам по себе не заставляет больше ресурсов использоваться. Эта проверка размера является главным образом предосторожностью против ошибочных операторов и коммуникационных пакетов.
Коммуникационный буфер должен быть достаточно большим, чтобы содержать единственный SQL-оператор (для трафика
клиента к серверу) и одна строка возвращенных данных (для трафика сервера клиенту). Коммуникационный буфер
каждого сеанса динамически увеличивается, чтобы обработать любой запрос или строку до максимального предела.
Например, если Вы имеете BLOB
значения, которые содержат до 16 МБ данных, у Вас должен быть коммуникационный буферный предел по крайней мере
16 МБ (и в сервере и в клиенте). Максимум значения по умолчанию клиента составляет 16 МБ, но максимум значения
по умолчанию в сервере составляет 1 МБ. Можно увеличить это, изменяя значение max_allowed_packet параметр при запуске сервера. См. Раздел
8.11.2, "Настраивая Параметры Сервера".
Сервер MySQL уменьшает каждый коммуникационный буфер к net_buffer_length байты после каждого запроса. Для клиентов не уменьшается размер
буфера, связанного с соединением, пока соединение не закрывается, в котором исправляется клиентская память
времени.