WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Приложение C. Ограничения и лимиты Обсуждение здесь описывает ограничения, которые относятся к использованию особенностей MySQL, таких как подзапросы или представления. C.1. Ограничения на сохраненные программы Эти ограничения относятся к особенностям, описанным в главе 21. Некоторые из ограничений, отмеченных здесь, относятся ко всем сохраненным подпрограммам, то есть, к хранимым процедурам и к сохраненным функциям. Есть также некоторые ограничения, определенные для сохраненных функций, но не для хранимых процедур. Ограничения для сохраненных функций также относятся к триггерам. Есть также некоторые ограничения, определенные для триггеров. Ограничения для хранимых процедур также относятся к предложению DO определений планировщика событий. Есть также некоторые ограничения, определенные для событий. Запросы SQL, не разрешенные в сохраненных программах Сохраненные программы не могут содержать произвольные запросы SQL. Следующие запросы не разрешены: Блокировки LOCK TABLES и UNLOCK TABLES. ALTER VIEW. LOAD DATA и LOAD TABLE. Подготовленные запросы SQL (PREPARE, EXECUTE, DEALLOCATE PREPARE) могут использоваться в хранимых процедурах, но не сохраненных функциях или триггерах. Таким образом, сохраненные функции и триггеры не могут использовать динамический SQL (где Вы создаете запросы как строки и затем выполняете их). Вообще, запросы, не разрешенные в подготовленных запросах SQL, также не разрешены в сохраненных программах. Для списка запросов, поддержанных как подготовленные, см. раздел 14.5. Исключения: SIGNAL, RESIGNAL и GET DIAGNOSTICS, которые недопустимы как подготовленные запросы, но разрешены в сохраненных программах. Поскольку местные переменные находятся в контексте только во время выполнения сохраненной программы, ссылки на них не разрешены в готовых запросах, создаваемых в пределах сохраненной программы. Готовый контекст запроса это текущий сеанс, а не сохраненная программа, таким образом, запрос может быть выполнен после завершения программы, а в этот момент переменные больше не будут в контексте. Например, SELECT ... INTO local_var не может использоваться в качестве готового запроса. Это ограничение также относится к хранимой процедуре и функциональным параметрам. См. раздел 14.5.1. В пределах всех сохраненных программ (хранимые процедуры и функции, триггеры и события), анализатор обрабатывает BEGIN [WORK] как начало, а BEGIN ... END как конец блока. Чтобы начать транзакцию в этом контексте, надо использовать START TRANSACTION. Ограничения для сохраненных функций Следующие дополнительные операции не разрешены в пределах сохраненных функций. Они разрешаются в пределах хранимых процедур, кроме хранимых процедур, которые вызваны изнутри сохраненной функции или триггера. Например, если Вы используете FLUSH в хранимой процедуре, эту хранимую процедуру нельзя вызвать из сохраненной функции или триггера. Запросы, которые завершают или отменяют транзакцию. Поддержка этих запросов не требуется стандартом SQL, который заявляет, что каждый поставщик системы управления базами данных может решить, разрешены ли они. Запросы, которые возвращают набор результатов. Это включает SELECT, которые не имеют предложения INTO var_list и другие запросы, такие как SHOW, EXPLAIN и CHECK TABLE. Функция может обработать набор результатов SELECT ... INTO var_list или используя курсор и запросы FETCH. См. разделы 14.2.9.1 и 14.6.6. FLUSH. Сохраненные функции не могут использоваться рекурсивно. Сохраненная функция или триггер не могут изменить таблицу, которая уже используется (для чтения или записи) запросом, который вызвал функцию или триггер. Если Вы обращаетесь к временной таблице многократно в сохраненной функции под различными псевдонимами, происходит ошибка Can't reopen table: 'tbl_name', даже если ссылки происходят в различных запросах в пределах функции. Запросы HANDLER ... READ, которые вызывают сохраненные функции, могут вызвать ошибки репликации и отвергнуты. Ограничения для триггеров Для триггеров применяются следующие дополнительные ограничения: Триггеры не активированы действиями внешнего ключа. Используя основанную на строке репликацию, триггеры на ведомом устройстве не активированы запросами, происходящими на ведущем устройстве. Триггеры на ведомом устройстве активированы, используя основанную на запросе репликацию. Для получения дополнительной информации см. раздел 19.4.1.35. RETURN не разрешен в триггерах, которые не могут возвратить значение. Чтобы немедленно выйти из триггера, используйте LEAVE. Триггеры не разрешены на таблицах в базе данных mysql. Кэш триггеров не обнаруживает, когда метаданные основных объектов изменились. Если триггер использует таблицу, и таблица изменилась с тех пор, как триггер был загружен в кэш, то триггер управляет использованием устаревших метаданных. Конфликты имен в пределах сохраненных подпрограмм Тот же самый идентификатор мог бы использоваться для обычного параметра, местной переменной и столбца таблицы. Кроме того, то же самое местное имя переменной может использоваться во вложенных блоках. Например: 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; В таких случаях идентификатор неоднозначен, и следующие правила приоритета применяются: Местная переменная имеет приоритет перед обычным параметром или столбцом таблицы. Обычный параметр имеет приоритет перед столбцом. Местная переменная во внутреннем блоке имеет приоритет перед местной переменной во внешнем блоке. Поведение, что переменные имеют приоритет перед столбцами таблицы, нестандартно. Соображения о репликации Использование сохраненных подпрограмм может вызвать проблемы репликации. Эта проблема обсуждена далее в разделе 21.7. Опция --replicate-wild-do-table=db_name.tbl_name относится к таблицам, представлениям и триггерам. Это не относится к хранимым процедурам, функциям или событиям. Чтобы фильтровать запросы, воздействующие на последние объекты, используйте одну или больше опций --replicate-*-db. Отладка Нет никаких средств отладки сохраненных подпрограмм. Неподдержанный синтаксис из стандарта SQL:2003 Синтаксис MySQL основан на стандарте SQL:2003. Следующие элементы этого стандарта в настоящее время не поддерживаются: UNDO. Циклы FOR. Соображения параллелизма Чтобы предотвратить проблемы взаимодействия между сеансами, когда клиент делает запрос, сервер использует снимок подпрограмм и триггеров, доступный для выполнения запроса. Таким образом, сервер вычисляет список процедур, функций и триггеров, которые могут использоваться во время выполнения запроса, загружает их, а затем продолжает выполнять запрос. В то время как запрос выполняется, он не видит изменений подпрограмм, выполненных другими сеансами. Для максимального параллелизма сохраненные функции должны минимизировать свои побочные эффекты: в частности обновление таблицы в пределах сохраненной функции может уменьшить параллельные операции на этой таблице. Сохраненная функция приобретает табличные блокировки перед выполнением, чтобы избежать несогласованности в двоичном журнале из-за несоответствия порядка, в котором запросы выполняются с тем, когда они появляются в журнале. Когда основанный на запросе двоичное журналирование используется, зарегистрированы запросы, которые вызывают функцию, а не запросы, которые выполнены в пределах функции. Следовательно, сохраненные функции, которые обновляют те же самые основные таблицы, не выполняются параллельно. Напротив, хранимые процедуры не приобретают блокировки на уровне таблицы. Все запросы, выполненные в пределах хранимых процедур, записаны в двоичный журнал, даже для основанного на запросе двоичного журналирования. См. раздел 21.7. Ограничения планировщика событий Следующие ограничения являются определенными для планировщика событий: Имена событий обработаны нечувствительным к регистру способом. Например, у Вас не может быть двух событий в той же самой базе данных с именами anEvent и AnEvent. Событие не может быть создано, изменено или удалено сохраненной подпрограммой, триггером или другим событием. Событие не может создать, изменить или удалить сохраненные подпрограммы или триггеры. (Bug #16409, Bug #18896). DDL-запросы о событиях запрещены в то время, как LOCK TABLES работает. Синхронизации событий, используя интервалы YEAR, QUARTER, MONTH и YEAR_MONTH решены в месяцах, в секундах решены те, которые используют любой другой интервал. Нет никакого способа вызвать события, которые, как намечают, произойдут в ту же самую секунду, в заданном порядке. Из-за округления, природы поточных приложений и факта, что отрезок времени, отличный от нуля, нужен, чтобы создавать события и сигнализировать об их выполнении, событие может быть отсрочено на 1 или 2 секунды. Однако, время, показанное в столбце LAST_EXECUTED таблицы INFORMATION_SCHEMA.EVENTS или столбце last_executed таблицы mysql.event всегда точно в рамках одной секунды после фактического времени выполнения события. См. также Bug #16522. Каждое выполнение запросов, содержавшихся в теле события, имеет место в новом соединении, таким образом, эти запросы не имеют никакого эффекта в данном пользовательском сеансе на счетчики сервера Com_select и Com_insert, которые выведен на экран SHOW STATUS. Однако, такие счетчики обновлены в глобальном контексте (Bug #16422). События не поддерживают время позже, чем конец Unix Epoch, это приблизительно начало 2038 года. Такие даты определенно не разрешены планировщиком событий (Bug #16396). Ссылки на сохраненные функции, определяемые пользователем функции и таблицы в предложении ON SCHEDULE запросов CREATE EVENT и ALTER EVENT не поддержаны. Эти виды ссылок не разрешены (см. Bug #22830). C.2. Ограничения на условия обработки SIGNAL, RESIGNAL и GET DIAGNOSTICS недопустимы как подготовленные. Например, это недопустимо: PREPARE stmt1 FROM 'SIGNAL SQLSTATE "02000"'; Значения SQLSTATE класса '04' не обработаны особенно. Они обработаны так же, как другие исключения. У стандартного SQL есть стек области диагностики, содержащий область диагностики для каждого вложенного контекста выполнения. Стандартный синтаксис SQL включает GET STACKED DIAGNOSTICS для того, чтобы обратиться к этим областям. MySQL не поддерживает ключевое слово STACKED, потому что есть единственная область диагностики, содержащая информацию из нового запроса. См. также раздел 14.6.7.7. В стандартном SQL первое условие касается значения SQLSTATE, возвращенного для предыдущего запроса SQL. В MySQL это не гарантируется, так что получив основную ошибку, Вы не можете сделать это: GET DIAGNOSTICS CONDITION 1 @errno = MYSQL_ERRNO; Вместо этого надо: GET DIAGNOSTICS @cno = NUMBER; GET DIAGNOSTICS CONDITION @cno @errno = MYSQL_ERRNO; C.3. Ограничения на серверные курсоры Серверные курсоры осуществлены в C API через использование функции mysql_stmt_attr_set() . То же самое выполнение используется для курсоров в сохраненных подпрограммах. Серверный курсор позволяет набору результатов быть произведенным на стороне сервера, но не переданным клиенту за исключением тех строк, которые просит клиент. Например, если клиент выполняет запрос, но интересуется только первой строкой, остающиеся строки не переданы. В MySQL серверный курсор осуществлен во внутреннюю временную таблицу. Первоначально это MEMORY, но преобразована в MyISAM, когда ее размер превышает минимальное значение переменных max_heap_table_size и tmp_table_size. Те же самые ограничения относятся к внутренним временным таблицам, составленным, чтобы держать набор результатов для курсора. См. раздел 9.4.4. Одно ограничение выполнения: для большого набора результатов, получение его строк через курсор могло бы быть медленным. Курсоры только для чтения; Вы не можете использовать курсор, чтобы обновить строки. UPDATE WHERE CURRENT OF и DELETE WHERE CURRENT OF не осуществлены, потому что обновляемые курсоры не поддержаны. Курсоры являются непрокручиваемыми. Курсоры не имеют имен. Обработчик действует как ID. Вы можете иметь только единственный открытый курсор на готовый запрос. Если Вы нуждаетесь в нескольких курсорах, Вы должны подготовить несколько запросов. Вы не можете использовать курсор для запроса, который производит набор результатов, если запрос не поддержан в готовом режиме. Это включает такие запросы, как CHECK TABLE, HANDLER READ и SHOW BINLOG EVENTS. C.4. Ограничения на подзапросы Вообще, Вы не можете изменить таблицу и выбрать из той же самой таблицы в подзапросе. Например, это ограничение относится к запросам следующих форм: DELETE FROM t WHERE ... (SELECT ... FROM t ...); UPDATE t ... WHERE col = (SELECT ... FROM t ...); {INSERT|REPLACE} INTO t (SELECT ... FROM t ...); Исключение: предыдущий запрет не применяется, если Вы используете подзапрос для измененной таблицы в предложении FROM, и подзапрос осуществлен, а не все это слито во внешний запрос. См. раздел 9.2.1.18.3: UPDATE t ... WHERE col = (SELECT * FROM (SELECT ... FROM t...) AS _t ...); Здесь следствие подзапроса в предложении FROM сохранено как временная таблица, таким образом, соответствующие строки в t были уже выбраны к моменту обновления t. Операции сравнения строки только частично поддержаны: Для expr [NOT] IN subquery, expr может быть n-кортеж (определенный синтаксис конструктора строки использования) и подзапрос может возвратить строки n-кортежей. Разрешенный синтаксис поэтому более определенно выражен как row_constructor [NOT] IN table_subquery. Для expr op {ALL|ANY|SOME} subquery expr должно быть скалярным значением, и подзапрос должен быть подзапросом столбца, это не может возвратить строки из многих столбцов. Другими словами, для подзапроса, который возвращает строки n-кортежи, это поддержано: (expr_1, ..., expr_n) [NOT] IN table_subquery Но это не поддержано: (expr_1, ..., expr_n) op {ALL|ANY|SOME} subquery Причина поддержки сравнений строки для IN, но не для других: IN осуществлен, переписывая это как последовательность сравнений = и операций AND. Этот подход не может использоваться для ALL, ANY или SOME. Подзапросы в FROM не могут быть коррелированными подзапросами. Они осуществлены полностью (оценены, чтобы произвести набор результатов) во время выполнения запроса, таким образом, они не могут быть оценены на строку внешнего запроса. Оптимизатор задерживает материализацию, пока результат не необходим, что может разрешить избежать материализации. См. раздел 9.2.1.18.3. MySQL не поддерживает LIMIT в подзапросах для определенных операторов подзапроса: mysql> SELECT * FROM t1 -> WHERE s1 IN (SELECT s2 FROM t2 ORDER BY s1 LIMIT 1); ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' MySQL разрешает подзапросу обращаться к сохраненной функции, у которой есть изменяющие данные побочные эффекты, такие как вставка строк в таблицу. Например, если f() вставляет строки, следующий запрос может изменить данные: SELECT ... WHERE x IN (SELECT f() ...); Это поведение расширение к стандарту SQL. В MySQL это может привести к неопределенным результатам потому, что f() может быть выполнена различное число раз для разного выполнения данного запроса в зависимости от того, как оптимизатор хочет обрабатывать это. Для основанной на запросе или смешанной репликации одно значение этого в том, что такой запрос может привести к различным результатам на ведущем устройстве и его ведомых устройствах. C.5. Ограничения на представления Обработка представления не оптимизирована: Невозможно создать индекс на представлении. Индекс может использоваться для представлений, обработанных, используя алгоритм слияния. Однако, представление, которое обработано алгоритмом temptable, неспособно использовать в своих интересах индекс на его основных таблицах (хотя индекс может использоваться во временных таблицах). Есть общий принцип, что Вы не можете изменить таблицу и выбрать из той же самой таблицы в подзапросе. См. раздел C.4. Тот же самый принцип также применяется, если Вы выбираете из представления, которое выбирает из таблицы, если представление выбирает из таблицы в подзапросе, и представление оценено, используя алгоритм слияния. Пример: CREATE VIEW v1 AS SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a); UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b; Если представление оценено, используя временную таблицу, Вы можете выбрать из таблицы в представлении подзапроса и все еще изменять эту таблицу во внешнем запросе. В этом случае представление будет сохранено во временной таблице, и таким образом Вы действительно не выбираете из таблицы в подзапросе и изменяете ее в то же самое время. Это другая причина, по которой Вы могли бы хотеть вынудить MySQL использовать алгоритм temptable, определяя ALGORITHM = TEMPTABLE в определении представления. Вы можете использовать DROP TABLE или ALTER TABLE, чтобы удалить или изменить таблицу, которая используется в определении представления. Никакое предупреждение не следует из DROP или ALTER даже при том, что это лишает законной силы представление. Вместо этого ошибка происходит позже, когда представление используется. CHECK TABLE может использоваться, чтобы проверить на представления, которые были лишены законной силы DROP или ALTER. Относительно обновляемого представления, полная цель для представлений состоит в том, что, если какое-либо представление теоретически обновляемое, это должно быть обновляемо практически MySQL как можно быстрее. Многие теоретически обновляемые представления могут быть обновлены теперь, но ограничения все еще существуют. Для деталей см. раздел 21.5.3. Там существует недостаток с текущим выполнением представлений. Если пользователю предоставляют основные привилегии, необходимые, чтобы создать представление (CREATE VIEW и SELECT), тот пользователь будет неспособен вызвать SHOW CREATE VIEW на том объекте, если пользователю также не предоставляют привилегию SHOW VIEW. Тот недостаток может привести к проблемам, поддерживая базу данных с mysqldump, который может потерпеть неудачу из-за недостаточных привилегий. Эта проблема описана в Bug #22062. Обходное решение проблемы для администратора: вручную предоставить привилегию SHOW VIEW пользователям, которым предоставляют CREATE VIEW, так как MySQL не предоставляет это неявно, когда представления создаются. Представления не имеют индека, так что индексные подсказки не применяются. Использование индексных подсказок при выборе из представления не разрешено. SHOW CREATE VIEW отображаетя определения, используя предложение AS alias_name для каждого столбца. Если столбец создается из выражения, псевдоним по умолчанию текст выражения, который может быть довольно длинным. Псевдонимы для имен столбцов в CREATE VIEW проверены по максимальной длине столбца в 64 символа (а не максимальной длине псевдонима в 256 символов). В результате, представления, создаваемые из вывода SHOW CREATE VIEW терпят неудачу, если какой-либо псевдоним столбца превышает 64 символа. Это может вызвать проблемы при следующих обстоятельствах для представлений со слишком длинными псевдонимами: Определения представления не в состоянии копироваться на более новые ведомые устройства, которые проводят в жизнь ограничение длины. Файлы дампа, создаваемые с mysqldump не могут быть загружены в серверы, которые проводят в жизнь ограничение длины. Обходное решение для этой проблемы должно изменить каждое проблематичное определение представления, чтобы использовать псевдонимы, которые обеспечивают более короткие имена столбцов. Тогда представление будет копировать должным образом, и может быть выведено и перезагружено, не вызывая ошибку. Чтобы изменить определение, удалите и пересоздайте представление снова с помощью DROP VIEW и CREATE VIEW или замените определение с помощью CREATE OR REPLACE VIEW. Для проблем, которые происходят, перезагружая определения представления в файлах дампа, есть другое обходное решение: отредактировать файл дампа, чтобы изменить запрос CREATE VIEW. Однако, это не изменяет оригинальные определения представления, которые могут вызвать проблемы для последующих операций дампа. C.6. Ограничения транзакций XA Операционная поддержка XA ограничена механизмом хранения InnoDB. Для external XA сервер MySQL действует как менеджер ресурсов, а клиент как менеджер по транзакциям. Для Internal XA механизмы хранения в пределах сервера MySQL являются менеджерами ресурсов, а сам сервер действует как менеджер по транзакциям. Внутренняя поддержка XA ограничена способностями отдельных механизмов хранения. Внутренний XA требуется для того, чтобы обработать транзакции XA, которые вовлекают больше, чем один механизм хранения. Выполнение внутреннего XA требует, чтобы механизм хранения поддержал двухфазную передачу на табличном уровне обработчика, в настоящее время это истина только для InnoDB. Для XA START предложения JOIN и RESUME не поддержаны. Для XA END предложение SUSPEND [FOR MIGRATE] не поддержано. Требование, что bqual часть значения xid отличается для каждой транзакции XA в пределах глобальной транзакции является ограничением текущего выполнения XA в MySQL. Это не часть спецификации XA. Транзакции XA записаны в двоичный журнал в виде двух частей. Когда запрос XA PREPARE выпущен, первая часть транзакции до XA PREPARE записана, используя начальный GTID. XA_prepare_log_event используется, чтобы идентифицировать такие транзакции в двоичном журнале. Когда XA COMMIT или XA ROLLBACK выпущен, вторая часть транзакции, содержащая только XA COMMIT или XA ROLLBACK записана, используя второй GTID. Отметьте что начальная часть транзакции, идентифицированной XA_prepare_log_event, не обязательно сопровождается XA COMMIT или XA ROLLBACK, который может вызвать чередованное двоичное журналирование любых двух транзакций XA. Две части транзакции XA могут даже появиться в различных двоичных файлах системного журнала. Это означает, что транзакция XA в состоянии PREPARED является теперь постоянной до явного запроса XA COMMIT или XA ROLLBACK, гарантируя, что транзакции XA совместимы с репликацией. Следующие ограничения существуют для того, чтобы использовать XA: XA не полностью безопасен от катастрофического отказа относительно двоичного журнала (на ведущем устройстве). Если есть катастрофический отказ до XA PREPARE, между XA PREPARE и XA COMMIT (или XA ROLLBACK) или после XA COMMIT (или XA ROLLBACK), сервер и двоичный журнал правильно восстановлены и взяты в последовательное состояние. Однако, если есть катастрофический отказ в середине выполнения одного из этих запросов, сервер, возможно, не в состоянии вернуться в правильное состояние. XA не работает с relay-log-info-repository=TABLE. XA не работает с фильтрами репликации или двоичного журнала. Фильтры разрешены, пока они не представляют пустых транзакций XA. Фильтры, которые отфильтровывают транзакции XA, могут заставить ведомое устройство останавливаться с ошибкой. В случае если GTIDs включены, и ведомое устройство не использует также log-bin=OFF или log-slave-updates , транзакции XA не безопасны от катастрофического отказа относительно GTIDs на ведомом устройстве. Если ведомое устройство неожиданно останавливается, применяя XA PREPARE или XA COMMIT, после восстановления @@GLOBAL.GTID_EXECUTED, возможно, неправильно описывает транзакции, которые были применены на ведомое устройство. До MySQL 5.7.7 транзакции XA не были совместимы с репликацией. Это потому, что транзакция XA, которая была в состоянии PREPARED, была бы отменена до прежнего уровня на чистом завершении работы сервера или обрыве связи с клиентом. Точно так же транзакция XA, которая была в состоянии PREPARED все еще существовала бы в состоянии PREPARED в случае, если сервер был завершен неправильно, а затем запущен снова, но содержание транзакции не могло быть записано в двоичный журнал. В обеих этих ситуациях транзакция XA не могла копироваться правильно. C.7. Ограничения на наборы символов Идентификаторы, сохраненные в базе данных mysql (таблицы user, db и т.д.), используют utf8, но идентификаторы могут содержать только символы в Basic Multilingual Plane (BMP). Дополнительные символы не разрешены в идентификаторах. У наборов символов ucs2, utf16, utf16le и utf32 есть следующие ограничения: Они не могут использоваться в качестве набора символов клиента, что означает, что они не работают в SET NAMES или SET CHARACTER SET (см. раздел 11.1.4 ). В настоящее время невозможно использовать LOAD DATA INFILE, чтобы загрузить файлы с данными, которые используют эти наборы символов. Индекс FULLTEXT не может быть создан на столбце, который использует любой из этих наборов символов. Однако, Вы можете выступить IN BOOLEAN MODE поиски на столбце без индексирования. Использование ENCRYPT() с этими наборами символов не рекомендуется, потому что основной системный вызов ожидает строку, законченную нулевым байтом. Операторы REGEXP и RLIKE работают побайтно, таким образом, они не безопасны для мультибайтных символов и могут привести к неожиданным результатам с многобайтовыми наборами символов. Кроме того, эти операторы сравнивают символы по их значения байта, и акцентированные символы, возможно, не сравниваются как равные, даже если данное сопоставление обрабатывает их как равные. C.8. Ограничения Performance Schema Performance Schema избегает использования mutexes, чтобы собрать или произвести данные, таким образом нет никаких гарантий последовательности, и результаты могут иногда быть неправильными. Значения событий в таблицах performance_schema недетерминированы и неповторимы. Если Вы сохраняете информацию о событии в другой таблице, Вы не должны предположить, что оригинальные события все еще будут доступны позже. Например, если Вы выбираете события из таблицы performance_schema во временную таблицу, намереваясь присоединиться к той таблице с оригинальной таблицей позже, не может быть никаких соответствий. mysqldump и BACKUP DATABASE игнорируют таблицы в базе данных performance_schema. Таблицы в базе данных performance_schema не могут быть заблокированы с LOCK TABLES, кроме таблиц setup_xxx. Таблицы в базе данных performance_schema не могут быть индексированы. Результаты для запросов, которые обращаются к таблицам в performance_schema, не сохранены в кэше запроса. Таблицы в базе данных performance_schema не реплицируются. Performance Schema недоступна в встроенном сервере libmysqld. Типы таймеров могли бы измениться, в зависимости от платформы. Таблица performance_timers показывает, какие таймеры событий доступны. Если значения в этой таблице для данного имени таймера NULL, этот таймер не поддержан на Вашей платформе. Инструменты, которые относятся к механизмам хранения, не могли бы быть осуществлены для всех механизмов хранения. Инструментовка каждого имеющего отношение к третьей стороне механизма ответственность автора механизма. C.9. Ограничения на подключаемую аутентификацию Первая часть этого раздела описывает общие ограничения на применимость структуры аутентификации, описанной в разделе 7.3.9. Вторая часть описывает, как имеющие отношение к третьей стороне разработчики могут определить степень, до которой плагин может использовать в своих интересах возможности аутентификации. Термин нативная авторизация, используемый здесь, относится к аутентификации по паролям, сохраненным в таблице mysql.user. Это прежний метод аутентификации, обеспеченный более старыми серверами MySQL, прежде, чем аутентификация плагинами была осуществлена. Это остается методом по умолчанию, хотя теперь это осуществлено, используя плагины. Нативная авторизация Windows обращается к аутентификации, используя авторизацию пользователя, который уже вошел в систему к Windows, как осуществлено плагином Windows Native Authentication (Windows plugin для краткости). Общие ограничения авторизации плагинами Connector/C, Connector/C++: Клиенты, которые используют эти соединители, могут соединить с сервером только через учетные записи с нативной авторизацией. Исключение: соединитель поддерживает плагиновую аутентификацию, если он был собран с libmysqlclient динамически (а не статически) и загружает текущую версию libmysqlclient, если эта версия установлена, или если соединитель повторно собран из исходных текстов для компоновки с текущей libmysqlclient. Connector/J: Клиенты, которые используют этот соединитель, могут соединиться с сервером только через учетные записи с нативной авторизацией. Connector/Net: До Connector/Net 6.4.4 клиенты, которые используют этот соединитель, могут соединиться с сервером только через учетные записи с нативной авторизацией. С 6.4.4 и выше клиенты могут также соединиться с сервером через учетные записи, которые используют Windows plugin. Connector/ODBC: До Connector/ODBC 3.51.29 и 5.1.9 клиенты, которые используют этот соединитель, могли соединиться с сервером только через учетные записи с нативной авторизацией. С 3.51.29 и 5.1.9 клиенты, которые используют двоичные выпуски этого соединителя для Windows, могут также соединиться с сервером через учетные записи, которые используют PAM или Windows plugin. Эти способности следствие компоновки Connector/ODBC с MySQL 5.5.16 libmysqlclient вместо MySQL 5.1 libmysqlclient. Более новая libmysqlclient включает клиентскую поддержку, необходимую для стороны сервера PAM и Windows plugin. Connector/PHP: Клиенты, которые используют этот соединитель, могут соединиться с сервером только через учетные записи, которые используют нативную авторизацию, используя драйвер MySQL для PHP (mysqlnd). MySQL Proxy: До MySQL Proxy 0.8.2 клиенты, которые используют этот соединитель, могут соединиться с сервером только через учетные записи, которые используют нативную авторизацию. С 0.8.2 клиенты могут также соединиться с сервером через учетные записи, которые используют PAM. С 0.8.3 клиенты могут также соединиться с сервером через учетные записи, которые используют Windows plugin. MySQL Enterprise Backup: MySQL Enterprise Backup до версии 3.6.1 поддерживает соединения с сервером только через учетные записи, которые используют нативную авторизацию. С 3.6.1 MySQL Enterprise Backup может соединиться с сервером через учетные записи с другой авторизацией. Windows native authentication: Соединение через учетную запись, которая использует плагин Windows, требует установки Windows Domain. Без этого используется аутентификация NTLM, затем только локальные соединения возможны. То есть, клиент и сервер должны работать на том же самом компьютере. Proxy users: Поддержка прокси доступна до такой степени, что клиенты могут соединиться через учетные записи, заверенные плагинами, которые осуществляют прокси (то есть, плагинами, которые могут возвратить имя пользователя, отличающееся от имени соединяющегося пользователя). Например, нативные плагины аутентификации не поддерживают пользователей прокси, тогда как PAM и Windows plugin такое умеют. Replication: ведомые устройства репликации могут использовать не только сводный отчет, используя нативную аутентификацию, но и могут также соединиться с иной авторизацией, если необходимый клиентский плагин доступен. Если плагин собран с libmysqlclient, это доступно по умолчанию. Иначе плагин должен быть установлен на ведомой стороне в каталоге, названном переменной plugin_dir на ведомом устройстве. Таблицы FEDERATED: Таблица FEDERATED может получить доступ к удаленной таблице только через учетные записи на удаленном сервере с нативной авторизацией. Аутентификация и имеющие отношение к третьей стороне соединители Имеющие отношение к третьей стороне разработчики соединителя могут использовать следующие направляющие линии, чтобы определить готовность соединителя использовать в своих интересах плагиновую аутентификацию: Существующий соединитель, в котором никакие изменения не были произведены использует нативную авторизацию и клиенты, которые используют соединитель, могут соединиться с сервером только через такие учетные записи. Однако, Вы должны проверить соединитель против недавней версии сервера, чтобы проверить, что такие соединения все еще работают без проблем . Исключение: соединитель мог бы работать с плагиновой аутентификацией без любых изменений, если он компонуется с libmysqlclient динамически (а не статически) и загружает текущую версию libmysqlclient, если эта версия установлена. Чтобы использовать плагиновую аутентификации, соединитель, который основан на libmysqlclient, должен быть перекомпонован с текущей версией libmysqlclient. Это позволяет соединителю поддержать соединения, хотя учетные записи, которые требуют клиентских плагинов, теперь созданных в libmysqlclient (такие как плагин открытого текста, необходимый для аутентификации PAM и Windows plugin для аутентификации Windows). Компоновка с текущей libmysqlclient позволяет соединителю получить доступ к клиентским плагинам, установленным в каталог плагинов MySQL (как правило, каталог по умолчанию локального сервера, указанный в переменной plugin_dir). Если соединитель компонуется с libmysqlclient динамически, должна быть обеспечена наиболее новая версия libmysqlclient на хосте клиента. Соединитель загружает ее во время выполнения. Иначе соединитель, чтобы поддержать данный метод аутентификации должен осуществить это непосредственно в протоколе клиент-сервер. Connector/Net использует этот подход, чтобы оказать поддержку для аутентификации Windows. Если соединитель должен быть в состоянии загрузить клиентские плагины из каталога, отличающегося от каталога плагинов по умолчанию, он должен осуществить некоторые средства для пользователей клиента определить каталог. Возможности для этого включают параметр командной строки или переменную окружения, из которой соединитель может получить имя каталога. Стандартные программы клиента MySQL, такие как mysql и mysqladmin осуществляют опцию --plugin-dir. См. раздел 25.8.14. C.10. Лимиты в MySQL Этот раздел перечисляет текущие лимиты в MySQL 8.0. C.10.1. Лимиты на Join Максимальное количество таблиц, на которые можно сослаться в единственном соединении, 61. Это включает соединение, обработанное, сливая полученные таблицы (подзапросы) и представления в предложении FROM во внешнем блоке запроса (см. раздел 9.2.1.18.3). Это также относится к числу таблиц, на которые можно сослаться в определении представления. C.10.2. Лимиты на число баз данных и таблиц У MySQL нет никакого предела числа баз данных. У основной файловой системы может быть предел числа каталогов. У MySQL нет никакого предела числа таблиц. У основной файловой системы может быть предел числа файлов, которые представляют таблицы. Отдельные механизмы хранения могут наложить определенные для механизма ограничения. InnoDB разрешает до 4 миллиардов таблиц. C.10.3. Лимит размера таблиц Эффективный максимальный табличный размер для баз данных MySQL обычно определяется ограничениями операционной системы на размеры файла, а не внутренними пределами MySQL. Следующая таблица приводит некоторые примеры пределов размера файла операционной системы. Это только грубое руководство и не предназначено, чтобы быть истиной в последней инстанции. Для получения самой современной информации проверьте документацию для Вашей операционной системы. ОС Лимит размера файла Win32 на FAT/FAT32 2GB/4GB Win32 на NTFS 2TB (можно и больше) Linux 2.2-Intel 32-bit 2GB (LFS: 4GB) Linux 2.4+ (на файловой системе ext3) 4TB Solaris 9/10 16TB OS X на HFS+ 2TB Пользователи Windows, пожалуйста, отметьте, что FAT и VFAT (FAT32) НЕ считаются подходящими для производственного использования с MySQL. Используйте NTFS вместо этого. В Linux 2.2 Вы можете создать таблицы MyISAM больше 2GB в размере при использовании патча Large File Support (LFS) для файловой системы ext2. Актуальнейшие дистрибутивы Linux основаны на ядре 2.4 или выше и включают все необходимые патчи LFS. На Linux 2.4 патчи также существуют для ReiserFS, чтобы получить поддержку больших файлов (до 2TB). С JFS и XFS в Linux возможны файлы в петабайт и даже более. Для подробного обзора о LFS в Linux см. страницу Andreas Jaeger's Large File Support in Linux на http://www.suse.de/~aj/linux_lfs.html. Если Вы действительно сталкиваетесь с ошибкой полной таблицы, есть несколько причин, почему это, возможно, произошло: Диск мог быть полный. Механизм хранения InnoDB поддерживает таблицы в пределах табличного пространства, которое может быть создано из нескольких файлов. Это позволяет таблице превысить максимальный размер отдельного файла. Табличное пространство может включать сырые дисковые разделы, которые разрешают чрезвычайно большие таблицы. Максимальный размер табличного пространства 64 TB. Если Вы используете таблицы InnoDB и исчерпали место в табличном пространстве InnoDB, решение состоит в том, чтобы расширить табличное пространство InnoDB. См. раздел 16.7.2. Вы используете таблицы MyISAM в операционной системе, которая поддерживает файлы только до 2GB в размере и превзошли этот предел для файла с данными или индексного файла. Вы используете таблицы MyISAM и пространство, требуемое для таблицы, превышает то, что разрешено внутренним размером указателя. MyISAM позволяет файлы с данными и индексные файлы до 256TB по умолчанию, но этот предел может быть изменен до максимального допустимого размера в 65536 TB (2567-1 байт). Если Вы нуждаетесь в таблице MyISAM, которая больше предела по умолчанию, и Ваша операционная система поддерживает большие файлы, запрос CREATE TABLE поддерживает опции AVG_ROW_LENGTH и MAX_ROWS. См. раздел 14.1.15. Сервер использует эти опции, чтобы определить, насколько большая таблица нужна. Если размер указателя является слишком маленьким для существующей таблицы, Вы можете изменить опции с ALTER TABLE, чтобы увеличить максимальный допустимый размер таблицы. См. раздел 14.1.7. ALTER TABLE tbl_name MAX_ROWS=1000000000 AVG_ROW_LENGTH=nnn; Вы должны определить AVG_ROW_LENGTH только для таблиц со столбцами BLOB или TEXT. В этом случае MySQL не может оптимизировать пространство, требуемое исходя только из числа строк. Чтобы изменить предел размера значения по умолчанию для MyISAM таблицы, установите параметр myisam_data_pointer_size, который определяет число байтов, используемых для внутренних указателей строки. Значение используется, чтобы установить размер указателя для новых таблиц, если Вы не определяете опцию MAX_ROWS. Значение myisam_data_pointer_size может быть от 2 до 7. Значение 4 разрешает таблицы до 4GB, 6 уже до 256TB. Вы можете проверить максимальные данные и индексировать размеры при использовании этого запроса: SHOW TABLE STATUS FROM db_name LIKE 'tbl_name'; Вы также можете использовать myisamchk -dv /path/to/table-index-file. См. разделы 14.7.5 или 5.6.4. Другие способы обойти ограничение размера таблиц MyISAM: Если Ваша большая таблица только для чтения, Вы можете использовать myisampack для ее сжатия. myisampack обычно сжимает таблицу по крайней мере на 50%, таким образом, у Вас могут быть в действительности намного большие таблицы. myisampack также может слить много таблиц в одну. См. раздел 5.6.6. MySQL включает библиотеку MERGE, которая позволяет Вам обработать набор таблиц MyISAM, у которых есть идентичная структура, как единую таблицу MERGE. См. раздел 17.7. Вы используете механизм хранения MEMORY (HEAP). В этом случае Вы должны увеличить значение переменной max_heap_table_size . См. раздел 6.1.5 . C.10.4. Лимиты на число столбцов и размер строк в таблице Есть жесткий предел 4096 столбцов на таблицу, но эффективный максимум может быть меньше для данной таблицы. Точный предел зависит от нескольких взаимодействующих факторов. У внутреннего представления таблицы MySQL есть максимальный размер строки 65535 байтов, даже если механизм хранения способен к поддержке более крупных строк. Это число исключает столбцы BLOB или TEXT, которые вносят только 9-12 байт к пределу размера строки, потому что их содержание сохранено отдельно от остальной части строки. Максимальный размер строки ограничивает число (и возможно размер) столбцов, потому что полная длина всех столбцов не может превысить этот размер. Например, символы utf8mb3 требуют до трех байтов на символ, таким образом, для столбца CHAR(255) CHARACTER SET utf8mb3 сервер должен выделить 255*3 = 765 байтов на значение. Следовательно, таблица не может содержать больше 65535/765=85 таких столбцов. Хранение для столбцов переменной длины включает байты длины, которые оценены по размеру строки. Например, столбец VARCHAR(255) CHARACTER SET utf8mb3 берет два байта, чтобы сохранить длину значения, таким образом, каждое значение может взять до 767 байт. Объявление столбцов NULL может уменьшить максимальное количество разрешенных столбцов. Для таблиц MyISAM столбцы NULL требуют, чтобы дополнительное пространство в строке сделало запись, являются ли их значения NULL. Каждый столбец NULL берет один бит дополнительно, округленный к самому близкому байту. Максимальная длина строки в байтах может быть вычислена следующим образом: длина строки = 1 + (сумма длин столбцов) + (число столбцов NULL + delete_flag + 7)/8 + (число столбцов переменной длины) delete_flag 1 для таблиц со статическим форматом строки. Статические таблицы используют бит в записи строки для флага, который указывает, была ли строка удалена. delete_flag 0 для динамических таблиц, потому что флаг сохранен в динамическом заголовке строки. Для информации о форматах таблиц MyISAM см. раздел 17.2.3. Для таблиц InnoDB размер хранения тот же самый для столбцов NULL и NOT NULL, таким образом, предыдущие вычисления не применяются. Следующий запрос, чтобы составить таблицу t1 работает, потому что столбцы требуют 32765 + 2 и 32766 + 2 байт, что в пределах максимального размера строки в 65535 байтов: mysql> CREATE TABLE t1 -> (c1 VARCHAR(32765) NOT NULL, c2 VARCHAR(32766) NOT NULL) -> ENGINE = MyISAM CHARACTER SET latin1; Query OK, 0 rows affected (0.02 sec) Следующий запрос, чтобы составить таблицу t2 терпит неудачу, потому что столбцы NULL и MyISAM требуют дополнительного пространства, которое заставляет размер строки превышать 65535 байт: mysql> CREATE TABLE t2 (c1 VARCHAR(32765) NULL, c2 VARCHAR(32766) NULL) -> ENGINE = MyISAM CHARACTER SET latin1; ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs Следующий запрос, чтобы составить таблицу t3 терпит неудачу, потому что, хотя длина столбца в пределах максимальной длины в 65535 байтов, два дополнительных байта нужны для записи длины, которая заставляет размер строки превышать 65535 байт: mysql> CREATE TABLE t3 (c1 VARCHAR(65535) NOT NULL) -> ENGINE = MyISAM CHARACTER SET latin1; ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs Сокращение длины столбца до 65533 или меньше разрешает запрос. Отдельные механизмы хранения могли бы ввести дополнительные ограничения на количество столбцов таблицы. Примеры: InnoDB разрешает до 1017 столбцов. InnoDB ограничивает размер строки немного меньше, чем половиной страницы базы данных для размеров страницы 4 КБ, 8 КБ, 16 КБ и 32 КБ. Для размера страницы 64 КБ InnoDB ограничивает размер строки приблизительно 16000 байтами. Ограничения размера строки отличаются для столбцов переменной длины (VARBINARY, VARCHAR, BLOB и TEXT). Подробности в разделе 16.8.7. Разные форматы хранения InnoDB (COMPRESSED, REDUNDANT) используют различный объем заголовков страницы и данных о метке конца, которые затрагивают объем хранения, доступного для строк. C.10.5. Ограничения в Windows Следующие ограничения применяются к использованию MySQL на платформе Windows: Память процесса В Windows 32-bit невозможно по умолчанию использовать больше 2GB RAM в пределах единственного процесса, включая MySQL. Это потому, что физическим пределом адреса на 32-битовом Windows является 4GB и настройка по умолчанию должна разделить виртуальное адресное пространство между ядром (2GB) и user/applications (2GB). У некоторых версий Windows есть опция загрузки, чтобы выделить больше памяти приложениям, уменьшая память ядра. Альтернативно, чтобы использовать больше 2GB, поставьте Windows 64-bit. Псевдонимы файловой системы Используя таблицы MyISAM, Вы не можете использовать псевдонимы в пределах ссылки Windows к файлам с данными на другом томе и ссылку назад с основным каталогом MySQL datadir. Это средство часто используется, чтобы переместить файлы с данными и индексные файлы в RAID. Ограниченное количество портов У систем Windows есть приблизительно 4000 портов, доступных для соединений клиента и после того, как соединение на порту закрывается, оно виснет на две-четыре минуты до того, как порт может быть снова использован. В ситуациях когда клиенты соединяются и разъединяются часто и много, возможно израсходовать все доступные порты прежде, чем закрытые порты станут доступными снова. Если это происходит, сервер MySQL, кажется, безразличен даже при том, что он работает. Порты могут использоваться другими приложениями, работающими на машине также, когда число портов, доступных MySQL, еще ниже. Подробности об этой проблеме http://support.microsoft.com/default.aspx?scid=kb;en-us;196271 . DATA DIRECTORY и INDEX DIRECTORY Опция DATA DIRECTORY для CREATE TABLE в Windows доступна только для таблиц InnoDB как описано в разделе раздел 16.7.5. Для MyISAM и других механизмов хранения опции DATA DIRECTORY и INDEX DIRECTORY для CREATE TABLE игнорируются в Windows и любых других платформах с атрофированным вызовом realpath(). DROP DATABASE Вы не можете удалить базу данных, которая используется другим сеансом. Нечувствительные к регистру имена Имена файлов не являются чувствительными к регистру в Windows, таким образом, имена базы данных MySQL и имена таблиц являются также не чувствительными к регистру в Windows. Единственное ограничение: имена базы данных и имена таблиц должны быть определены, используя тот же самый регистр всюду по данному запросу. См. раздел 10.2.2. Каталог и имена файла В Windows MySQL Server поддерживает только имена каталога и файла, которые совместимы с текущими кодовыми страницами ANSI. Например, следующее японское имя каталога не будет работать в Западном месте действия (кодовая страница 1252): datadir="C:/Г╖│Ц│÷Ц│║Ц│╝Ц┐≈Ц┐╜Ц┌╦Ц┌╖Ц┌╞Ц┐┬Ц│╝Ц┐┤Ц┐╪Ц┌©" То же самое ограничение относится к каталогу и именам файла, упомянутым в запросах SQL, например, путь файла с данными в LOAD DATA INFILE. Символ разделителя пути \ Компоненты пути в Windows отделены символом \, который является также символом ESC в MySQL. Если Вы используете LOAD DATA INFILE или SELECT ... INTO OUTFILE, примените имена файла стиля Unix с символом /: mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr; Альтернативно, Вы должны удвоить символ \: mysql> LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr; Проблемы с каналами Каналы не работают достоверно из командной строки Windows. Если канал включает символ ^Z / CHAR(24), Windows думает, что столкнулась с концом файла и прерывает программу. Это проблема, главным образом, когда Вы пытаетесь применить двоичный журнал следующим образом: C:\> mysqlbinlog binary_log_file | mysql --user=root Если Вы имеете проблему, применяя журнал и подозреваете, что это из-за символа ^Z / CHAR(24), Вы можете использовать следующее обходное решение: C:\> mysqlbinlog binary_log_file --result-file=/tmp/bin.sql C:\> mysql --user=root --execute "source /tmp/bin.sql" Последняя команда также может использоваться, чтобы достоверно читать любой файл SQL, который может содержать двоичные данные.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.