7.6.4 Характеристики таблиц BDB

• Чтобы обеспечить возможность отката транзакций, для таблиц BDB поддерживается ведение файлов журналов. Для достижения максимальной производительности эти файлы необходимо разместить на разных с базой данных дисках, воспользовавшись параметром --bdb_log_dir.
• Каждый раз, когда создается новый файл журнала BDB, MySQL устанавливает контрольные точки и удаляет все файлы журналов, которые не нужны для текущих транзакций. Можно также в любое время запустить команду FLUSH LOGS, чтобы установить контрольную точку для таблиц Berkeley DB. Чтобы произвести восстановление после сбоя, необходимо воспользоваться резервными копиями таблицы, а также бинарным журналом MySQL (see section 4.4.1 Резервное копирование баз данных). Предупреждение: если удалить используемые старые файлы журналов, BDB не сможет осуществить восстановление, и в случае сбоя вы можете потерять данные.
• В MySQL все таблицы BDB должны иметь первичные ключи, чтобы обеспечить возможность обращаться к ранее считанным строкам. Если первичный ключ не создан, MySQL создаст его и будет поддерживать скрытый первичный ключ. Длина скрытого ключа составляет 5 байтов, а его значение увеличивается при каждой попытке вставки.
• Если все столбцы, к которым производится обращение в таблице BDB, являются частью одного индекса или одного первичного ключа, то MySQL может выполнить запрос, не обращаясь к самой строке. Для таблиц MyISAM это справедливо только если столбцы являются частью одного индекса.
• Первичный ключ обеспечивает более быструю обработку, чем любой другой ключ, так как он хранится вместе с данными строки. Поскольку остальные ключи хранятся как данные ключа + PRIMARY KEY, очень важно иметь как можно более короткие первичные ключи, чтобы сэкономить дисковое пространство и увеличить производительность.
• Команда LOCK TABLES работает с таблицами BDB точно так же, как и с другими таблицами. Если команда LOCK TABLE не используется, MySQL устанавливает на таблицу внутреннюю множественную блокировку записи, чтобы обеспечить правильную блокировку, если другой поток установит блокировку таблицы.
• Внутренняя блокировка в таблицах BDB осуществляется на уровне страниц.
• Команда SELECT COUNT(*) FROM table_name выполняется медленно, так как для таблиц BDB не поддерживается подсчет количества строк в таблице.
• Сканирование осуществляется медленнее, чем в таблицах MyISAM, так как данные в таблицах BDB хранятся в B-деревьях, а не в отдельных файлах данных.
• Приложение всегда должно быть готово к обработке ситуаций, в которых любые изменения таблицы BDB могут привести к автоматическому откату и любое считывание может вызвать сбой из-за возникновения взаимоблокировки.
• Сжимаемые ключи не присоединяются к предыдущим ключам, как в таблицах ISAM или MyISAM. Иначе говоря, информация по ключам в таблицах BDB займет несколько больше места по сравнению с таблицами MyISAM, в которых не используется параметр PACK_KEYS=0.
• В таблице BDB всегда имеются промежутки, благодаря чему можно вставлять новые строки в середину дерева ключа. Из-за этого таблицы BDB несколько больше, чем таблицы MyISAM.
• Оптимизатору необходимо знать приблизительное количество строк в таблице. В MySQL этот вопрос решается путем подсчета количества вставок и поддержки этой информации в отдельном сегменте каждой таблицы BDB. Если операторов DELETE или ROLLBACK выполнялось не слишком много, это количество должно быть достаточно точным для оптимизатора MySQL, но MySQL сохраняет это число только при закрытии, и оно в случае аварийного завершения работы MySQL может оказаться неверным. Если число не соответствует действительности на 100% - ничего страшного в этом нет. Количество строк можно обновить, запустив команду ANALYZE TABLE или OPTIMIZE TABLE (см. разделы section 4.5.2 Синтаксис команды ANALYZE TABLE и see section 4.5.1 Синтаксис команды OPTIMIZE TABLE).
• Если таблица BDB займет все пространство на диске, то будет выведено сообщение об ошибке (возможно, ошибка 28) и выполнен откат транзакции. В отличие от BDB, таблицы MyISAM и ISAM в mysqld будут ожидать, пока не появится свободное место, а потом продолжат работу.

User Comments

Sorry, I don't understand why one should use BDB instead of InnoDB. You say table scan is slow, COUNT(*) is slow, more space is required... I don't see any advantage!

Transactions support! :)

What one could question though is why one would want to use BDB now when we have InnoDB. InnoDB, which like BDB provides MySQL with a transactions capable storage engine, seems to be fast, come with more features, and it's obviously also more widely supported by MySQL AB.

Add your own comment.