MySQL: руководство профессионала, Паутов Алексей В.

MySQL: руководство профессионала

на обложку

Паутов Алексей В.

Шрифт:

mysql> check table csvtest;

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

1 row in set (0.00 sec)

Проверка на разрушенной таблице возвращает неисправность:

mysql> check table csvtest;

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

1 row in set (0.01 sec)

Если сбой проверки произошел, таблица отмечена как разрушенная. Если только таблица была отмечена как разрушенная, она будет автоматически восстановлена, когда Вы затем выполняете инструкцию CHECK или SELECT. Соответствующее разрушенное состояние и новое состояние будут отображаться при выполнении CHECK:

mysql> check table csvtest;

+--------------+-------+----------+----------------------------+

+--------------+-------+----------+----------------------------+

+--------------+-------+----------+----------------------------+

2 rows in set (0.08 sec)

Для ремонта таблицы Вы можете использовать REPAIR, это скопирует так много допустимых строк из существующих CSV данных, сколько возможно, а затем заменяет существующий CSV файл на восстановленные строки. Любые строки вне разрушенных данных будут потеряны.

mysql> repair table csvtest;

+--------------+--------+----------+----------+

+--------------+--------+----------+----------+

+--------------+--------+----------+----------+

1 row in set (0.02 sec)

Предупреждение

Обратите внимание, что в течение ремонта только строки из CSV файла до первой поврежденной строки скопированы к новой таблице. Все другие строки, даже допустимые строки, до первой поврежденной строки удалены!

2.8.2. Ограничения CSV

Важно: тип памяти CSV не поддерживает индексацию.

Выделение разделов не обеспечивается для таблиц, использующих CSV. Начиная с MySQL 5.1.12, больше не возможно создать разбитую на разделы таблицу CSV (Глюк #19307).

2.9. Тип памяти BLACKHOLE

Тип памяти BLACKHOLE действует как черная дыра. Это принимает данные, но не сохраняет их. Поиски всегда возвращают пустой результат:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;

Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES(1,'record one'), (2,'record two');

Query OK, 2 rows affected (0.00 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM test;

Empty set (0.00 sec)

Тип памяти BLACKHOLE включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-blackhole-storage-engine. Чтобы исследовать исходник типа памяти BLACKHOLE, смотрите каталог sql исходных текстов MySQL.

Когда Вы создаете таблицу BLACKHOLE, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Не имеется никаких других файлов, связанных с таблицей.

Тип памяти BLACKHOLE поддерживает все виды индексов. То есть, Вы можете включать индексные объявления в определении таблицы. Вы можете проверять наличие поддержки типа памяти BLACKHOLE этой инструкцией:

mysql> SHOW VARIABLES LIKE 'have_blackhole_engine';

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

Главный пишет в свой двоичный файл регистрации. Макет mysqld обрабатывает действия как подчиненный, применяя желательную комбинацию правил replicate-do-* и replicate-ignore-* после чего пишет новый, собственный, отфильтрованный двоичный файл регистрации. Этот фильтрованный файл регистрации передается подчиненному.

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

Другие возможные использования типа памяти BLACKHOLE:

Проверка синтаксиса файла дампа.

Измерение непроизводительных затрат из двоичной регистрации, сравнивая эффективность, используя BLACKHOLE с и без двоичной регистрации.

BLACKHOLE по существу тип памяти пустой команды, так что это могло бы использоваться для нахождения критических параметров эффективности, не связанных с типом памяти непосредственно.

Начиная с MySQL 5.1.4, тип памяти BLACKHOLE знает транзакции в том смысле, что совершенные транзакции записаны в двоичный файл регистрации, а отмененные транзакции уже нет.