Mysql библиотека отладчика mysql


Содержание

15 примеров команды mysqlbinlog для двоичных файлов в MySQL

Главное меню » Базы данных » База данных MySQL » 15 примеров команды mysqlbinlog для двоичных файлов в MySQL

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

Двоичный журнал очень полезен в репликации MySQL, где главный сервер будет отправлять данные из двоичных журналов на удаленные сервера.

Вы также будете иметь дело с бинарными файлами журнала, когда выполняете какие-либо операции восстановления в MySQL.

Команда mysqlbinlog используется для просмотра содержимого двоичного журнала в удобном для чтения формате. Вы также будете использовать команду mysqlbinlog для чтения содержимого и подключения его к другим утилитам mysql.

В этом уроке мы обсудим следующие примеры, используя команду mysqlbinlog:

  1. Получить список текущих двоичных журналов
  2. Поведение по умолчанию Mysqlbinlog
  3. Получить записи для конкретной базы данных
  4. Отключить двоичный журнал для восстановления
  5. Управление base-64 в выводе BINLOG
  6. Отладочная информация в выводе mysqlbinlog
  7. Пропустить первые N количество записей
  8. Сохранить вывод в файл
  9. Извлечение записей, начиная с определенного положения
  10. Извлечь записи до определенного положения
  11. Сбросить журналы для чистого вывода Binlog
  12. Отображать только SQL-запросы в выводе
  13. Просмотр записей, начиная с определенного времени
  14. Просмотр записей до определенного времени
  15. Получить двоичный журнал с удаленного сервера

1. Получить список текущих двоичных журналов

Из mysql выполните следующую команду show binary logs, которая отобразит все бинарные журналы в вашей системе.

Если вы не используете двоичный журнал, то вы увидите следующее сообщение об ошибке.

По умолчанию файлы двоичного журнала находятся в каталоге /var/lib/mysql, как показано ниже.

2. Поведение по умолчанию Mysqlbinlog

Далее будет отображаться содержимое указанного бинарного файла журнала mysql (например: mysqld-bin.000001) в удобном для пользователя формате.

Ниже приводится частичный вывод указанной выше команды:

Вышеприведенная команда отображает события, которые произошли во всей базе данных в этой системе.

3. Получить записи для конкретной базы данных

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

Используя параметр -d, вы также можете указать имя базы данных, которое будет отображаться в событиях, которые происходят в данной базе данных.

Следующая команда сбрасывает все события, принадлежащие базе данных «crm», в файл crm-events.txt

Вместо опции -d вы также можете использовать параметр -database, как показано ниже.

4. Отключите двоичный журнал для восстановления.

Когда вы используете mysqlbinlog для восстановления базы данных из-за сбоя, вы не хотите, чтобы ваш процесс восстановления создавал двоичные журналы. Если да, то вы окажетесь в цикле, где вы продолжите восстановление, так как само восстановление будет генерировать новые двоичные файлы журналов.

Таким образом, чтобы отключить двоичный журнал, когда вы используете команду mysqlbinlog, используйте параметр -D, как показано ниже:

Вы также можете использовать -disable-log-bin, как показано ниже. Следующее точно так же, как приведенная выше команда.

Этот параметр также будет полезен, если вы используете опцию «–to-last-log». Кроме того, имейте в виду, что вам нужна привилегия root для выполнения этой команды.

Для резервного копирования и восстановления вы обычно используете команду mysqldump, но иногда в ситуации, когда вам приходится восстанавливаться после сбоя, полезно использовать mysqlbinlog.

5. Управление base-64 в выводе BINLOG

Используя опцию base64-output, вы можете управлять поведением, когда оператором вывода должны быть операторы BINLOG, закодированные в base64.

Ниже приведены возможные значения для base64-output:

  • never
  • always
  • decode-rows
  • auto (this is default)

never: Когда вы укажете «never», как показано ниже, будут выводиться операторы BINLOG с кодировкой base64 в выходном файле.

т.е. когда вы используете «never», в выводе команды mysqlbinlog вы не будете использовать строки, похожие на следующие, которые имеют BINLOG с кодировкой base64.

Обратите внимание, что вышеупомянутая опция «never» для вывода base64 будет работать в двоичных файлах журнала, если они не содержат события на основе строк.

always: когда вы укажете опцию «always», отображать только записи BINLOG, когда это возможно. Таким образом, используйте это только тогда, когда вы специально отлаживаете некоторые проблемы.

Ниже приведен вывод выше с помощью «always», который показывает только записи BINLOG.

decode-rows: эта опция будет декодировать события на основе строк в комментированные инструкции SQL, особенно если вы укажете опцию -verbose также вместе с ней, как показано ниже.

auto: Это опция по умолчанию. Если вы не укажете опцию base64-decode, она будет использовать auto. В этом случае mysqlbinlog будет печатать записи BINLOG только для определенных типов событий, таких как события на основе строк и события описания формата.

Оба следующих утверждения точно совпадают.

6. Отладочная информация в выводе mysqlbinlog.

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

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

7. Пропустить первые N количество записей

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

Для этого используйте опцию -o. -o означает смещение.

Ниже перечислены первые 10 записей в указанном журнале bin mysql.

Чтобы убедиться, что это работает должным образом, дайте номер события для смещения, и вы не увидите никаких записей. Следующий пример пропустит первые 10 000 записей (событий) из журнала.

В этом примере, поскольку этот конкретный файл журнала, нет 10 000 записей, он не указывает на какие-либо события базы данных на выходе.

8. Сохранить вывод в файл

Вы можете использовать простую команду перенаправления Linux > и сохранить вывод в файл, как показано ниже.

Или вы можете использовать параметр -r (файл результата), как показано ниже, для сохранения вывода в файле. Обратите внимание, что -r и -result- file совпадают.

9. Извлечь записи, начиная с определенного положения

Обычно в бинарном файле mysql вы увидите номера позиций, как показано ниже. Ниже представлен частичный вывод mysqlbinlog, где вы видите «15028» – номер позиции.

Следующая команда начнет считывать записи двоичного журнала с номером позиции 15028.

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

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

10. Извлечь записи до определенного положения

Как и в предыдущем примере, вы также можете читать записи из двоичного журнала mysql до определенной позиции, как показано ниже.

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

11. Сбросить журналы для чистого вывода Binlog

Когда двоичный журнал не был правильно закрыт, на выходе вы увидите предупреждающее сообщение, как показано ниже.

Как вы видите здесь, он говорит, что файл binlog не был закрыт должным образом.

Когда вы это увидите, подключитесь к mysql и очистите журналы, как показано ниже.

После того, как вы очистите журналы и снова выполните команду mysqlbinlog, вы не увидите, что binlog не закрыл должным образом предупреждающее сообщение в вашем выводе mysqlbinlog.

12. Отображать только SQL-запросы в выводе

По умолчанию, как вы видите в выводе предыдущих примеров, помимо SQL-запросов, вы также увидите некоторую дополнительную информацию в выводе mysqlbinlog.

Если вам нужны только обычные SQL-запросы и ничего больше, используйте опцию -s, как показано ниже.

-s здесь означает короткую форму. Вы также можете использовать опцию -short-form. Оба приведенных ниже примера совпадают.

Ниже представлен частичный вывод вышеуказанной команды. Как вы видите здесь, он отображает только SQL-запросы из данного файла двоичного журнала.

В короткой форме вы не увидите следующее:

13. Просмотр записей, начиная с определенного времени

Ниже перечислены только те записи, которые начинаются с указанного времени. Любые записи до этого времени будут проигнорированы.

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

Формат метки времени может быть любым, что понимается типами DATETIME и TIMESTAMP сервера MYSQL. Итак, у вас здесь много гибкости.

14. Просмотр записей до определенного времени

Как и в предыдущем примере времени начала, вы также можете указать время остановки, как показано ниже.

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

15. Получить двоичный журнал с удаленного сервера

С вашего локального компьютера вы также можете прочитать бинарные журналы mysql, расположенные на удаленном сервере.

Для этого вам необходимо указать IP-адрес, имя пользователя и пароль для удаленного сервера, как описано ниже.

Используйте для этого вариант -R. Параметр -R аналогичен -read-from-remote-server.

В приведенном выше:

  • Параметр -R указывает команде mysqlbinlog считывать файл журнала с удаленного сервера
  • -h указать ip-адрес удаленного сервера
  • -p даст вам пароль. По умолчанию он будет использовать «root» в качестве имени пользователя. Вы также можете указать имя пользователя, используя опцию -u.
  • mysqld-bin.000001 Это имя бинарного файла журнала с удаленного сервера, который мы здесь читаем.

Следующая команда точно такая же, как приведенная выше команда:

Ниже приводится частичный вывод указанной выше команды:

Если вы укажете только параметр -h, вы получите следующее сообщение об ошибке.

Если у вас недостаточно прав для удаленной базы данных, вы получите сообщение об ошибке “is not allowed to connect”. В этом случае убедитесь, что вы предоставили правильные привилегии в удаленной базе данных для своего локального клиента (т. е. когда запущена команда mysqlbinlog)

Если вы не укажете правильный пароль с помощью параметра -p, вы получите следующее сообщение об ошибке «access denied»

В следующем примере показано, что вы также можете использовать опцию -u для указания имени пользователя, которое должен использовать mysqlbinlog для подключения к удаленной базе данных MySQL. Обратите внимание, что этот пользователь является пользователем mysql (а не пользователем Linux-сервера).

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

FPublisher

Web-технологии: База знаний

Документация MySQL

Приложение E. Перенос на другие системы
Пред. След.

Приложение E. Перенос на другие системы

