Упрощенная китайская версия руководства для MySQL 5.1.12 может быть найдена на http://dev.mysql.com/doc/#chinese-5.1. Японская для MySQL 4.1 может быть получена с http://dev.mysql.com/doc/#japanese-4.1.
10.11.21: Где я могу получать справку по CJK и связанным проблемам в MySQL?
Следующие ресурсы доступны:
Перечень групп пользователей MySQL может быть найден на http://dev.mysql.com/user-groups/.
Вы можете входить в контакт с инженером сбыта в MySQL KK Japan:
Tel: +81(0)3-5326-3133
Fax: +81(0)3-5326-3001
Email: [email protected]
Просмотр показывает запросы в отношении проблем набора символов на http://tinyurl.com/y6xcuf.
Посетите форум "MySQL Character Sets, Collation, Unicode" на http://forums.mysql.com/list.php?103.
Глава 11. Ограничения свойств
Обсуждение здесь описывает ограничения, которые относятся к использованию свойств MySQL типа подзапросов или просмотров.
11.1. Ограничения на сохраненные подпрограммы и триггеры
Некоторые из ограничений, отмеченных здесь, относятся ко всем сохраненным подпрограммам, то есть к сохраненным процедурам и сохраненным функциям. Некоторые из ограничений применяются только к сохраненным функциям, но не к сохраненным процедурам. Все ограничения для сохраненных функций также относятся к триггерам.
Сохраненные подпрограммы не могут содержать произвольные инструкции SQL. Следующие инструкции отвергнуты:
Инструкции блокировки LOCK TABLES и UNLOCK TABLES.
LOAD DATA и LOAD TABLE.
Подготовленные инструкции SQL (PREPARE, EXECUTE, DEALLOCATE PREPARE).
Вы не можете использовать динамический SQL внутри сохраненных подпрограмм (где Вы создаете динамически инструкции как строки, а затем выполняете их). Это ограничение снимается в MySQL 5.0.13 для сохраненных процедур, но это все еще применяется к сохраненным функциям и триггерам.
Для сохраненных функций (но не для процедур) следующие дополнительные инструкции или операции отвергнуты:
Инструкции, которые делают явный или неявный commit или rollback.
Инструкции, которые возвращают набор результатов. Это включает инструкции SELECT, которые не имеют предложения INTO var_list, и инструкции SHOW. Функция может обрабатывать набор результатов через SELECT … INTO var_list или используя курсор и инструкции FETCH.
Все инструкции FLUSH.
Инструкции рекурсии. То есть, сохраненные функции не могут использоваться рекурсивно.
Внутри сохраненной функции или триггера не разрешается изменять таблицу, которая уже используется (для чтения или записи) инструкцией, которая вызвала функцию или триггер.
Обратите внимание, что, хотя некоторые ограничения обычно относятся к сохраненным функциям и триггерам, но не к сохраненным процедурам, эти ограничения относятся к сохраненным процедурам, если они вызываются изнутри сохраненной функции или триггера. Например, хотя Вы можете использовать FLUSH в сохраненной процедуре, такая сохраненная процедура не может быть вызвана из сохраненной функции или из триггера.
Тот же самый идентификатор можно использовать для стандартного параметра, локальной переменной и столбца таблицы. Также, то же самое локальное переменное имя может использоваться во вложенных блоках. Например:
CREATE PROCEDURE p (i INT)
BEGIN
DECLARE i INT DEFAULT 0;
SELECT i FROM t;
BEGIN
DECLARE i INT DEFAULT 1;
SELECT i FROM t;
END;
END;
В таких случаях идентификатор неоднозначен, и следующие правила старшинства применяются:
Локальная переменная имеет приоритет над стандартным параметром или столбцом таблицы.
Стандартный параметр имеет приоритет над столбцом таблицы.
Локальная переменная во внутреннем блоке имеет приоритет над локальной переменной во внешнем блоке.
Поведение, что столбцы таблицы не имеют приоритет над переменными, ненормативно.
Использование сохраненных подпрограмм может вызывать проблемы дублирования. Эта проблема рассмотрена далее.
INFORMATION_SCHEMA еще не имеет таблицу PARAMETERS, так что прикладные программы, которым надо собирать стандартную информацию параметров во время выполнения должны использовать методы типа синтаксического анализа вывода инструкций SHOW CREATE.
Не имеется никакой системы отладки сохраненных подпрограмм.
Инструкции CALL не могут быть подготовлены.
Драйверы UNDO не обеспечиваются.
Циклы FOR не обеспечиваются.
Чтобы предотвращать проблемы взаимодействия между потоками сервера, когда пользователь выдает инструкцию, сервер использует кадр подпрограмм и вызывает доступные для выполнения инструкции. То есть, сервер вычисляет список процедур, функций и триггеров, который может использоваться в течение выполнения инструкции, загружает их, и затем продолжает выполнять инструкцию. Это означает, что, в то время как инструкция выполняется, она не будет видеть изменения для подпрограмм, выполняемых другими потоками сервера.
Инструкция 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), как это было бы для несоотнесенного подзапроса.
Подзапрос IN может быть намного медленнее, чем запрос, написанный с использованием конструкции IN(value_list), которая вносит в список те же самые значения, которые возвратил бы подзапрос.
