Разработку и сопровождение MySQL

• BDB-таблицы - Gamma

Код Berkeley DB очень устойчив, но на настоящий момент продолжается усовершенствование интерфейса обработчика транзакционных BDB-таблиц с MySQL, поэтому должно пройти некоторое время, пока он будет так же хорошо протестирован, как и таблицы других типов.

• Полнотекстовый поиск - Beta

Полнотекстовый поиск работает, но широко не используется. В версии MySQL 4.0 реализованы существенные улучшения  данной возможности.

• MyODBC 2.50 (использующий ODBC SDK 2.5) - Gamma

Чрезвычайно широко используется. Как  оказалось, некоторые из возникших  проблем являются зависящими от приложения, а не от ODBC-драйвера или сервера  баз данных.

• Aвтоматическое восстановление MyISAM-таблиц - Gamma

Статус Gamma относится только к новому коду в обработчике таблиц, который проверяет правильность закрытия таблицы после ее открытия и выполняет автоматическую проверку/восстановление незакрытой таблицы.

• Вставка больших объемов данных - Alpha

Новая возможность в MyISAM-таблицах в MySQL 4.0 для быстрой вставки большого количества строк.

• Блокировка - Gamma

В большой степени зависит от системы. В некоторых системах возникают  большие проблемы с использованием стандартной для ОС блокировки (fcntl()). В таких случаях следует запустить демон mysqld с флагом --skip-external-locking. Известно, что проблемы имеют место в некоторых системах Linux и в SunOS, когда используются NFS-монтированные файловые системы.

Несмотря на то, что высококвалифицированную  поддержку MySQL AB обеспечивает за плату, в списке рассылки MySQL обычно можно получить ответы на часто возникающие вопросы. Ошибки обычно ликвидируются сразу же при помощи патчей, а серьезные дефекты почти всегда устраняются в новом выпуске.

1.4.4. Насколько большими  могут быть таблицы в MySQL?

MySQL версии 3.22 имеет предел по размеру таблиц 4 Гб. В MySQL версии 3.23, где используется новый тип таблиц, максимальный размер таблицы доведен до 8 миллионов терабайтов (2 ^ 63 bytes).

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

Операционная система	Ограничения на размеры файла
32-разрядная Linux-Intel	2Гб, 4Гб и более, в зависимости  от версии Linux
Linux-Alpha	8T (?)
Solaris 2.5.1	2 Гб (с патчем возможно 4Гб)
Solaris 2.6	4Гб (может быть изменено при  помощи указания флага)
Solaris 2.7 Intel	4 Гб
Solaris 2.7 UltraSPARC	512 Гб

В Linux 2.2 существует возможность создавать  таблицы с размерами более 2 Гб, используя патч LFS для файловой системы ext2. Существуют также патчи, обеспечивающие поддержку больших файлов для ReiserFS в Linux 2.4.

Как можно видеть, размер таблицы  в базе данных MySQL обычно лимитируется операционной системой.

По умолчанию MySQL-таблицы имеют  максимальный размер около 4 Гб. Для  любой таблицы можно проверить/определить ее максимальный размер с помощью команд SHOW TABLE STATUS или myisamchk -dv table_name. See Раздел 4.5.6, «Синтаксис команды SHOW».

Если необходимы таблицы большего размера, чем 4 Гб (и используемая операционная система ``не возражает''), следует при  создании такой таблицы задать параметры AVG_ROW_LENGTH и MAX_ROWS (see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»). Эти параметры можно задать и позже - с помощью ALTER TABLE (see Раздел 6.5.4, «Синтаксис оператора ALTER TABLE»).

Если большая таблица предназначена  только для чтения, можно воспользоваться myisampack, чтобы слить несколько таблиц в одну и сжать ее. Обычно myisampack ужимает таблицу по крайней мере на 50%, поэтому в результате можно получить очень большие таблицы (see Раздел 4.7.4, «myisampack, MySQL-генератор сжатых таблиц (только для чтения)»).

Есть еще одна возможность обойти ограничения операционной системы  на размеры файлов данных MyISAM, - это делается при помощи опции RAID(see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»).

Еще одним решением может быть использование функции MERGE, которая обеспечивает возможность обрабатывать набор идентичных таблиц как одну таблицу (see Раздел 7.2, «Таблицы MERGE»).

1.4.5. Вопросы, связанные  с Проблемой-2000

Сам MySQL не имеет проблем, связанных  с Проблемой-2000 (Y2K):

• В MySQL используются функции времени Unix, поэтому проблемы с датами, вплоть до 2069, исключены. Принимается, что все двузначные значения годов находятся в диапазоне с 1970 по 2069, поэтому число 01 в столбце с типом year MySQL обрабатывает как 2001.
• Все MySQL-функции, обрабатывающие даты, хранятся в одном файле sql/time.cc. Их код был написан очень тщательно, чтобы застраховаться от проблем, связанных с 2000-м годом.
• В версиях MySQL 3.22 и более поздних в столбцах с новым типом YEAR, который обеспечивает хранение нулевого 0 года и значений лет от 1901до 2155 в одном байте, а также отображение дат при помощи 2 или 4 знаков.

Проблемы, связанные с 2000-м годом, могут возникнуть в приложениях, которые используют MySQL так, что это может оказаться небезопасным с точки зрения Y2K. Например, во многих старых приложениях для хранения и обработки значений годов используются 2-значные величины (которые можно трактовать неоднозначно), а не 4-значные. Эта проблема может быть урегулирована при помощи приложений, которые используют 00 или 99как ``отсутствующие'' индикаторы значений.

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

Приведенный ниже код является наглядной  демонстрацией того, что в MySQL Server проблемы с датами вплоть до 2030 года отсутствуют.

mysql> DROP TABLE IF EXISTS y2k;

Query OK, 0 rows affected (0.01 sec)

 

mysql> CREATE TABLE y2k (date DATE,

    -> date_time DATETIME,

    -> time_stamp TIMESTAMP);

Query OK, 0 rows affected (0.00 sec)

 

mysql> INSERT INTO y2k VALUES

    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),

    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),

    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),

    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),

    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),

    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),

    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),

    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),

    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),

    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),

    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),

    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),

    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);

Query OK, 13 rows affected (0.01 sec)

Records: 13 Duplicates: 0 Warnings: 0

 

mysql> SELECT * FROM y2k;

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

| date | date_time | time_stamp |

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

| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |

| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |

| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |

| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |

| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |

| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |

| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |

| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |

| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |

| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |

| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |

| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |

| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |

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

13 rows in set (0.00 sec)

 

Можно видеть, что при использовании типов DATE и DATETIME проблем с датами будущего не возникнет (эти типы ``справляются'' с датами вплоть до 9999 года).

Тип TIMESTAMP, который используется для сохранения текущего времени, имеет диапазон только до 2030-01-01. В 32-разрядных машинах TIMESTAMPтип имеет диапазон от 1970 до 2030 (значение со знаком). В 64-разрядных машинах этот тип ``справляется'' со значениями времени до 2106 года (значение без знака).

Таким образом, даже несмотря на то, что MySQL является Y2K-совместимым, ответственность за однозначную интерпретацию значений даты ложится на плечи пользователя. See Раздел 6.2.2.1, «Проблема 2000 года и типы данных», где приведены правила по работе MySQL с входными данными, которые имеют неоднозначные значения даты (данные, содержащие 2-значные значения года).