Цель данного раздела — обеспечить помощь в переносе MySQL на другие операционные системы. Но сначала необходимо ознакомиться со списком поддерживаемых в настоящее время операционных систем (see Раздел 2.2.3, «Операционные системы, поддерживаемые MySQL»). Если вы создали новую версию переноса MySQL, пожалуйста, сообщите нам — тогда мы включим ее в настоящий список и в список на нашем веб-сайте (http://www.mysql.com/) и сможем рекомендовать ее другим пользователям.

Примечание: те, кто создаст новую версию переноса MySQL, имеют право размножать и распространять на условиях лицензии GPL, но это не делает их обладателями авторского права на MySQL.

При переносе на новый вариант Unix без хорошей поддержки собственных потоков наиболее трудной частью является перенос потоков MIT-pthreads. См. mit-pthreads/README и Programming POSIX Threads (Программирование POSIX-потоков) (http://www.humanfactor.com/pthreads/).

В состав поставки MySQL входит исправленная версия Pthreads Провензано (Provenzano) от MIT (см. веб-страницу MIT Pthreads на http://www.mit.edu:8001/people/proven/pthreads.html). Эту версию можно применять для операционных систем, не имеющих POSIX-потоков.

Можно использовать и другой пакет потоков пользовательского уровня — FSU Pthreads (страница FSU Pthreads). Эта реализация применяется для переноса SCO.

Для ознакомления этими проблемами и анализа их следует изучить программы thr_lock.c и thr_alarm.c в каталоге mysys .

И сервер, и клиент нуждаются в работающем компиляторе C++ (мы используем gcc , испытывали также SPARCworks). Еще одним работающим компилятором является Irix cc .

Для компиляции только клиентской части используйте ./configure —without-server .

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

Если необходимо изменить любой Makefile или скрипт конфигурации, следует использовать Automake и Autoconf . Мы применяли версии automake-1.2 и autoconf-2.12 .

Ниже перечислены действия, необходимые для того, чтобы собрать все заново из базовых файлов:


Если вы столкнетесь с проблемами новой версии переноса, то, возможно, потребуется произвести некоторую отладку MySQL! See Раздел E.1, «Отладка сервера MySQL».

Примечание: прежде чем запускать отладку mysqld , нужно добиться, чтобы заработала тестовая программа mysys/thr_alarm and mysys/thr_lock , — тогда у вас появится хотя бы призрачный шанс получить рабочие потоки.

E.1. Отладка сервера MySQL

Если вы используете в MySQL совершенно новую функциональную возможность, то можно попробовать запустить mysqld с параметром —skip-new (при этом все новые, потенциально ненадежные функции будут заблокированы) или с параметром —safe-mode — он отключает ряд оптимизаций, которые могут вызвать проблемы. See Раздел A.4.1, «Что делать, если работа MySQL сопровождается постоянными сбоями».

Если mysqld не хочет стартовать, то необходимо посмотреть, не влияют ли на ваши настройки какие-либо конфигурационные файлы! Вы можете проверить аргументы файла my.cnf с помощью mysqld —print-defaults и, чтобы запретить их использование, стартовать mysqld с параметром —no-defaults .

Если для запуска mysqld требуется большое количество ресурсов центрального процессора или памяти, а также в случае зависания программы можно использовать команду mysqladmin processlist status . Эта команда позволит определить, какой именно запрос требует столь длительного времени выполнения. При изучении проблем, связанных с производительностью или трудностями при подсоединении новых клиентов, иногда полезно запустить команду mysqladmin -i10 processlist status в другом окне.

Команда mysqladmin debug выводит в журнальный файл информацию о применяемых блокировках, используемой памяти и работе с запросами запросов — возможно, это поможет вам решить некоторые проблемы. Данная команда снабдит вас полезной информацией даже в том случае, если код MySQL не был скомпилирован для отладки!

Если проблема заключается в том, что некоторые таблицы справляются с работой все медленнее и медленнее, то такие таблицы необходимо попробовать оптимизировать с помощью команды OPTIMIZE TABLE или myisamchk . See Глава 4, Администрирование баз данных. Для проверки медленных запросов можно также использовать EXPLAIN .

Кроме того, чтобы решить уникальные для конкретных условий эксплуатации проблемы, необходимо изучить раздел данного руководства, в котором описывается специфика определенной операционной системы. See Раздел 2.6, «Заметки по операционным системам».

E.1.1. Компиляция MySQL для отладки

Иногда в случае каких-либо очень специфических проблем помогает отладка MySQL. Для этого необходимо сконфигурировать сборку MySQL с параметрами —with-debug или —with-debug=full . Чтобы проверить, был ли код MySQL скомпилирован с возможностью отладки, нужно запустить команду: mysqld —help . Если среди опций присутствует флаг —debug , то отладка доступна. Кроме того, если задана возможность отладки, команда mysqladmin ver выводит версию mysqld как mysql . —debug .

При использовании компиляторов gcc или egcs рекомендуется следующая конфигурационная строка:

Такая запись позволит избежать проблем с библиотекой libstdc++ и исключениями C++ (многие компиляторы имеют проблемы с исключениями C++ в кодах потоков) и скомпилировать версию MySQL с поддержкой всех кодировок.

Если есть подозрение, что может возникнуть ошибка переполнения памяти, то можно сконфигурировать MySQL с параметром —with-debug=full , чтобы установить программу контроля выделения памяти ( SAFEMALLOC ). Однако SAFEMALLOC замедляет работу системы, поэтому при возникновении проблем с производительностью необходимо запустить mysqld с опцией —skip-safemalloc . Эта опция заблокирует проверки переполнения памяти для каждого вызова malloc и free .

Если mysqld перестает падать в аварийном режиме при компиляции ее с параметром —with-debug , то, возможно, вы нашли ошибку в компиляторе или произошла ошибка синхронизации внутри MySQL. В этом случае можно попытаться добавить к переменным CFLAGS и CXXFLAGS в приведенной выше конфигурационной строке -g и не использовать параметр —with-debug . Если mysqld и после этого будет падать, то можно по меньшей мере подключить к ней отладчик gdb или использовать gdb для core-файла, чтобы выяснить, что происходит.

В поставке MySQL для Windows файл mysqld.exe по умолчанию скомпилирован с поддержкой трассировочных файлов.

E.1.2. Создание трассировочных файлов

Если сервер mysqld не запускается или если вы можете вызвать его скорую аварийную остановку, то для выяснения причин неполадок можно попытаться создать трассировочный файл.

Для этого необходимо иметь mysqld , скомпилированный для отладки. Проверить, скомпилирован ли mysqld для отладки можно, выполнив mysqld -V . Если номер данной версии заканчивается на -debug , то она скомпилирована с поддержкой трассировочных файлов.

Запустите сервер mysqld с журналом трассировки в каталоге /tmp/mysqld.trace (или C:\mysqld.trace под Windows):

Под Windows необходимо также использовать флаг —standalone , чтобы mysqld не стартовал как сервис:

В окне DOS введите следующее:

После этого можно использовать клиента командной строки mysql.exe во втором окне DOS, чтобы воспроизвести проблему. Для остановки описанного выше сервера mysqld следует воспользоваться командой mysqladmin shutdown .

Следует учесть, что трассировочный файл получится очень большим! Чтобы получить трассировочный файл меньшего размера, можно использовать что-нибудь вроде:

при этом в каталог /tmp/mysqld.trace будет выводиться только информация с наиболее интересными для вас признаками.

Если вы создаете отчет о подобных ошибках, то, пожалуйста, присылайте в соответствующий список рассылки только те строки из трассировочного файла, которые, по вашему мнению, имеют непосредственное отношение к ошибке! Те же, кто затрудняются определить место ошибки, могут загрузить на ftp трассировочный файл вместе с отчетом об ошибках по адресу ftp://support.mysql.com/pub/mysql/secret/, чтобы разработчики MySQL могли взглянуть на него.

Трассировочный файл создается с помощью пакета DBUG , автором которого является Фред Фиш (Fred Fish). See Раздел E.3, «Пакет DBUG».

E.1.3. Отладка mysqld при помощи gdb

В большинстве операционных систем можно запускать mysqld под отладчиком gdb — это позволяет получить больше информации при аварийных остановках mysqld ,

С некоторыми более старыми версиями gdb под Linux, чтобы обеспечить возможность отладки потоков mysqld , необходимо использовать run —one-thread . В этом случае в каждый момент времени доступен для отладки только один поток. Нам остается только рекомендовать вам как можно быстрее заменить старые версии отладчика на версию gdb 5.1, поскольку отладка потоков в этой версии работает намного лучше!

При работе mysqld под отладчиком gdb необходимо заблокировать трассировку стеков при помощи —skip-stack-trace , что обеспечит возможность выявить ошибки сегмантацию внутри gdb .

Если постоянно подсоединяются новые пользователи, то отладка MySQL под gdb может оказаться достаточно сложным делом, поскольку gdb не освобождает память, занимаемую старыми потоками. Эту проблему можно устранить, запустив mysqld с параметрами -O thread_cache_size=’max_connections+1′ . В большинстве случаев даже простое использование -O thread_cache_size=5 может очень помочь!

Для получения дампа оперативной памяти под Linux, если mysqld падает по сигналу SIGSEGV , можно запустить mysqld с опцией —core-file . Этот файл оперативной памяти (core) можно использовать для обратной трассировки при выявлении причин останова mysqld :

При использовании версии gdb 4.17.x или выше под Linux необходимо установить в текущем каталоге файл .gdb со следующей информацией:

Если при отладке потоков с помощью gdb возникают проблемы, необходимо загрузить версию gdb 5.x и попробовать использовать ее вместо прежней. Новая версия отладчика gdb обеспечивает значительно улучшенную обработку потоков!

Ниже приводится пример отладки mysqld:

Если mysqld зависает, можно попробовать использовать некоторые системные средства наподобие strace или /usr/proc/bin/pstack для выяснения, где именно произошло зависание mysqld .

Если используется интерфейс Perl DBI , то можно получить отладочную информацию, используя метод trace или установив переменную окружения DBI_TRACE . See Раздел 8.2.2, «Интерфейс DBI ».

E.1.4. Использование трассировки стека

В некоторых операционных системах журнал ошибок в случае смерти mysqld будет содержать трассировку стека. Эти данные можно использовать для выяснения, где (и, может быть, почему) умер mysqld (see Раздел 4.9.1, «Журнал ошибок»). Для получения трассировки стека не следует компилировать mysqld с опцией -fomit-frame-pointer для gcc (see Раздел E.1.1, «Компиляция MySQL для отладки»).

Если файл ошибок содержит что-нибудь похожее на следующее:

то можно определить, где произошла остановка mysqld . Для этого нужно выполнить следующие действия:

Скопируйте приведенные выше числовые значения в файл, например mysqld.stack .

Создайте файл символов для сервера mysqld :

Следует учесть, что во многих бинарных поставках MySQL приведенный выше файл с именем mysqld.sym.gz уже имеется. В этом случае необходимо распаковать его следующим образом:

Выполните resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack , чтобы вывести место остановки mysqld . Если и это не поможет определить причину останова mysqld , то следует сделать отчет об ошибке и включить в него данный вывод с комментарием. Следует учитывать, однако, что в большинстве случаев наличие лишь только трассировки стеков не поможет нам определить причину данной проблемы. Чтобы иметь возможность локализовать данный сбой или рекомендовать обходной путь, нам, как правило, необходимо знать, какой именно запрос привел к остановке mysqld и, желательно, иметь контрольный пример, чтобы мы могли воспроизвести данную проблему! See Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах».

Илон Маск рекомендует:  Подбор синонимов и антонимов с помощью редактора Word

E.1.5. Использование журналов для определения причин ошибок в mysqld

Обратите внимание: перед запуском mysqld с —log необходимо проверить все используемые таблицы с помощью myisamchk (see Глава 4, Администрирование баз данных).

Если демон mysqld умрет или зависнет, следует запустить mysqld с опцией —log . Если аварийное завершение mysqld снова повторится, то можно исследовать часть журнала, относящуюся к запросу, убившему mysqld .

При использовании опции —log без имени файла данный журнал хранится в каталоге базе данных как `hostname`.log . В большинстве случаев именно последний запрос в системном журнале приводит к смерти mysqld , но при возможности лучше в этом убедиться: перезапустите mysqld и выполните найденный запрос из командной строки mysql . Если запрос выполняется, то следует протестировать все сложные запросы, которые не завершились.

Можно также попробовать выполнить команду EXPLAIN для всех выражений SELECT , которые занимают длительное время, чтобы убедиться, что mysqld правильно использует индексы. See Раздел 5.2.1, «Синтаксис оператора EXPLAIN (получение информации о SELECT )».

Запросы, требующие слишком длительного времени для выполнения, можно выявить, запустив mysqld с параметром —log-slow-queries . See Раздел 4.9.5, «Журнал медленных запросов».

Если демон mysqld был запущен с параметром myisam-recover , то MySQL автоматически проверяет и пытается восстановить таблицы MyISAM (если они отмечены как «таблица не закрыта правильно» или «таблица повреждена»). В этом случае MySQL запишет в файл hostname.err предупреждение: » Warning: Checking table . «, за которым следует » Warning: Repairing table «, если данную таблицу следует исправить. Если таких ошибок в журнале много, а mysqld перед этим не умирал со сбоем, то что-то работает неправильно и необходимы дальнейшие исследования. See Раздел 4.1.1, «Параметры командной строки mysqld ».

Конечно, неожиданная смерть mysqld — событие малоприятное, но в этом случае следует не изучать сообщения » Checking table. «, а попытаться найти причины остановки mysqld .

E.1.6. Создание контрольного примера при повреждении таблиц

Когда таблицы оказываются поврежденными или mysqld всегда дает сбой после некоторых команд, то можно провести испытания (если данный сбой воспроизводим). Для этого нужно выполнить следующие действия:

Остановите демон MySQL (с помощью команды mysqladmin shutdown ).

Сделайте резервную копию таблиц (в качестве меры предосторожности на случай, если процесс исправления таблиц пройдет некорректно, хотя это и маловероятно).

Проверьте все таблицы с помощью команды myisamchk -s database/*.MYI . Исправьте некорректные таблицы с помощью команды myisamchk -r database/table.MYI .

Создайте еще раз резервные копии этих таблиц.

Переместите (или удалите совсем) все старые журнальные файлы из каталога данных MySQL, если нужно освободить больше места.

Запустите mysqld с —log-bin (see Раздел 4.9.4, «Бинарный журнал обновлений»). Если вы хотите найти запрос, который приводит к сбою mysqld , то следует использовать —log —log-bin .

Когда таблица с искажениями будет получена, остановите сервер mysqld .

Восстановите систему из резервной копии.

Перезапустите сервер mysqld без —log-bin .

Выполните заново команды mysqlbinlog update-log-file | mysql . Обновленная запись в журнале сохраняется в каталоге баз данных MySQL с именем hostname-bin.# .

Если в результате вышеприведенной команды таблицы опять окажутся поврежденными или вы можете получить сбой в работе mysqld , то, значит, вы нашли повторяющуюся ошибку, которую можно исправить! Загрузите эти таблицы и запись из двоичного журнала по адресу ftp://support.mysql.com/pub/mysql/secret/ и пошлите письмо с описанием данной проблемы на [email protected] или (если вы являетесь коммерческим пользователем) на [email protected] — и команда разработчиков MySQL устранит ошибку настолько быстро, насколько это возможно.

Для локализации проблемы можно также использовать скрипт mysql_find_rows , чтобы просто выполнить ряд обновляющих команд.

E.2. Отладка клиента MySQL

Чтобы иметь возможность отладки клиента MySQL с помощью встроенного отладчика, необходимо сконфигурировать сборку MySQL с —with-debug или —with-debug=full . See Раздел 2.3.3, «Типичные опции configure ».

Перед запуском клиента следует установить переменную окружения MYSQL_DEBUG :

Это заставит клиента генерировать трассировочный файл в /tmp/client.trace .

Если существуют проблемы с кодом конкретного клиента, необходимо попытаться соединиться с сервером и послать запрос, используя другой заведомо работоспособный клиент. Это следует делать при работе mysql в режиме отладки (предполагается, что данный экземпляр MySQL скомпилирован с возможностью отладки):

приведенный выше вызов снабдит вас полезной информацией для отчета об ошибках. See Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах».

Если ваш клиент, имея «правильный» на первый взгляд код, отказывается устойчиво работать, необходимо проверить, соответствует ли включаемый файл mysql.h файлу вашей библиотеки mysql . Очень распространенная ошибка заключается в том, что используется старый файл mysql.h из MySQL старой установки с новой библиотекой MySQL.

E.3. Пакет DBUG

Сервер MySQL и большинство клиентов MySQL компилируются с пакетом DBUG , автором первой версии которого является Фред Фиш (Fred Fish). При конфигурации MySQL в отладочном режиме этот пакет дает возможность получить трассировочный файл для отладки программы. See Раздел E.1.2, «Создание трассировочных файлов».

Чтобы воспользоваться пакетом отладки, следует в вызове программы задать опцию —debug=». » или -#.

Большинство программ MySQL по умолчанию имеют отладочную строку, которая будет использована, если не задана опция —debug . По умолчанию трассировочный файл обычно находится в /tmp/имя_программы.trace под Unix и в \имя_программы.trace под Windows.

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

Каждое поле состоит из обязательного флагового символа, за которым следует необязательный символ «,» и разделенный запятыми список модификаторов:

В настоящее время распознаются следующие символы флагов:

Флаг Описание
d Разрешает вывод из макроса DBUG_ для текущего состояния. За этим флагом может следовать список ключевых слов. Если задан такой список, то из вывода макроса DBUG будет выбираться вывод только с данными ключевыми словами. Если задан пустой список ключевых слов, выбирается вывод всего макроса.
D Задает задержку вывода после каждой строки отладчика. Аргумент представляет собой количество десятых долей секунд задержки в соответствии с возможностями машины. Т.е. D,20 означает задержку в две секунды.
f Ограничивает отладку и/или трассировку и профайлинг только перечисленными в списке функциями. Обратите внимание: если задан нулевой список, то будут заблокированы все функции. Соответствующие флаги » d » или » t » должны также задаваться, данный флаг только ограничивает их действия, если они разрешены.
F Идентифицирует имя исходного файла для каждой строки вывода отладки или трассировки.
i Идентифицирует процесс указанием pid или идентификатором потока ( thread id ) в каждой строке вывода отладки или трассировки.
g Разрешает профайлинг. Создает файл с именем dbugmon.out , содержащий информацию, которую можно использовать для профайлинга программы. За этим флагом может следовать список ключевых слов; если такой список задан, то профайлинг будет применяться только для функций из этого списка. Если задан нулевой список ключевых слов, то профайлинг применяется ко всем функциям.
L Идентифицирует номер строки исходного файла для каждой строки вывода отладки или трассировки.
n Задает вывод глубины вложенности текущей функции для каждой строки вывода отладки или трассировки.
N Задает нумерацию каждой строки в выводе dbug .
o Переадресует выходной поток отладчика в указанный файл. По умолчанию вывод осуществляется в stderr.
O То же, что и o , но указанный файл сбрасывается на диск каждый раз между операциями записи. При необходимости этот файл закрывается и снова открывается каждый раз между операциями записи.
p Ограничивает действия отладчика указанным процессом. Процесс должен быть идентифицирован макросом DBUG_PROCESS и совпадать с указанным в списке для действий отладчика.
P Выводит имя текущего процесса для каждой строки вывода отладки или трассировки.
r Не наследовать уровень вложенности функции в предыдущем состоянии при переходе в новое состояние. Полезно, если вывод должен начинаться с левого поля.
S Выполнять функцию _sanity(_file_,_line_) для каждой отлаженной функции, пока _sanity() не возвратит значение, отличное от 0 . (Главным образом используется совместно с safemalloc для определения утечек памяти).
t Разрешает трассировку вызовов функций/выход из функций. За этим параметром может следовать список (содержащий только один модификатор). Данный модификатор задает число — максимальный уровень вложения функций, ниже которого не производится вывод ни для отладочного, ни для трассировочного макросов. Параметр по умолчанию задается во время компиляции.

Ниже представлены некоторые примеры строк управления отладкой, которые можно применять в командной строке оболочки (символ » -# » обычно используется для внедрения управляющей строки в программу):

В MySQL обычно применяются следующие дескрипторы для вывода (совместно с опцией d ): enter,exit,error,warning,info и loop .

E.4. Методы блокировки

В настоящее время MySQL поддерживает только табличную блокировку для таблиц типов ISAM/MyISAM и HEAP, страничную блокировку для таблиц BDB и строковую блокировку для таблиц InnoDB (see Раздел 5.3.1, «Как MySQL блокирует таблицы»). Для таблиц MyISAM можно произвольным образом сочетать команды INSERT и SELECT без блокировок, поскольку поддерживается управление версиями (Versioning).

Начиная с версии 3.23.33 имеется возможность анализировать конфликты и конкуренцию блокировок таблиц в системе. Это делается путем проверки переменных Table_locks_waited и Table_locks_immediate .

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

Аргументы в пользу строковой блокировки:

Меньше конфликтов блокировок при обращении к различным строкам из множества потоков.

Меньше изменений при откатах.

Возможна блокировка одной строки на длительное время.

Аргументы против строковой блокировки

Требуется больше памяти, чем при страничной или табличной блокировке.

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

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

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

Блокировки на уровне таблиц лучше, чем блокировки страничного/строкового уровня в следующих случаях:

Когда производится главным образом чтение.

При чтении и обновлении для строго заданных ключей; при обновлении или удалении строки, которая может быть извлечена чтением одного ключа:

SELECT с INSERT (и очень мало операций UPDATE и DELETE ).

Выполняется много операций просмотра и группировки GROUP BY на всей таблице без записи.

Другие возможности, кроме строчного/страничного уровня блокирования:

Управление версиями (Versioning), подобно тому, как это делается в MySQL для параллельных вставок. При этом один из пользователей может выполнять операцию записи в то же время, когда несколько пользователей производят чтение. Это означает, что данная база данных/таблица поддерживает различные представления для данных в зависимости от того, когда произошло обращение к ним. Существуют и другие названия этой возможности — перемещение по времени (time travel), метод копирования в момент записи (copy on write) или метод копирования по запросу (copy on demand).

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

Вместо использования блокировок строкового уровня можно применять блокировки уровня приложения (подобно get_lock/release_lock в MySQL). Конечно, такие блокировки годятся только для корректно работающих приложений.


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

Ниже приводится несколько советов по блокировкам в MySQL:

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

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

В случае сочетания вставок и удалений в одной и той же таблице очень полезно применять INSERT DELAYED .

Для повышения скорости можно также использовать LOCK TABLES (несколько обновлений в рамках одной блокировки выполняются намного быстрее, чем обновления без блокировок). Целесообразно также распределять данные по различным таблицам.

Иногда проблемы со скоростью при блокировках таблиц в MySQL удается решить преобразованием ряда таблиц в таблицы типа InnoDB или BDB. See Раздел 7.5, «Таблицы InnoDB ». See Раздел 7.6, «Таблицы BDB или BerkeleyDB».

Большое количество различных аспектов настройки приложения рассмотрено в разделе данного руководства, посвященном оптимизации (see Раздел 5.2.12, «Другие советы по оптимизации»).

E.5. Замечания по потокам RTS

При попытке применить пакеты потоков RTS с MySQL автору пришлось столкнуться со следующими проблемами:

В этих пакетах используются старые версии большинства вызовов POSIX, поэтому очень утомительно создавать оболочки (wrapper) для всех функций. На мой взгляд, было бы легче изменить библиотеки этих потоков в соответствии с современной спецификацией POSIX.

Некоторые оболочки уже написаны (чтобы получить более подробную информацию, обращайтесь к mysys/my_pthread.c ).

Следует изменить, по меньшей мере, следующие аспекты:

В pthread_get_specific должен использоваться один аргумент, а в sigwait — два аргумента. Многие функции (по крайней мере, pthread_cond_wait , pthread_cond_timedwait ) должны возвращать код ошибки или ошибку. Сейчас они возвращают -1 и устанавливают errno .

Еще одна проблема заключается в том, что потоки пользовательского уровня используют сигнал ALRM , преждевременно прекращающий работу многих функций ( read, write, open. ). MySQL должен повторять попытку выполнить такие вызовы в случае прерывания, но это не так легко проверить.

Наиболее значительная из нерешенных проблем заключается в следующем:

Чтобы получать alarm на уровне потока, я изменил mysys/thr_alarm.c — чтобы ожидать alarm с помощью функции pthread_cond_timedwait() . Однако оказалось, что это приводит к преждевременному прекращению работы с ошибкой EINTR . Чтобы понять, почему так получается, я пытался отладить библиотеку потока, но не смог найти никакого простого решения.

Для тех, кто хочет попробовать использовать MySQL с потоками RTS, я предлагаю следующее:

Измените функции, используемые MySQL из библиотеки потоков для POSIX. Это не должно занять много времени.

Скомпилируйте все библиотеки с -DHAVE_rts_threads .

Если существуют некоторые небольшие отличия в реализации, то они могут быть устранены изменением my_pthread.h и my_pthread.c .

Запустите thr_alarm . Если программа выполняется без каких-либо предупреждений, сообщений об ошибках или об аварийном выходе, значит, вы на правильном пути. Ниже приводится успешный прогон программы под Solaris:

E.6. Различия между разными потоковыми пакетами

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

Существуют по меньшей мере три типа потоковых пакетов:

Пользовательские потоки в одном процессе. Переключение потоков осуществляется сигналами (alarm) и библиотека потоков управляет всеми функциями, не поддерживающими потоки, с помощью блокировок. Операции чтения, записи и выборки обычно управляются программой выбора потоков, которая переключает их на другой поток, если текущий должен ожидать данные (речь идет о вызове select). Пакеты пользовательских потоков могут быть интегрированы в стандартные библиотеки (FreeBSD- и BSDI-потоки). Такие интегрированные пакеты требуют меньше затрат в сравнении с потоковыми пакетами, которые должны обрабатывать все ненадежные вызовы (MIT-pthreads, FSU Pthreads и потоки RTS). В некоторых средах (например SCO) все системные вызовы поддерживают потоки, так что обработка может быть выполнена очень просто (FSU Pthreads под SCO). Недостатки такого метода: поскольку все вызовы, для которых установлены соответствия, занимают мало времени, очень сложно контролировать обработку всех ситуаций. Обычно существуют также системные вызовы, не обрабатываемые потоковым пакетом (такие как MIT-pthreads и сокеты). Диспетчеризация потоков не всегда является оптимальной.

Пользовательские потоки в раздельных процессах. Переключение потоков производится ядром и все данные используются совместно всеми потоками. Потоковый пакет управляет стандартными вызовами потоков, чтобы обеспечить совместное использование данных этими потоками. Такой метод используется в LinuxThreads. Недостатки этого метода: масса процессов; медленное создание потока. Если один поток умирает, то остальные обычно зависают и необходимо их уничтожать перед перезапуском. Переключение потоков отчасти затратно.

Потоки ядра. Переключение потоков управляется потоковой библиотекой или ядром и происходит очень быстро. Все делается в одном процессе, но для некоторых систем ps может показывать разные потоки. Если один из потоков неожиданно умрет, то происходит аварийное прерывание всего процесса. Большинство системных вызовов поддерживают потоки и должны требовать очень небольших затрат. С потоками ядра работают Solaris, HP-UX, AIX и OSF/1.

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

Форум Pawn-Wiki.Ru — Воплоти мечту в реальность!: Плагин MySQL — разбор функций — Форум Pawn-Wiki.Ru — Воплоти мечту в реальность!

Всем здравствуйте. На данном форуме много уроков по MySQL и по переводу мода на него, но нет урока, который бы описывал функции данного плагина. В официальном WIKI описание функций только на английском.

Поэтому я решил написать урок, посвященный всем доступным функциям MySQL

Ну для начала: по этой ссылке можно скачать плагин MySQL для сервера. Тут же есть и описание функций (на англ)
Кстати, функции подходят только к плагину от BlueG ( G-sTyLeZzZ)

Функции плагина
Примечание : Каждая функция (кроме mysql_connect и mysql_debug) имеет параметр connectionHandle — ID базы данных. Если вы подключены только к одной базе данных, то вам не нужно использовать данный параметр. Он всегда будет 1 по умолчанию

С помощью данной функции можно включить / отключить запись всех действий с базой данных в лог (не рекомендую, если не требуется — может тормозить сервер)

enable: 0 — отключить, 1 — включить

Пример использования (так, как его использую я):

С помощью данной функции можно подключиться к Базе Данных
Важное замечание: Не пытайтесь переподключиться к Базе Данных с помощью этой функции. Для этого используйте mysql_reconnect()

const host[]: IP, на котором расположена База Данных
const user[]: логин пользователя для доступа к Базе Данных
const database[]: имя Базы Данных
const password[]: пароль, для подключения к Базе Данных

Возвращает: ID соединения (его нудно использовать в connectionHandle)

Данная функция проверяет, если ли соединение с Базой Данных
Важное замечание: проверка на состояние соединения (и рестарт, если нужно) происходят автоматически при использовании потоков

connectionHandle: ID соединения

Возвращает: 1 — если соединение есть, 0 — если нет

Данная функция получает статистику MySQL сервера

const destination[]: строка, в которую необходимо записать полученный результат
connectionHandle: ID соединения

С помощью этой функции можно изменить кодировку симовлов в Базе Данных. Полезно для использования в БД символов, отличных от английских (например, кириллицу)

charset[]: необходимая кодировка
connectionHandle: ID соединения

С помощью этой функции можно узнать, какая сейчас кодировка установлена

destination[]: строка, в которую запишем текущую кодировку
connectionHandle: ID соединения

С помощью этой функции можно переподключиться к БД

connectionHandle: ID соединения

С помощью этой функции можно попросить MySQL сервер перезагрузить таблицы пользовательских привилегий (сам не юзал)

connectionHandle: ID соединения

С помощью этой функции можно попросить MySQL сервер перезагрузить таблицы пользовательских привилегий (сам не юзал)
Важное замечание: функция добавлена в версии R6-2 плагина и не работает в более ранних версиях
Замечание: такие спецификаторы как %2.f, %10.s еще не поддерживаются

connectionHandle: ID соединения
output[]: строка, в которую придется записать результат
format[]: строка, которую нужно подготовить для запроса
. тут аргументы

Дополнения:
Эту функцию можно использовать (и надо использовать) вместо простого format, если вы хотите отправить этот запрос к БД, т.к. она автоматически проверяет запрос на запрещенные символы, которыми можно вызвать SQL инъекцию и заменяет их не безопасные

%s — обычная строка (опасные символы не трогаются)
%e — строка, которую необходимо почистить от возможной SQL инъекции (в этом и есть вся разница с format
%d — целое число (ну это и так понятно. )
%f — вещественный тип (дробь)
%i — число

Самая главная функция в плагине. Отправляет запрос к Базе Данных
Важное замечание: я рекомендую всем Вам для каждого запроса создавать потоки. Подробнее о них ниже

query[]: запрос, который необходимо отправить к Базе Данных
resultid: ID запроса (необходимо для потоков)
extraid: переменная, которую вы хотите передать в поток
connectionHandle: ID соединения

Возвращает: 1 — если запрос отправлен, 0 — если произошла ошибка

Функция схожа с mysql_query. Разница в том, что тут вы на каждый поток можете создать свой паблик

index: переменная, которую вы хотите передать для использования в потоке
query[]: запрос, который необходимо отправить к Базе Данных
callback[]: название потока (паблика)
extraid: (дополнительный) переменная, которую вы хотите передать в поток
connectionHandle: ID соединения

Замечание: так как создается новый public, не забудьте добавить к нему forward

Возвращает: 1 — если запрос отправлен, 0 — если произошла ошибка

Всегда используйте эту функцию после отправки запросов SELECT, SHOW, DESCRIBE, EXPLAIN, CHECK TABLE. Иначе будут создавать пробки
Замечание: Функция используется для сохранения результата запроса для последующей обработки. Не забывайте очищать данные, когда они больше не нужны — mysql_free_result().

connectionHandle: ID соединения

Возвращает: 1 — если сохранено, 0 — если произошла ошибка

Функция используется для очистки результата после использования mysql_store_result

connectionHandle: ID соединения

Данная функция проверяет строку на символы, которые могут вызвать SQL инъекцию и отключа Например, \x00, \n, \r, \, ‘, » и \x1a.
Важное замечание: Всегда используйте эту фунцкию (если не используете mysql_format), если хотите отправить запрос с данными полученными от игрока. Во избежание SQL инъекции

const source[]: первоначальная строка
destination[]: строка, в которую записать безопасную строку
connectionHandle: ID соединения

Замечание: Перед использованием этой функции необходимо, чтобы соединение с БД было установлено.
Замечание: Символы % и _ не блокируются, т.к. используются в некоторых запросах.

Возвращает: кол-во найденных и нейтрализованных вредоносных символов

Функция получает код ошибки предыдущей MySQL операции

connectionHandle: ID соединения

Возвращает: код ошибки, 0 — если ошибок нет

Функция получает кол-во ошибок / предупреждений из предыдущего запроса

connectionHandle: ID соединения

Возвращает: код кол-во предупреждений, 0 — если их нет

Функция получает кол-во строк работа с которыми совершилась через запросы INSERT, UPDATE, REPLACE или DELETE

connectionHandle: ID соединения

Замечание: Если последний запрос был DELETE, но без WHERE — все строки из данной таблицы будут удалены, но это функция вернет 0.

Возвращает: кол-во строк

Функция получает кол-во строк, полученных в результате выполнения запросов SELECT и SHOW (схожа с mysql_affected_rows)

connectionHandle: ID соединения

Возвращает: кол-во строк

Функция получает кол-во столбцов в результате запроса

connectionHandle: ID соединения

Возвращает: кол-во столбцов

Функция получает ID сгенерированный благодаря AUTO_INCREMENT в предыдущем INSERT запросе

connectionHandle: ID соединения

Возвращает: число вставленное в таблицу, как AUTO_INCREMENT

Функция получает кол-во столбцов в самом последнем запросе

connectionHandle: ID соединения

Возвращает: число столбцов

Функция получает число из результата запроса (только если получено 1 число)

connectionHandle: ID соединения

Возвращает: полученное число

Функция получает дробь из результата запроса (только если получена 1 дробь)

Float:result: вещественная переменная, в которую записать полученную дробь
connectionHandle: ID соединения

Функция служит для обработки полной строки из результата запроса

Замечание: Если запросом получено несколько строк, то данная функция после обработки текущей строки перейдет на следующую.
Замечание: Есть еще одна функция (точнее макрос) — mysql_fetch_row. В нем в отличии от данной функции используется разделитель по умолчанию — ‘|’

string[]: строка, в которую необходимо записать полученный результат
const delimiter[]: разделитель, которым будут разделяться значения из разных столбцов (| по умолчанию). Если не используется, то смело используйте mysql_fetch_row
connectionHandle: ID соединения

Возвращает: 1 — при обработке, 0 — если нет строк для обработки

Илон Маск рекомендует:  Генерация контента сайта с использованием template toolkit

Функция служит для перехода на следующую строку.

Замечание: Помните, что mysql_fetch_row_format автоматически переводит на следующую строку (будьте внимательны)
Замечание: Есть еще одна функция (точнее макрос) — mysql_next_row. Она полностью дублирует данную

connectionHandle: ID соединения

Возвращает: 1 — если строка сменилась, 0 — если больше нет строк


Функция получает название определенного столбца.

number: номер столбца
dest[]: строка, в которую нужно записать название столбца
connectionHandle: ID соединения

Важное замечание: Если вы укажите неверный номер столбца, плагин крешнется
Замечание: Номер первого столбца — 0

Функция получает данные из указанного столбца

Замечание: Есть еще одна функция (точнее макрос) — mysql_get_field

string[]: строка куда будет помещен результат из столбца
const fieldname[]: имя столбца, из которого будем брать данные
connectionHandle: ID соединения

Коллбеки плагина
Примечание : Используйте потоки, только если вы профессионал

Данный коллбек вызывается, когда число (отличное от -1) передается через result >mysql_query

query[] — выполненный запрос
resultid — ID потока (передается через resultid в mysql_query)
extraid — переменная (передается через extraid в mysql_query)
connectionHandle — ID соединения

Данный коллбек вызывается, когда происходит ошибка при отправлении запроса

errorid — ID ошибки
error[] — название ошибки
resultid — ID потока
extraid — переменная (передается через extraid в mysql_query)
callback[] — название коллбека, если был mysql_query_callback (если не было — NULL)
query[] — отправленный запрос
connectionHandle — ID соединения

dbForge Studio for MySQL

dbForge Studio for MySQL

Отладчик для MySQL

Как Вы отлаживаете хранимые процедуры и функции MySQL? Ни для кого не секрет, что отладка хранимых процедур без хорошего инструмента является мучением. Отладчик для MySQL, поставляемый с dbForge Studio, избавит вас от всех проблем, связанных с процессом отладки.

dbForge Studio for MySQL представляет отладчик процедур MySQL!

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

  • Первый специализированный отладчик для MySQL
  • Отлаживает любой код
  • Хранит логику MySQL сервера для выполнения процедур
  • Предоставляет полный контроль над выполнением кода
  • Превращает процесс отладки в удовольствие

Станьте обладателем первого специализированного отладчика для MySQL

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

Отлаживайте любой код

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

Сохраняйте исходную логику выполнения процедуры

Почему это важно? Так как MySQL сервер не предоставляет никакого интегрированного инструмента отладки, вы должны отлаживать вручную. Однако ручная отладка в основном влияет на исходный процесс выполнения и даже на логику процедур. Таким образом, вместо исправления ошибок Вы удваиваете их количество и в результате получаете неправильные процедуры. Отладчик для MySQL, поставляемый в dbForge Studio, знает, как избежать этого.

Получите полный контроль над выполнением кода

Отладчик для MySQL обеспечивает полный контроль над выполнением кода, включающий:

  • Полную поддержку пошагового выполнения кода (Войти в код, Выйти из кода, Перейти код)
  • Точки останова для полного контроля над выполнением кода
  • Стек вызовов с возможностью переключаться между фреймами
  • Встроенный механизм вычисления значений переменных

Получите все, чтобы наслаждаться отладкой

Отладчик для MySQL, поставляемый в dbForge Studio, содержит удобный интерфейс отладки уровня современных средств разработки ПО, таких как Microsoft Visual Studio. Работа в привычной среде с удобной функциональностью делает отладку хранимых процедур и функций простой задачей.

Учебное пособие онлайн

Прочтите статью Отладка хранимых процедур MySQL (EN) чтобы ознакомиться с тем, как эффективно использовать отладчик MySQL.

20 команд MySQL (mysqladmin) для администратора базы данных в Linux

mysqladmin – это утилита командной строки, которая поставляется с MySQL сервером и используется администраторами баз данных для выполнения некоторых простых MySQL задач, таких как установка пароля root или другого пользователя, изменение пароля root или другого пользователя, мониторинг процессов mysql, перезагрузка привилегий, проверка статуса сервера и т.д.

В этой статье собраны некоторые очень полезные команды mysqladmin, которые используется системными администраторами и администраторами баз данных в их повседневной работе. У вас уже должен быть установлен MySQL сервер, чтобы вы могли повторить эти примеры.

1. Как установить пароль MySQL Root?

Если у вас свежая установка MySQL сервера, то она не требует какого-либо пароля для подключения в качестве пользователя root. Для установки в MySQL пароля root пользователя используйте следующую команду:

2. Как изменить пароль MySQL Root?

Если вы хотите изменить или обновить пароль от root в MySQL, то вам нужно напечатать следующую команду. Допустим, ваш старый пароль это 123456, и вы хотите изменить его на новый пароль xyz123:

Аналогично операция выполняется для других пользователей, вместо root вставьте имя пользователя, для которого вы хотите изменить пароль

3. Как проверить, запущен ли MySQL сервер?

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

4. Как проверить, какую версию MySQL я использую?

Следующая команда покажет версию MySQL, а также текущий статус работы:

5. Как узнать текущий статус MySQL сервера?

Для определения статуса MySQL сервера используйте следующую команду. Mysqladmin покажет время работы с запущенными патоками и очередями.

6. Как проверить статус всех переменных и значений MySQL сервера?

Для проверки всех переменных и значений работающего MySQL сервера напечатайте следующую команду. Вывод должен быть примерно таким:

7. Как посмотреть все переменные и значения MySQL статуса?

Для просмотра всех переменных и значений запущенного MySQL сервера, используйте команду, как показано ниже:

8. Как проверить все процессы рабочего MySQL сервера?

Следующая команда отобразить все запущенные процессы запросов к базе данных MySQL:

9. Как создать базу данных на MySQL сервере?

Для создания новой команды на MySQL сервере используйте команду, которая показана ниже:

10. Как удалить базу данных на MySQL сервере?

Для удаления базы данных с MySQL сервера используйте следующую команду. Для подтверждения нажмите ‘y‘.

11. Как перезагрузить/сбросить привилегии MySQL?

Команда reload говорит серверу повторно загрузить таблицы grant. Команда refresh сбрасывает все таблицы и повторно открывает файлы журналов.

12. Как безопасно выключить MySQL сервер?

Для безопасного выключения MySQL сервера используйте следующую команду:

Вы также можете использовать следующие команды для запуска, остановки MySQL сервера:

13. Некоторые полезные команды MySQL Flush

Ниже несколько полезных flush команд с описанием.

  • flush-hosts: Очистить всю информацию из кэша хоста.
  • flush-tables: Сброс всех таблиц.
  • flush-threads: Очистить кэш всех потоков.
  • flush-logs: Очистить все информационные логи.
  • flush-privileges: Перезагрузить таблицы grant (то же как и reload).
  • flush-status: Очистить переменные статуса.

14. Как завершить спящий клиентский процесс MySQL?

Используйте следующую команду для выявления спящего клиентского процесса MySQL:

Теперь запустите команду с kill и ID процесска, как показано ниже:

Если вам нужно завершить несколько процессов, тогда передайте ID процессов в виде списка, разделённого запятыми:

15. Как вместе запустить несколько команд mysqladmin?

Если вы хотите выполнить одновременно несколько mysqladmin команд, то команда должна выглядеть примерно так:

16. Как подключиться к удалённому mysql серверу?

Для подключения к удалённому MySQL серверу исопльзуйте -h (хост) с IP адресом удалённой машины:

17. Как выполнить команды на удалённом MySQL сервере?

Допустим, вы хотите увидеть статус удалённого MySQL сервера, тогда команда будет:

18. Как запустить/остановить копирование на удалённом второстепенном MySQL сервере?

Для запуска/остановки MySQL репликации на второстепенном (salve) сервере, используйте следующие команды:

19. Как сохранить отладочную информацию MySQL в файлы журналов?

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

20. Опции и использование mysqladmin

Все опции и доступные команды mysqladmin вы сможете узнать набрав:

Мы попытались включить в статью почти все команды mysqladmin с примерами. Если мы пропустили что-то, напишите в комментариях.

C: libmysqlclient — примеры работы с MySQL API

Немного за ним заскучал, ибо язык интересный и заставляет местами поломать голову, потому решил немного освежить память.

Ниже приводятся примеры работы с сервером MySQL/MariaDB на С, используя API из библиотеки libmysqlclient .

Примеры взяты из поста MySQL C API programming tutorial с небольшими изменениями и отсебятинкой.

Получившиеся примеры доступны в репозитории тут>>> .

Устаналиваем на Ubuntu/Debian с помощью apt :

Первый пример

Напишем первый пример, который выполнит подключение к серверу MySQL, и выведет его версию:

Убедимся, что это правда:

Кратко рассмотрим сам код:

  • #include и #include : включаем заголовочные файлы для работы с MySQL, которые расположены в каталоге /usr/include/mysql/ , путь к которому передадим через вызов mysql_config (см. ниже). В частности — /usr/include/mysql/mysql.h содежит описание mysql_get_client_info()
  • затем вызываем mysql_get_client_info() , которая возвращает версию используемой библиотеки

gcc и mysql_config

При компиляции выше мы использовали вызов mysql_config , что бы получить пути к используемым библиотекам и флагам сборки MySQL-клиента.

Можно вызвать mysql_config напрямую, что бы посмотреть эти данные:

Или отобразить только неоходимые данные, что мы и делаем при вызове gcc :

Создание базы данных

В следующем примере — выполним подключение к серверу и запрос на создание новой базы данных.

Тут нам потребуются данные доступа:


  • имя хоста — cdb-example.setevoy.org.ua (через CNAME направлено на AWS RDS инстанс с MariaDB)
  • имя пользователя — setevoy
  • пароль пользователя

Подключаемся к серверу БД, создаём пользоваеля:

Приступаем к коду:

testdb появилась, всё работает.

Процесс выполнения программы:

  • MYSQL *con = mysql_init(NULL) — с помощью mysql_init() инициализируем создание новой сессии для создания подключения
  • if (con == NULL) — проверяем его состояние, если сессия не создана — выходим с ошибкой, используя exit(1);
  • mysql_real_connect(con, «cdb-example.setevoy.org.ua», «setevoy», «p@ssw0rd») — используя mysql_real_connect() создаём подключение, используя созданную сессию ( con ), и передавая имя хоста, пользователя и пароль, и тут же проверяем его состояние с помощью if mysql_real_connect() == NULL
  • mysql_query(con, «CREATE DATABASE testdb») — с помощью mysql_query() выполняем запрос на создание базы данных
  • mysql_close() — закрываем сессию, созданную с помощью mysql_init()

Создание и наполнение таблицы

Теперь у нас есть пользователь, и база.

Следующим шагом — создадим в этой базе таблицу, и запишем в неё данные:

Тут, что бы не писать один и тот же код при каждом выполнении запросов к MySQL, мы сначала определяем единую функцию, которую будем использовать для проверки успешности подключения:

Затем подключаемся к базе, удаляем таблицу, если она есть ( mysql_query(con, «DROP TABLE IF EXISTS ExampleTable») ), создаём новую таблицу с тремя колонками ( mysql_query(con, «CREATE TABLE ExampleTable(Id INT, TextCol TEXT, IntCol INT)» ), и вносим тестовые данные ( mysql_query(con, «INSERT INTO ExampleTable VALUES(1, ‘TextValue’, 12345)») ).

Cloning a MySQL database on the same MySql instance

I would like to write a script which copies my current database sitedb1 to sitedb2 on the same mysql database instance. I know I can dump the sitedb1 to a sql script:

and then import it to sitedb2 . Is there an easier way, without dumping the first database to a sql file?

14 Answers 14

As the manual says in Copying Databases you can pipe the dump directly into the mysql client:

If you’re using MyISAM you could copy the files, but I wouldn’t recommend it. It’s a bit dodgy.

Integrated from various good other answers

Both mysqldump and mysql commands accept options for setting connection details (and much more), like:

Also, if the new database is not existing yet, you have to create it beforehand (e.g. with echo «create database new_db_name» | mysql -u -p ).

Using MySQL Utilities

The MySQL Utilities contain the nice tool mysqldbcopy which by default copies a DB including all related objects (“tables, views, triggers, events, procedures, functions, and database-level grants”) and data from one DB server to the same or to another DB server. There are lots of options available to customize what is actually copied.

So, to answer the OP’s question:

You need to run the command from terminal / command prompt.

e.g: mysqldump -u root test_db1 | mysql -u root test_db2

This copies test_db1 to test_db2 and grant the access to ‘root’@’localhost’

Best and easy way is to enter these commands in your terminal and set permissions to the root user. Works for me.

db_name | mysql -u -p

new_db_name can be problematic with large databases. – Alex Feb 14 ’18 at 11:32

You could use (in pseudocode):

The reason I’m not using the CREATE TABLE . SELECT . syntax is to preserve indices. Of course this only copies tables. Views and procedures are not copied, although it can be done in the same manner.

First create the duplicate database:

Make sure the permissions etc are all in place and:

You can do something like the following:

This statement was added in MySQL 5.1.7 but was found to be dangerous and was removed in MySQL 5.1.23. It was intended to enable upgrading pre-5.1 databases to use the encoding implemented in 5.1 for mapping database names to database directory names. However, use of this statement could result in loss of database contents, which is why it was removed. Do not use RENAME DATABASE in earlier versions in which it is present.

To perform the task of upgrading database names with the new encoding, use ALTER DATABASE db_name UPGRADE DATA DIRECTORY NAME instead: http://dev.mysql.com/doc/refman/5.1/en/alter-database.html

A simple way to do so if you installed phpmyadmin:

Go to your database, select «operation» tab, and you can see the «copy database to» block. Use it and you can copy the database.

In addition to Greg’s answer, this is the easiest and fastest way if the new_db_name doesn’t yet exist:

If you have triggers in your original database, you can avoid the «Trigger already exists» error by piping a replacement before the import:

As mentioned in Greg’s answer, mysqldump db_name | mysql new_db_name is the free, safe, and easy way to transfer data between databases. However, it’s also really slow.

If you’re looking to backup data, can’t afford to lose data (in this or other databases), or are using tables other than innodb , then you should use mysqldump .

If you’re looking for something for development, have all of your databases backed up elsewhere, and are comfortable purging and reinstalling mysql (possibly manually) when everything goes wrong, then I might just have the solution for you.

I couldn’t find a good alternative, so I built a script to do it myself. I spent a lot of time getting this to work the first time and it honestly terrifies me a little to make changes to it now. Innodb databases were not meant to copied and pasted like this. Small changes cause this to fail in magnificent ways. I haven’t had a problem since I finalized the code, but that doesn’t mean you won’t.

Systems tested on (but may still fail on):

  • Ubuntu 16.04, default mysql, innodb, separate files per table
  • Ubuntu 18.04, default mysql, innodb, separate files per table

What it does

  1. Gets sudo privilege and verifies you have enough storage space to clone the database
  2. Gets root mysql privileges
  3. Creates a new database named after the current git branch
  4. Clones structure to new database
  5. Switches into recovery mode for innodb
  6. Deletes default data in new database
  7. Stops mysql
  8. Clones data to new database
  9. Starts mysql
  10. Links imported data in new database
  11. Switches out of recovery mode for innodb
  12. Restarts mysql
  13. Gives mysql user access to database
  14. Cleans up temporary files

How it compares with mysqldump

On a 3gb database, using mysqldump and mysql would take 40-50 minutes on my machine. Using this method, the same process would only take

How we use it

We have our SQL changes saved alongside our code and the upgrade process is automated on both production and development, with each set of changes making a backup of the database to restore if there’s errors. One problem we ran into was when we were working on a long term project with database changes, and had to switch branches in the middle of it to fix a bug or three.

In the past, we used a single database for all branches, and would have to rebuild the database whenever we switched to a branch that wasn’t compatible with the new database changes. And when we switched back, we’d have to run the upgrades again.

We tried mysqldump to duplicate the database for different branches, but the wait time was too long (40-50 minutes), and we couldn’t do anything else in the meantime.

This solution shortened the database clone time to 1/5 the time (think coffee and bathroom break instead of a long lunch).

Common tasks and their time

Switching between branches with incompatible database changes takes 50+ minutes on a single database, but no time at all after the initial setup time with mysqldump or this code. This code just happens to be

5 times faster than mysqldump .

Here are some common tasks and roughly how long they would take with each method:

Create feature branch with database changes and merge immediately:

  • Single database:

5 minutes

  • Clone with mysqldump : 50-60 minutes
  • Clone with this code:

    Create feature branch with database changes, switch to master for a bugfix, make an edit on the feature branch, and merge:

    • Single database:

    60 minutes

  • Clone with mysqldump : 50-60 minutes
  • Clone with this code:

    Create feature branch with database changes, switch to master for a bugfix 5 times while making edits on the feature branch inbetween, and merge:

    • Single database:

    4 hours, 40 minutes

  • Clone with mysqldump : 50-60 minutes
  • Clone with this code:

    The code

    Do not use this unless you’ve read and understood everything above.

    If everything goes smoothly, you should see something like:

    MySQLdb User’s Gu >

    MySQLdb is an thread-compatible interface to the popular MySQL database server that provides the Python database API.

    The README file has complete installation instructions.

    If you want to write applications which are portable across databases, use MySQLdb, and avo > _mysql provides an interface which mostly implements the MySQL C API. For more information, see the MySQL documentation. The documentation for this module is intentionally weak because you probably should use the higher-level MySQLdb module. If you really need it, use the standard MySQL docs and transliterate as necessary.

    MySQL C API translation

    The MySQL C API has been wrapped in an object-oriented way. The only MySQL data structures which are implemented are the MYSQL (database connection handle) and MYSQL_RES (result handle) types. In general, any function which takes MYSQL *mysql as an argument is now a method of the connection object, and any function which takes MYSQL_RES *result as an argument is a method of the result object. Functions requiring none of the MySQL data structures are implemented as functions in the module. Functions requiring one of the other MySQL data structures are generally not implemented. Deprecated functions are not implemented. In all cases, the mysql_ prefix is dropped from the name. Most of the conn methods listed are also available as MySQLdb Connection object methods. Their use is non-portable.


    MySQL C API function mapping

    C API _mysql
    mysql_affected_rows() conn.affected_rows()
    mysql_autocommit() conn.autocommit()
    mysql_character_set_name() conn.character_set_name()
    mysql_close() conn.close()
    mysql_commit() conn.commit()
    mysql_connect() _mysql.connect()
    mysql_data_seek() result.data_seek()
    mysql_debug() _mysql.debug()
    mysql_dump_debug_info conn.dump_debug_info()
    mysql_escape_string() _mysql.escape_string()
    mysql_fetch_row() result.fetch_row()
    mysql_get_character_set_info() conn.get_character_set_info()
    mysql_get_client_info() _mysql.get_client_info()
    mysql_get_host_info() conn.get_host_info()
    mysql_get_proto_info() conn.get_proto_info()
    mysql_get_server_info() conn.get_server_info()
    mysql_info() conn.info()
    mysql_insert_id() conn.insert_id()
    mysql_num_fields() result.num_fields()
    mysql_num_rows() result.num_rows()
    mysql_options() various options to _mysql.connect()
    mysql_ping() conn.ping()
    mysql_query() conn.query()
    mysql_real_connect() _mysql.connect()
    mysql_real_query() conn.query()
    mysql_real_escape_string() conn.escape_string()
    mysql_rollback() conn.rollback()
    mysql_row_seek() result.row_seek()
    mysql_row_tell() result.row_tell()
    mysql_select_db() conn.select_db()
    mysql_set_character_set() conn.set_character_set()
    mysql_ssl_set() ssl option to _mysql.connect()
    mysql_stat() conn.stat()
    mysql_store_result() conn.store_result()
    mysql_thread_id() conn.thread_id()
    mysql_thread_safe_client() conn.thread_safe_client()
    mysql_use_result() conn.use_result()
    mysql_warning_count() conn.warning_count()
    CLIENT_* MySQLdb.constants.CLIENT.*
    CR_* MySQLdb.constants.CR.*
    ER_* MySQLdb.constants.ER.*
    FIELD_TYPE_* MySQLdb.constants.FIELD_TYPE.*
    FLAG_* MySQLdb.constants.FLAG.*

    Some _mysql examples

    Okay, so you want to use _mysql anyway. Here are some examples.

    The simplest possible database connection is:

    This creates a connection to the MySQL server running on the local machine using the standard UNIX socket (or named pipe on Windows), your login name (from the USER environment variable), no password, and does not USE a database. Chances are you need to supply more information.:

    This creates a connection to the MySQL server running on the local machine via a UNIX socket (or named pipe), the user name «joebob», the password «moonpie», and selects the initial database «thangs».

    We haven’t even begun to touch upon all the parameters connect() can take. For this reason, I prefer to use keyword parameters:

    This does exactly what the last example did, but is arguably easier to read. But since the default host is «localhost», and if your login name really was «joebob», you could shorten it to this:

    UNIX sockets and named pipes don’t work over a network, so if you specify a host other than localhost, TCP will be used, and you can specify an odd port if you need to (the default port is 3306):

    If you really had to, you could connect to the local host with TCP by specifying the full host name, or 127.0.0.1.

    Generally speaking, putting passwords in your code is not such a good idea:

    This does what the previous example does, but gets the username and password and other parameters from

    /.my.cnf (UNIX-like systems). Read about option files for more details.

    So now you have an open connection as db and want to do a query. Well, there are no cursors in MySQL, and no parameter substitution, so you have to pass a complete query string to db.query() :

    There’s no return value from this, but exceptions can be raised. The exceptions are defined in a separate module, _mysql_exceptions , but _mysql exports them. Read DB API specification PEP-249 to find out what they are, or you can use the catch-all MySQLError .

    At this point your query has been executed and you need to get the results. You have two options:

    Both methods return a result object. What’s the difference? store_result() returns the entire result set to the client immediately. If your result set is really large, this could be a problem. One way around this is to add a LIMIT clause to your query, to limit the number of rows returned. The other is to use use_result() , which keeps the result set in the server and sends it row-by-row when you fetch. This does, however, tie up server resources, and it ties up the connection: You cannot do any more queries until you have fetched all the rows. Generally I recommend using store_result() unless your result set is really huge and you can’t use LIMIT for some reason.

    Now, for actually getting real results:

    This might look a little odd. The first thing you should know is, fetch_row() takes some additional parameters. The first one is, how many rows ( maxrows ) should be returned. By default, it returns one row. It may return fewer rows than you asked for, but never more. If you set maxrows=0 , it returns all rows of the result set. If you ever get an empty tuple back, you ran out of rows.

    The second parameter ( how ) tells it how the row should be represented. By default, it is zero which means, return as a tuple. how=1 means, return it as a dictionary, where the keys are the column names, or table.column if there are two columns with the same name (say, from a join). how=2 means the same as how=1 except that the keys are always table.column ; this is for compatibility with the old Mysqldb module.

    OK, so why d > maxrows .

    The other oddity is: Assuming these are numeric columns, why are they returned as strings? Because MySQL returns all data as strings and expects you to convert it yourself. This would be a real pain in the ass, but in fact, _mysql can do this for you. (And MySQLdb does do this for you.) To have automatic type conversion done, you need to create a type converter dictionary, and pass this to connect() as the conv keyword parameter.

    The keys of conv should be MySQL column types, which in the C API are FIELD_TYPE_* . You can get these values like this:

    By default, any column type that can’t be found in conv is returned as a string, which works for a lot of stuff. For our purposes, we probably want this:

    This means, if it’s a FIELD_TYPE_LONG , call the builtin int() function on it. Note that FIELD_TYPE_LONG is an INTEGER column, which corresponds to a C long , which is also the type used for a normal Python integer. But beware: If it’s really an UNSIGNED INTEGER column, this could cause overflows. For this reason, MySQLdb actually uses long() to do the conversion. But we’ll ignore this potential problem for now.

    Then if you use db=_mysql.connect(conv=my_conv. ) , the results will come back ((3, 2, 0),) , which is what you would expect.

    MySQLdb

    MySQLdb is a thin Python wrapper around _mysql which makes it compatible with the Python DB API interface (version 2). In reality, a fair amount of the code which implements the API is in _mysql for the sake of efficiency.

    The DB API specification PEP-249 should be your primary guide for using this module. Only deviations from the spec and other database-dependent things will be documented here.

    Functions and attributes

    Only a few top-level functions and attributes are defined within MySQLdb.

    Constructor for creating a connection to the database. Returns a Connection Object. Parameters are the same as for the MySQL C API. In addition, there are a few additional keywords that correspond to what you would pass mysql_options() before connecting. Note that some parameters must be specified as keyword arguments! The default value for each parameter is NULL or zero, as appropriate. Consult the MySQL documentation for more details. The important parameters are:

    host name of host to connect to. Default: use the local host via a UNIX socket (where applicable) user user to authenticate as. Default: current effective user. passwd password to authenticate with. Default: no password. db database to use. Default: no default database. port TCP port of MySQL server. Default: standard port (3306). unix_socket location of UNIX socket. Default: use default location or TCP for remote hosts. conv type conversion dictionary. Default: a copy of MySQLdb.converters.conversions compress Enable protocol compression. Default: no compression. connect_timeout Abort if connect is not completed within given number of seconds. Default: no timeout (?) named_pipe Use a named pipe (Windows). Default: don’t. init_command Initial command to issue to server upon connection. Default: Nothing. read_default_file MySQL configuration file to read; see the MySQL documentation for mysql_options() . read_default_group Default group to read; see the MySQL documentation for mysql_options() . cursorclass cursor > cursor() uses, unless overr > MySQLdb.cursors.Cursor . This must be a keyword parameter. use_unicode

    If True, CHAR and VARCHAR and TEXT columns are returned as Unicode strings, using the configured character set. It is best to set the default encoding in the server configuration, or client configuration (read with read_default_file). If you change the character set after connecting (MySQL-4.1 and later), you’ll need to put the correct character set name in connection.charset.

    If False, text-like columns are returned as normal strings, but you can always write Unicode strings.

    This must be a keyword parameter.

    If present, the connection character set will be changed to this character set, if they are not equal. Support for changing the character set requires MySQL-4.1 and later server; if the server is too old, UnsupportedError will be raised. This option implies use_unicode=True, but you can overr >

    If not present, the default character set is used.

    This must be a keyword parameter.

    If present, the session SQL mode will be set to the given string. For more information on sql_mode, see the MySQL documentation. Only available for 4.1 and newer servers.

    If not present, the session SQL mode will be unchanged.

    This must be a keyword parameter.

    ssl This parameter takes a dictionary or mapping, where the keys are parameter names used by the mysql_ssl_set MySQL C API call. If this is set, it initiates an SSL connection to the server; if there is no SSL support in the client, an exception is raised. This must be a keyword parameter. apilevel String constant stating the supported DB API level. ‘2.0’ threadsafety

    Integer constant stating the level of thread safety the interface supports. This is set to 1, which means: Threads may share the module.

    The MySQL protocol can not handle multiple threads using the same connection at once. Some earlier versions of MySQLdb utilized locking to achieve a threadsafety of 2. While this is not terribly hard to accomplish using the standard Cursor > mysql_store_result() ), it is complicated by SSCursor (which uses mysql_use_result() ; with the latter you must ensure all the rows have been read before another query can be executed. It is further complicated by the addition of transactions, since transactions start when a cursor execute a query, but end when COMMIT or ROLLBACK is executed by the Connection object. Two threads simply cannot share a connection while a transaction is in progress, in addition to not being able to share it during query execution. This excessively complicated the code to the point where it just isn’t worth it.

    The general upshot of this is: Don’t share connections between threads. It’s really not worth your effort or mine, and in the end, will probably hurt performance, since the MySQL server runs a separate thread for each connection. You can certainly do things like cache connections in a pool, and give those connections to one thread at a time. If you let two threads use a connection simultaneously, the MySQL client library will probably upchuck and die. You have been warned.

    For threaded applications, try using a connection pool. This can be done using the Pool module.

    charset The character set used by the connection. In MySQL-4.1 and newer, it is possible (but not recommended) to change the connection’s character set with an SQL statement. If you do this, you’ll also need to change this attribute. Otherwise, you’ll get encoding errors. paramstyle

    String constant stating the type of parameter marker formatting expected by the interface. Set to ‘format’ = ANSI C printf format codes, e.g. ‘. WHERE name=%s’. If a mapping object is used for conn.execute(), then the interface actually uses ‘pyformat’ = Python extended format codes, e.g. ‘. WHERE name=%(name)s’. However, the API does not presently allow the specification of more than one style in paramstyle.

    Note that any literal percent signs in the query string passed to execute() must be escaped, i.e. %%.

    Parameter placeholders can only be used to insert column values. They can not be used for other parts of SQL, such as table names, statements, etc.

    A dictionary or mapping which controls how types are converted from MySQL to Python and vice versa.

    If the key is a MySQL type (from FIELD_TYPE.* ), then the value can be either:

    • a callable object which takes a string argument (the MySQL value),’ returning a Python value
    • a sequence of 2-tuples, where the first value is a combination of flags from MySQLdb.constants.FLAG , and the second value is a function as above. The sequence is tested until the flags on the field match those of the first value. If both values are None, then the default conversion is done. Presently this is only used to distinquish TEXT and BLOB columns.

    If the key is a Python type or class, then the value is a callable Python object (usually a function) taking two arguments (value to convert, and the conversion dictionary) which converts values of this type to a SQL literal string value.

    This is initialized with reasonable defaults for most types. When creating a Connection object, you can pass your own type converter dictionary as a keyword parameter. Otherwise, it uses a copy of MySQLdb.converters.conversions . Several non-standard types are returned as strings, which is how MySQL returns all columns. For more details, see the built-in module documentation.

    Connection Objects

    Connection objects are returned by the connect() function.

    commit() If the database and the tables support transactions, this commits the current transaction; otherwise this method successfully does nothing. rollback() If the database and tables support transactions, this rolls back (cancels) the current transaction; otherwise a NotSupportedError is raised. cursor([cursorclass]) MySQL does not support cursors; however, cursors are easily emulated. You can supply an alternative cursor > Cursor class. Also see the additional supplied cursor classes in the usage section.

    There are many more methods defined on the connection object which are MySQL-specific. For more information on them, consult the internal documentation using pydoc .

    Cursor Objects

    Calls stored procedure procname with the sequence of arguments in args. Returns the original arguments. Stored procedure support only works with MySQL-5.0 and newer.

    Compatibility note: PEP-249 specifies that if there are OUT or INOUT parameters, the modified values are to be returned. This is not consistently possible with MySQL. Stored procedure arguments must be passed as server variables, and can only be returned with a SELECT statement. Since a stored procedure may return zero or more result sets, it is impossible for MySQLdb to determine if there are result sets to fetch before the modified parmeters are accessible.

    The parameters are stored in the server as @_*procname*_*n*, where n is the position of the parameter. I.e., if you cursor.callproc(‘foo’, (a, b, c)), the parameters will be accessible by a SELECT statement as @_foo_0, @_foo_1, and @_foo_2.

    Compatibility note: It appears that the mere act of executing the CALL statement produces an empty result set, which appears after any result sets which might be generated by the stored procedure. Thus, you will always need to use nextset() to advance result sets.

    close() Closes the cursor. Future operations raise ProgrammingError . If you are using server-side cursors, it is very important to close the cursor when you are done with it and before creating a new one. info() Returns some information about the last query. Normally you don’t need to check this. If there are any MySQL warnings, it will cause a Warning to be issued through the Python warning module. By default, Warning causes a message to appear on the console. However, it is possible to filter these out or cause Warning to be raised as exception. See the MySQL docs for mysql_info() , and the Python warning module. (Non-standard) setinputsizes() Does nothing, successfully. setoutputsizes() Does nothing, successfully. nextset()

    Advances the cursor to the next result set, discarding the remaining rows in the current result set. If there are no additional result sets, it returns None; otherwise it returns a true value.

    Note that MySQL doesn’t support multiple result sets until 4.1.

    Some examples

    The connect() method works nearly the same as with _mysql:

    To perform a query, you first need a cursor, and then you can execute queries on it:

    In this example, max_price=5 Why, then, use %s in the string? Because MySQLdb will convert it to a SQL literal value, which is the string ‘5’. When it’s finished, the query will actually say, «. WHERE price _mysql example, this returns a single tuple, which is the row, and the values are properly converted by default. except. What’s with the L’s?

    As mentioned earlier, while MySQL’s INTEGER column translates perfectly into a Python integer, UNSIGNED INTEGER could overflow, so these values are converted to Python long integers instead.

    If you wanted more rows, you could use c.fetchmany(n) or c.fetchall() . These do exactly what you think they do. On c.fetchmany(n) , the n is optional and defaults to c.arraysize , which is normally 1. Both of these methods return a sequence of rows, or an empty sequence if there are no more rows. If you use a weird cursor class, the rows themselves might not be tuples.

    Note that in contrast to the above, c.fetchone() returns None when there are no more rows to fetch.

    The only other method you are very likely to use is when you have to do a multi-row insert:

    Here we are inserting three rows of five values. Notice that there is a mix of types (strings, ints, floats) though we still only use %s . And also note that we only included format strings for one row. MySQLdb picks those out and duplicates them for each row.

    Using and extending

    In general, it is probably wise to not directly interact with the DB API except for small applicatons. Databases, even SQL databases, vary w > connect() are completely implementation-dependent.

    If you believe your application may need to run on several different databases, the author recommends the following approach, based on personal experience: Write a simplified API for your application which implements the specific queries and operations your application needs to perform. Implement this API as a base class which should be have few database dependencies, and then derive a subclass from this which implements the necessary dependencies. In this way, porting your application to a new database should be a relatively simple matter of creating a new subclass, assuming the new database is reasonably standard.

    Because MySQLdb’s Connection and Cursor objects are written in Python, you can easily derive your own subclasses. There are several Cursor classes in MySQLdb.cursors:

    BaseCursor The base class for Cursor objects. This does not raise Warnings. CursorStoreResultMixIn Causes the Cursor to use the mysql_store_result() function to get the query result. The entire result set is stored on the client side. CursorUseResultMixIn Causes the cursor to use the mysql_use_result() function to get the query result. The result set is stored on the server side and is transferred row by row using fetch operations. CursorTupleRowsMixIn Causes the cursor to return rows as a tuple of the column values.

    Causes the cursor to return rows as a dictionary, where the keys are column names and the values are column values. Note that if the column names are not unique, i.e., you are selecting from two tables that share column names, some of them will be rewritten as table.column . This can be avo > AS keyword. (This is yet-another reason not to use * in SQL queries, particularly where JOIN is involved.)

    Embedded Server

    Instead of connecting to a stand-alone server over the network, the embedded server support lets you run a full server right in your Python code or application server.

    If you have built MySQLdb with embedded server support, there are two additional functions you will need to make use of:

    Initialize embedded server. If this client is not linked against the embedded server library, this function does nothing.

    args sequence of command-line arguments groups sequence of groups to use in defaults files server_end() Shut down embedded server. If not using an embedded server, this does nothing.

    See the MySQL documentation for more information on the embedded server.

    EAX_Mysql — MySQL library — библиотека для MetaTrader 5

    Я случайно столкнулся с языком программирования MQL5 и был вынужден использовать в нем базу данных MySQL. Как и для любой библиотеки, я надеюсь, что примеры продемонстрируют как можно ее использовать. Самым важным и актуальным для любой библиотеки являются примеры ее использования ;)

    Примеры:

    Взаимодействие с данными:

    Установка:

    • Откройте MQL5 директорию, в которой хранятся данные.
    • Загрузите Connector/C (libmysql) нужной разрядности (32 или 64 бит) и поместите файл libymsql.dll в папку «MQL5\Libraries».
    • Создайте папку EAX внутри папки Include.
    • Поместите EAX_Mysql.mqh в папку «MQL5\Include\EAX».

    Проблемы:

    • Так как внутри кода используется общий указатель соединения, то библиотека не может обрабатывать более одного подключения к БД одновременно (у меня не было необходимости в добавлении/перемещении пулов соединения).
    • Нет реальной обработки ошибок (MySQL), сбрасывание соединения с БД.
    • Нет обработки ошибок, переподключения к БД.
    • Нет поддержки использования нескольких столбцов первичных ключей.
    • Это бета-версия — пожалуйста напишите мне по электронной почте если вы хотите протестировать ее.
    • Не обрабатываются типы данных (внутри только строки). Решение можно поискать в CodeBase.
    • Соединение базы данных осуществляется при помощи стандарта ISO — слишком ленив чтобы настроить арифметику указателей/строк для UTF-8.

    Mysql библиотека отладчика mysql

    Для тех кто хочет обменяться ссылками, стучите 353521939

    Библиотека отладчика MySQL

    Библиотека отладчика, используемая MySQL была первоначально написана Фредом Фишом (Fred Fish). Она будет очень полезна, если Вы планируете отлаживать и/или добавлять функциональные возможности к СУБД MySQL.

    Автор зачем-то приводит заголовок файла dbug.c из исходников пакета (вместе со всеми комментариями к нему). Приведу его и я, поскольку это может быть продиктовано какими-либо юридическими проблемами с копирайтом. Поскольку я не юрист, привожу этот заголовок без какого-либо перевода (во избежание ошибок или искажения смысла юридического документа при переводе).

    Функции библиотеки отладчика

    _db_push_

    Поместить в стек текущее состояние отладчика, и установить новое.

    СИНТАКСИС: VOID _db_push_ (control) char *control;

    По указателю в параметре «control» на строку управления отладкой помещает в стек текущее состояние отладки, анализирует строку управления и устанавливает новое состояние отладки.

    Единственный атрибут нового состояния, унаследованного из предыдущего состояния, это текущая функция вложенного уровня. Это может быть отменено, используя флажок «r» в строке управления.

    Строка управления отладкой является последовательностью полей, разделенных двоеточиями:

    Каждое поле состоит из обязательного символа флажка отладки, сопровождаемого факультативным «,» и списком параметров, разделенных запятыми:

    Символы флажка отладки:

    d Разрешает вывод из макроса DBUG_ для текущего состояния. Может сопровождаться списком ключевых слов, который разрешает вывод только для DBUG макрокоманд с соответствующим ключевым словом. Пустой список ключевых слов подразумевает вывод для всех макрокоманд.
    D Ждать после каждой выведенной отладчиком строки. Аргумент задает число десятых долей секунды, которое нужно ждать. Например, -#D,20 задает паузу в 2 секунды.
    f Ограничивает отладку и/или трассировку списком имен функций. Обратите внимание, что пустой список отключит все функции. Соответствующий флажок «d» или «t» должен все же быть дан, поскольку этот флажок только ограничивает их действие, если они включены.
    F Идентифицируют имя исходного файла для каждой строки отладки или трассирует вывод.
    i Идентифицируют процесс с pid для каждой строки отладки или трассирует вывод.
    g Включить профилирование. Создайте файл ‘dbugmon.out’, содержащий информацию, которая может использоваться, чтобы профилировать программу. Может сопровождаться списком ключевых слов, которые выбирают профилирование только для функций в этом списке. Пустой список подразумевает, что все функции подлежат профилированию.
    L Идентифицирует номер строки исходного файла для каждой строки отладки или трассирует вывод.
    n Выводит текущую глубину вложенности функции для каждой строки отладки или трассирует вывод.
    N Номер каждой строки вывода отладки.
    o Переназначает выходной поток отладчика в файл. По умолчанию задан stderr.
    O То же, что и o, но файл сбрасывается между записями. То есть, после каждой записи файл закрывается, и снова открывается только перед следующей записью. Тормозит, конечно, кошмарно, но зато гарантирует сохранность данных в этом файле на случай слета системы. Что при отладке не бесполезно.
    p Ограничивает действия отладчика определенными процессами. Процесс должен быть указан в макросе DBUG_PROCESS и совпадать с одной из записей в списке действий отладчика.
    P Выводит имя текущего процесса для каждой строки отладки или трассирует вывод.
    r При установке нового состояния отладки не наследует предыдущее состояние вложенности функции. Полезно, когда вывод должен начаться в левом поле.
    S Функция _sanity(_file_, _line_) для каждой отлаживаемой функции до _sanity() возвращает отличное от 0 значение. Обычно используется с safemalloc. Как задается это значение, и что оно вообще значит в документации не сказано (. ), а опытным путем это установить не удалось.
    t Включить функцию трассировки строк вызова и выхода (call/exit). Может сопровождаться списком, содержащим число номер максимального уровня трассировки, вне которого никакого вывода не произойдет для отладочных или трассировочных макрокоманд. Умолчание задается при компиляции.

    Некоторые примеры строк управления отладкой:

    _db_pop_

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

    _db_enter_

    Вызывается в начале каждой функции пользователя, чтобы сообщить отладчику, что была введена новая функция. Обратите внимание, что указатели на предыдущее имя функции пользователя и предыдущее имя файла пользователя сохраняются в стеке вызовов (это причина того, почему макрокоманда ENTER должна быть первым «выполнимым» кодом в функции, так как она распределяет память для этой области. Предыдущий уровень вложения также сохраняется в стеке вызовов для внутренней самопроверки непротиворечивости.

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

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

    _db_return_

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

    _db_pargs_

    Параметры файла протокола для последующего использования _db_doprnt_().

    Новая универсальная макрокоманда печати DBUG_PRINT, которая заменяет все формы макрокоманд DBUG_N, нуждается в двух обращениях к подпрограммам поддержки во время выполнения. Первая, это функция, которая запоминает параметры, которые используются последующим обращением для _db_doprnt_().

    _db_doprnt_

    Печать дескриптора строк отладки.

    Когда вызывается через одну из DBUG макрокоманд, проверяет текущий набор ключевых слов, вызывая _db_pargs_() чтобы узнать, была ли эта макрокоманда выбрана для обработки через строку управления отладчика, и если так, печатает аргументы с помощью форматированной строки. Номер строки DBUG макрокоманды в источнике найден в u_line.

    Обратите внимание, что строка формата (format) НЕ ДОЛЖНА включить завершение строки (n), это делается автоматически.

    _db_dump_

    Выполняет дамп строки, пока не найдет ‘

    Разместил : Vulko
    Опубликовано : 15.02.2004
    Статья «MySql — Библиотека отладчика MySQL» прочтена 7956 раз .

    Илон Маск рекомендует:  deg в CSS
  • Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL