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

См. Раздел 23.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 (см. Раздел 24.3.21, «Таблица INFORMATION_SCHEMA ROUTINES»).

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

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

Более подробную информацию см. в Разделе 24.3.21, «Таблица INFORMATION_SCHEMA ROUTINES».

Тело хранимой процедуры можно просмотреть, используя SHOW CREATE FUNCTION (для хранимой функции) или SHOW CREATE PROCEDURE (для хранимой процедуры). Подробнее см. в Разделе 13.7.5.9, «Команда SHOW CREATE PROCEDURE».

В таблице proc системной базы данных mysql. Однако напрямую обращаться к таблицам системной базы данных не следует. Вместо этого следует использовать запросы к таблицам INFORMATION_SCHEMA ROUTINES и PARAMETERS. См. Раздел 24.3.21, «Таблица INFORMATION_SCHEMA ROUTINES» и Раздел 24.3.15, «Таблица INFORMATION_SCHEMA PARAMETERS».

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

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

Да.

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

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

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

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

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

Нет.

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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