Да. MySQL поддерживает два типа хранимых подпрограмм: хранимые процедуры и хранимые функции.

Смотрите Раздел 27.2, «Использование хранимых подпрограмм».

Да. Смотрите https://forums.mysql.com/list.php?98.

К сожалению, официальные спецификации не доступны бесплатно (ANSI предоставляет их для покупки). Однако существуют книги, такие как SQL-99 Complete, Really Питера Гулуцана и Труди Пельцер, которые предоставляют всесторонний обзор стандарта, включая описание хранимых процедур.

Всегда рекомендуется использовать четкую схему именования для ваших хранимых подпрограмм. Вы можете управлять хранимыми процедурами с помощью CREATE [FUNCTION|PROCEDURE], ALTER [FUNCTION|PROCEDURE], DROP [FUNCTION|PROCEDURE] и SHOW CREATE [FUNCTION|PROCEDURE]. Вы можете получить информацию о существующих хранимых процедурах, используя таблицу ROUTINES в базе данных INFORMATION_SCHEMA (см. Раздел 28.3.30, «Таблица INFORMATION_SCHEMA ROUTINES»).

Да. Для базы данных с именем dbname используйте этот запрос к таблице INFORMATION_SCHEMA.ROUTINES:

SELECT ROUTINE_TYPE, ROUTINE_NAME
    FROM INFORMATION_SCHEMA.ROUTINES
    WHERE ROUTINE_SCHEMA='dbname';

Для получения дополнительной информации см. Раздел 28.3.30, «Таблица INFORMATION_SCHEMA ROUTINES».

Тело хранимой подпрограммы можно просмотреть с помощью SHOW CREATE FUNCTION (для хранимой функции) или SHOW CREATE PROCEDURE (для хранимой процедуры). См. Раздел 15.7.7.10, «Инструкция SHOW CREATE PROCEDURE», для получения дополнительной информации.

Хранимые процедуры хранятся в таблицах mysql.routines и mysql.parameters, которые являются частью словаря данных. Вы не можете напрямую обращаться к этим таблицам. Вместо этого запросите таблицы INFORMATION_SCHEMA ROUTINES и PARAMETERS. См. Раздел 28.3.30, «Таблица INFORMATION_SCHEMA ROUTINES», и Раздел 28.3.20, «Таблица INFORMATION_SCHEMA PARAMETERS».

Вы также можете использовать SHOW CREATE FUNCTION для получения информации о хранимых функциях и SHOW CREATE PROCEDURE для получения информации о хранимых процедурах. См. Раздел 15.7.7.10, «Инструкция SHOW CREATE PROCEDURE».

Нет. Это не поддерживается в MySQL.

Да.

Хранимая процедура может выполнить оператор SQL, например, UPDATE, который приводит к активации триггера.

Да. Хранимая процедура может обращаться к одной или нескольким таблицам по мере необходимости.

Да. MySQL реализует операторы стандарта SQL SIGNAL и RESIGNAL. Смотрите Раздел 15.6.7, «Обработка условий».

MySQL реализует определения HANDLER в соответствии со стандартом SQL. Подробности см. в Разделе 15.6.7.2, «Оператор DECLARE ... HANDLER».

Хранимые процедуры могут, но хранимые функции — нет. Если вы выполняете обычный SELECT внутри хранимой процедуры, результирующий набор возвращается клиенту напрямую. Для этого вам необходимо использовать протокол клиент/сервер MySQL 4.1 (или выше). Это означает, что, например, в PHP вам нужно использовать расширение mysqli, а не старое расширение mysql.

Нет.

В MySQL нет эквивалента.

Нет.

Курсоры доступны только внутри хранимых процедур.

Курсоры доступны только внутри хранимых процедур. Однако, если вы не открываете курсор на SELECT, результат отправляется напрямую клиенту. Вы также можете SELECT INTO переменные. См. Раздел 15.2.13, «Оператор SELECT».

Да, вы можете сделать это в сохраненной процедуре, но не в сохраненной функции. Если вы выполните обычное SELECT внутри сохраненной процедуры, набор результатов будет возвращен непосредственно клиенту. Для этого необходимо использовать протокол клиента/сервера MySQL 4.1 (или выше). Это означает, что, например, в PHP вам нужно использовать расширение mysqli, а не старое расширение mysql.

Да. Однако вы не можете выполнять транзакционные операции внутри сохраненной функции.

Да, стандартные действия, выполняемые в сохраненных процедурах и функциях, реплицируются с сервера источника репликации на реплику. Существуют некоторые ограничения, подробно описанные в Разделе 27.7, «Логирование двоичных данных сохраненных программ».

Да, создание сохраненных процедур и функций, выполняемое с помощью обычных DDL-операций на сервере источника репликации, реплицируется на реплику, так что объекты существуют на обоих серверах. ALTER и DROP операторы для сохраненных процедур и функций также реплицируются.

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

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

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

Недетерминированные (случайные) или основанные на времени действия, встроенные в сохраненные процедуры, могут не реплицироваться должным образом. По своей природе случайно полученные результаты непредсказуемы и не могут быть точно воспроизведены; поэтому случайные действия, реплицированные на реплику, не отражают тех, которые выполнялись на источнике. Объявление сохраненных функций как DETERMINISTIC или установка переменной системы log_bin_trust_function_creators в 0 предотвращает вызов случайных операций, генерирующих случайные значения.

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

Наконец, для нетранзакционных таблиц, для которых возникают ошибки во время больших действий DML (например, массовых вставок), могут возникнуть проблемы с репликацией, поскольку источник может быть частично обновлен из-за активности DML, но обновления не выполняются на реплике из-за возникших ошибок. Обходным путем является выполнение действий DML функции с ключевым словом IGNORE, чтобы обновления на источнике, вызывающие ошибки, игнорировались, а обновления, которые не вызывают ошибок, реплицировались на реплику.

Те же ограничения, которые влияют на репликацию, влияют и на восстановление по состоянию на определенную точку времени.

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

Также доступна смешанная репликация (путем запуска сервера с --binlog-format=mixed). Этот гибридный вид репликации “знает”, можно ли безопасно использовать репликацию на уровне оператора или требуется репликация на уровне строк.

Дополнительную информацию см. в Разделе 19.2.1, «Форматы репликации».