Форум пользователей MySQL

Существуют два вида переменных: пользовательские переменные
и переменные хранимого кода.

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

mysql> SET @var=123;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @var;
+------+
| @var |
+------+
| 123  |
+------+
1 row in set (0.00 sec)

Переменные хранимого кода же напротив - имеют ограниченную
область видимости. Они должны объявляться в хранимом коде и
имеют совершенно определенный тип данных:

mysql> \d ;;
mysql> CREATE PROCEDURE proc ()
    -> BEGIN
    ->   DECLARE pvar INT;
    ->   SET pvar = 2;
    ->   SELECT pvar;
    -> END;;
Query OK, 0 rows affected (0.15 sec)

mysql> \d ;
mysql> CALL proc ();
+------+
| pvar |
+------+
|    2 |
+------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT pvar;
ERROR 1054 (42S22): Unknown column 'pvar' in 'field list'

Да, к сожалению, в случае PREPARE Вам не удастся не использовать
глобальные переменные. И дело тут даже не столько в длине строки,
сколько в том, что PREPARE может работать только с глобальными переменными
(ну или с чистой строкой, разумеется).

Если Вам нужен лог запросов - включите general query log. Только учтите,
что на загруженных серверах это очень быстро приводит к огромным логам.

Если Вам нужен лог изменений - включите binary log. В случае 5.0, сервер пишет
запросы, изменяющие данные. В случае 5.1, Вам необходимо это в явном виде
указать (иначе он может писать реальные изменения, а не запросы).

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

В начале процедуры Вы можете поставить выражение типа

INSERT INTO logdb.logtable (`query`)
SELECT ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA='dbname' AND ROUTINE_NAME='procname';

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

paulus написал:

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

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

Отредактированно Golova (27.03.2007 02:44:10)

Да, их, по-видимому, прийдется создать несколько - в стеке.

Если Вы программировали когда-нибудь на ассемблере - Вы должны
помнить, как там организуется память при входе в процедуры. Обычно
при входе Вы делаете pusha, что проталкивает значение всех регистров
процессора в стек, а при выходе - popa, что возвращает значения.

Точно так же можно сделать и тут - создать кучку переменных
локальных, в них сохранить значения всех используемых в процедуре
глобальных переменных до входа в процедуру, а потом восстановить их
значения перед выходом из нее. Это касается как @query, так и @log_count.

Ну, если Вы их используете 5-6 штук, то не накладно (даже если они по 100кбайт каждая).
Если Вы используете их 100+, то Вам стоит написать собственное расширение для сервера
(которое будет записывать в файл то, что выполняют процедуры), т.к. при таком количестве
переменных, код будет выполняться действительно долго.

Смысл в том, что Вам нужно сохранять не все переменные, а только те, которые изменяет Ваша
процедура. Остальные, разумеется, останутся неизменными и на выходе из нее. А процедура
обычно изменяет 1-2...

Если будете садиться за код - советую сделать патч, чтобы PREPARE работал с локальными
переменными - это будет куда полезнее и Вам, и сообществу вцелом.

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

Ну а разные сессии будут иметь разные @query.

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

1. Мне присылают дамп бд сделанный обычным способом.
2. но в результате каких то перверсий - точно не известно - дамп получается не простой а с вложенными DECLARE
3. мне необходимо из этого дампа забрать четыре таблицы и перенаправить их в другую базу.
4. Я делаю дамп этих четырех таблиц обычным mysqldump -t basa tb1 tb2 tb3 tb4 > c:/basa4.sql
5. В этом дампе опять оказывается DECLARE
6. Когда пытаюсь положить этот дамп четырех таблиц в нужную мне БД то выдает:
ERROR 1304 (42000): FUNCTION join_period already exists
7. если пытаюсь вручную почистить созданный дамп от DECLARE, то заливает, но неизвестно всю ли информацию и как правильно.

Вопрос - как сделать дамп без DECLARE - возможно ли это ?
ключи дампа просмотрел - вроде невозможною
на моей машине mysql стоит 5.0, могу поставить 5.5 - если необходимо.
на конечный (mysql  Ver 14.12 Distrib 5.0.45,) и начальный источник повлиять не могу.

Просидел весь день в инете с этой проблемой, но как новичок в mysql и со слабым английским - слаборезультативно.
=
Буду рад хотя бы более полной инфе о DECLARE - можно ли ее безболезненно удалять вручную из дампа, к примеру.

Отредактированно Joy_25 (02.07.2012 18:48:22)

Спасибо за совет - копирование потаблично помогло убрать DECLARE
==
распишу вашу запись чуть подробнее для других гостей вашего форума:

MySql скопировать таблицу из одной базы в другую

CREATE TABLE db2.table LIKE db1.table;
INSERT INTO db2.table SELECT * FROM db1.table;