Да. 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.32, «Таблица INFORMATION_SCHEMA ROUTINES»).

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

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

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

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

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

Вы также можете использовать SHOW CREATE FUNCTION для получения информации о хранимых функциях и SHOW CREATE PROCEDURE для получения информации о хранимых процедурах. См. Раздел 15.7.7.11, «Инструкция 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.8, «Журналирование двоичного кода хранимых программ».

Да, создание хранимых процедур и функций, выполненное с помощью обычных операторов 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, «Форматы репликации».