Обсуждение здесь описывает ограничения, которые относятся к использованию особенностей MySQL, таких как подзапросы или представления.
Эти ограничения относятся к особенностям, описанным в главе 21.
Некоторые из ограничений, отмеченных здесь, относятся ко всем сохраненным подпрограммам, то есть, к хранимым процедурам и к сохраненным функциям. Есть также некоторые ограничения, определенные для сохраненных функций, но не для хранимых процедур.
Ограничения для сохраненных функций также относятся к триггерам. Есть также некоторые ограничения, определенные для триггеров.
Ограничения для хранимых процедур также относятся к предложению
DO
определений планировщика событий.
Есть также некоторые ограничения, определенные для событий.
Сохраненные программы не могут содержать произвольные запросы SQL. Следующие запросы не разрешены:
Блокировки LOCK TABLES
и UNLOCK TABLES
.
ALTER VIEW
.LOAD DATA
и LOAD
TABLE
.PREPARE
,
EXECUTE
,
DEALLOCATE PREPARE
)
могут использоваться в хранимых процедурах, но не сохраненных функциях или
триггерах. Таким образом, сохраненные функции и триггеры не могут
использовать динамический SQL (где Вы создаете запросы как строки и
затем выполняете их).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
,
которые вызывают сохраненные функции, могут вызвать
ошибки репликации и отвергнуты.Для триггеров применяются следующие дополнительные ограничения:
Триггеры не активированы действиями внешнего ключа.
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
.
Нет никаких средств отладки сохраненных подпрограмм.
Синтаксис MySQL основан на стандарте SQL:2003. Следующие элементы этого стандарта в настоящее время не поддерживаются:
UNDO
.
FOR
.Чтобы предотвратить проблемы взаимодействия между сеансами, когда клиент делает запрос, сервер использует снимок подпрограмм и триггеров, доступный для выполнения запроса. Таким образом, сервер вычисляет список процедур, функций и триггеров, которые могут использоваться во время выполнения запроса, загружает их, а затем продолжает выполнять запрос. В то время как запрос выполняется, он не видит изменений подпрограмм, выполненных другими сеансами.
Для максимального параллелизма сохраненные функции должны минимизировать свои побочные эффекты: в частности обновление таблицы в пределах сохраненной функции может уменьшить параллельные операции на этой таблице. Сохраненная функция приобретает табличные блокировки перед выполнением, чтобы избежать несогласованности в двоичном журнале из-за несоответствия порядка, в котором запросы выполняются с тем, когда они появляются в журнале. Когда основанный на запросе двоичное журналирование используется, зарегистрированы запросы, которые вызывают функцию, а не запросы, которые выполнены в пределах функции. Следовательно, сохраненные функции, которые обновляют те же самые основные таблицы, не выполняются параллельно. Напротив, хранимые процедуры не приобретают блокировки на уровне таблицы. Все запросы, выполненные в пределах хранимых процедур, записаны в двоичный журнал, даже для основанного на запросе двоичного журналирования. См. раздел 21.7.
Следующие ограничения являются определенными для планировщика событий:
Имена событий обработаны нечувствительным к регистру способом.
Например, у Вас не может быть двух событий в той же самой базе данных с
именами anEvent
и AnEvent
.
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).ON SCHEDULE
запросов
CREATE EVENT
и
ALTER EVENT
не поддержаны. Эти
виды ссылок не разрешены (см. Bug #22830).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 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
.
Вообще, Вы не можете изменить таблицу и выбрать из той же самой таблицы в подзапросе. Например, это ограничение относится к запросам следующих форм:
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] INtable_subquery
Но это не поддержано:
(expr_1
, ...,expr_n
)op
{ALL|ANY|SOME}subquery
Причина поддержки сравнений строки для IN
,
но не для других: IN
осуществлен, переписывая это как
последовательность сравнений =
и операций AND
.
Этот подход не может использоваться для ALL
,
ANY
или SOME
.
FROM
не могут быть коррелированными
подзапросами. Они осуществлены полностью (оценены, чтобы произвести набор
результатов) во время выполнения запроса, таким образом, они не могут быть
оценены на строку внешнего запроса. Оптимизатор задерживает материализацию,
пока результат не необходим, что может разрешить избежать материализации.
См. раздел 9.2.1.18.3.
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'
f()
вставляет строки, следующий запрос
может изменить данные:
SELECT ... WHERE x IN (SELECT f() ...);
Это поведение расширение к стандарту SQL. В MySQL это может привести к
неопределенным результатам потому, что f()
может быть выполнена
различное число раз для разного выполнения данного запроса в зависимости от
того, как оптимизатор хочет обрабатывать это.
Для основанной на запросе или смешанной репликации одно значение этого в том, что такой запрос может привести к различным результатам на ведущем устройстве и его ведомых устройствах.
Обработка представления не оптимизирована:
Невозможно создать индекс на представлении.
Есть общий принцип, что Вы не можете изменить таблицу и выбрать из той же самой таблицы в подзапросе. См. раздел 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 символа.
Это может вызвать проблемы при следующих обстоятельствах для представлений со
слишком длинными псевдонимами:
Определения представления не в состоянии копироваться на более новые ведомые устройства, которые проводят в жизнь ограничение длины.
Обходное решение для этой проблемы должно изменить каждое проблематичное
определение представления, чтобы использовать псевдонимы, которые
обеспечивают более короткие имена столбцов. Тогда представление будет
копировать должным образом, и может быть выведено и перезагружено, не вызывая
ошибку. Чтобы изменить определение, удалите и пересоздайте представление
снова с помощью DROP VIEW
и
CREATE VIEW
или замените
определение с помощью
CREATE OR REPLACE VIEW
.
Для проблем, которые происходят, перезагружая определения представления в
файлах дампа, есть другое обходное решение: отредактировать файл дампа, чтобы
изменить запрос CREATE VIEW
.
Однако, это не изменяет оригинальные определения представления, которые могут
вызвать проблемы для последующих операций дампа.
Операционная поддержка 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
), сервер и двоичный
журнал правильно восстановлены и взяты в последовательное состояние. Однако,
если есть катастрофический отказ в середине выполнения одного из этих
запросов, сервер, возможно, не в состоянии вернуться в правильное состояние.
relay-log-info-repository=TABLE
.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 не могла копироваться правильно.
Идентификаторы, сохраненные в базе данных 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
работают побайтно, таким образом, они не безопасны для мультибайтных символов
и могут привести к неожиданным результатам с многобайтовыми наборами
символов. Кроме того, эти операторы сравнивают символы по их значения байта,
и акцентированные символы, возможно, не сравниваются как равные, даже если
данное сопоставление обрабатывает их как равные.
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
, этот таймер не поддержан на Вашей платформе.
Инструменты, которые относятся к механизмам хранения, не могли бы быть осуществлены для всех механизмов хранения. Инструментовка каждого имеющего отношение к третьей стороне механизма ответственность автора механизма.
Первая часть этого раздела описывает общие ограничения на применимость структуры аутентификации, описанной в разделе 7.3.9. Вторая часть описывает, как имеющие отношение к третьей стороне разработчики могут определить степень, до которой плагин может использовать в своих интересах возможности аутентификации.
Термин нативная авторизация, используемый здесь,
относится к аутентификации по паролям, сохраненным в таблице
mysql.user
. Это прежний метод аутентификации, обеспеченный более
старыми серверами MySQL, прежде, чем аутентификация плагинами была
осуществлена. Это остается методом по умолчанию, хотя теперь это
осуществлено, используя плагины. Нативная авторизация Windows
обращается к аутентификации, используя авторизацию пользователя, который
уже вошел в систему к Windows, как осуществлено плагином Windows Native
Authentication (Windows plugin для краткости).
Connector/C, Connector/C++: Клиенты, которые используют эти соединители, могут соединить с сервером только через учетные записи с нативной авторизацией.
Исключение: соединитель поддерживает плагиновую аутентификацию, если он
был собран с libmysqlclient
динамически (а не статически) и
загружает текущую версию libmysqlclient
, если эта версия
установлена, или если соединитель повторно собран из исходных текстов
для компоновки с текущей libmysqlclient
.
libmysqlclient
вместо MySQL 5.1
libmysqlclient
. Более новая libmysqlclient
включает клиентскую поддержку, необходимую для стороны сервера
PAM и Windows plugin.mysqlnd
).libmysqlclient
, это доступно по умолчанию. Иначе плагин должен
быть установлен на ведомой стороне в каталоге, названном переменной
plugin_dir
на ведомом устройстве.FEDERATED
: Таблица
FEDERATED
может получить доступ к удаленной таблице только через учетные записи на
удаленном сервере с нативной авторизацией.Имеющие отношение к третьей стороне разработчики соединителя могут использовать следующие направляющие линии, чтобы определить готовность соединителя использовать в своих интересах плагиновую аутентификацию:
Существующий соединитель, в котором никакие изменения не были произведены использует нативную авторизацию и клиенты, которые используют соединитель, могут соединиться с сервером только через такие учетные записи. Однако, Вы должны проверить соединитель против недавней версии сервера, чтобы проверить, что такие соединения все еще работают без проблем .
Исключение: соединитель мог бы работать с плагиновой аутентификацией без
любых изменений, если он компонуется с libmysqlclient
динамически (а не статически) и загружает текущую версию
libmysqlclient
, если эта версия установлена.
libmysqlclient
, должен быть перекомпонован с
текущей версией libmysqlclient
. Это позволяет соединителю
поддержать соединения, хотя учетные записи, которые требуют клиентских
плагинов, теперь созданных в libmysqlclient
(такие как плагин открытого текста, необходимый для аутентификации PAM
и Windows plugin для аутентификации Windows). Компоновка с текущей
libmysqlclient
позволяет соединителю получить доступ к
клиентским плагинам, установленным в каталог плагинов MySQL (как правило,
каталог по умолчанию локального сервера, указанный в переменной
plugin_dir
).
Если соединитель компонуется с libmysqlclient
динамически,
должна быть обеспечена наиболее новая версия libmysqlclient
на хосте клиента. Соединитель загружает ее во время выполнения.
--plugin-dir
. См.
раздел 25.8.14.Этот раздел перечисляет текущие лимиты в MySQL 8.0.
Максимальное количество таблиц, на которые можно сослаться в единственном
соединении, 61. Это включает соединение, обработанное, сливая полученные
таблицы (подзапросы) и представления в предложении FROM
во внешнем блоке запроса (см.
раздел 9.2.1.18.3).
Это также относится к числу таблиц, на которые можно
сослаться в определении представления.
У MySQL нет никакого предела числа баз данных. У основной файловой системы может быть предел числа каталогов.
У MySQL нет никакого предела числа таблиц. У основной файловой системы
может быть предел числа файлов, которые представляют таблицы. Отдельные
механизмы хранения могут наложить определенные для механизма ограничения.
InnoDB
разрешает до 4 миллиардов таблиц.
Эффективный максимальный табличный размер для баз данных 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 TABLEtbl_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 FROMdb_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.
MERGE
, которая позволяет Вам
обработать набор таблиц MyISAM
, у которых есть идентичная
структура, как единую таблицу MERGE
. См.
раздел 17.7.MEMORY
(HEAP
). В этом случае Вы должны увеличить значение переменной
max_heap_table_size
. См. раздел 6.1.5
.Есть жесткий предел 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
)
используют различный объем заголовков страницы и данных о метке конца,
которые затрагивают объем хранения, доступного для строк.
Следующие ограничения применяются к использованию 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 .
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, который может содержать двоичные данные.