Паутов Алексей В.
Шрифт:
Чтобы предотвращать проблемы взаимодействия между потоками сервера, когда пользователь выдает инструкцию, сервер использует кадр подпрограмм и вызывает доступные для выполнения инструкции. То есть, сервер вычисляет список процедур, функций и триггеров, который может использоваться в течение выполнения инструкции, загружает их, и затем продолжает выполнять инструкцию. Это означает, что, в то время как инструкция выполняется, она не будет видеть изменения для подпрограмм, выполняемых другими потоками сервера.
Инструкция RENAME DATABASE не перемещает сохраненные подпрограммы к новому имени схемы.
Для триггеров следующие дополнительные инструкции или операции отвергнуты:
Триггеры в настоящее время не активизированы действиями внешнего ключа.
Инструкция RETURN запрещена в триггере, который не может возвращать значение. Чтобы выходить из него немедленно, используйте инструкцию LEAVE.
Триггеры не позволяются на таблицах в базе данных mysql.
11.2. Ограничения на курсоры сервера
Курсоры стороны сервера выполнены в C API через функцию mysql_stmt_attr_set. Та же самая реализация используется для курсоров в сохраненных подпрограммах. Курсор стороны сервера позволяет набору результатов быть сгенерированным на стороне сервера, но не перемещен пользователю, кроме тех строк, которые пользователь запрашивает. Например, если пользователь выполняет запрос, но заинтересован только первой строкой, остающиеся строки не будут перемещены.
В MySQL серверные курсоры осуществлены сквозь временную таблицу. Первоначально это таблица MEMORY, но преобразованная в таблицу MyISAM, если размер достигает значения переменной системы max_heap_table_size. Одно ограничение реализации в том, что для большого набора результатов получение строк через курсор может быть медленным.
Курсоры предназначены пока только для чтения: Вы не можете использовать курсор, чтобы модифицировать строки. А поэтому обновляемые курсоры не обеспечиваются. Следовательно, UPDATE WHERE CURRENT OF и DELETE WHERE CURRENT OF не выполнены.
Курсоры не сохраняются открытыми после передачи.
Курсоры не прокручиваемые.
Курсоры не именованы. Операторный драйвер действует как курсор ID.
Вы можете иметь открытым только один курсор на подготовленную инструкцию. Если Вы нуждаетесь в нескольких курсорах, Вы должны подготовить несколько инструкций.
Вы не можете использовать курсор для инструкции, которая генерирует набор результатов, если инструкция не обеспечивается в подготовленном режиме. Это включает инструкции типа CHECK TABLES, HANDLER READ и SHOW BINLOG EVENTS.
11.3. Ограничения на подзапросы
Известная ошибка, которая будет фиксирована позже: если Вы сравниваете значение NULL с подзапросом, использующим ALL, ANY или SOME, и подзапрос возвращают пустой результат, сравнение может быть оценено к ненормативному результату NULL, а не к TRUE или FALSE.
Внешняя инструкция подзапроса может быть любой из SELECT, INSERT, UPDATE, DELETE, SET или DO.
Оптимизация подзапроса для IN не как эффективна, как для оператора = или для конструкции IN(value_list).
Типичный случай для недостаточной эффективности подзапроса IN: когда подзапрос возвращает маленькое число строк, но внешний запрос возвращает большое количество строк, которые нужно сравнить с результатом подзапроса.
Проблема состоит в том, что для инструкции, которая использует в подзапросе IN, оптимизатор перезаписывает это как соотнесенный подзапрос. Рассмотрите следующую инструкцию, которая использует несоотнесенный подзапрос:
SELECT … FROM t1 WHERE t1.a IN (SELECT b FROM t2);
Оптимизатор переписывает инструкцию к соотнесенному подзапросу:
SELECT … FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.b = t1.a);
Если внутренние и внешние запросы возвращают M и N строк соответственно, время выполнения становится порядка O(M^N), а не O(M+N), как это было бы для несоотнесенного подзапроса.
<