Читаем (и пишем) MyISAM напрямую

[HighOctane]

Как быть если MySQL сервер на другом физическом сервере?

[youROCK]

Если у вас есть доступ к ФС (и к файлам MySQL) на этом сервере, то я не вижу большой проблемы. Если же такого доступа нет, то можете попробовать использовать HANDLER (вместо SELECT) и LOAD DATA LOCAL INFILE (вместо INSERT). Но достичь такой же производительности, как если писать напрямую, не получится

[Ackrite]

Начало статьи обнадежило меня увидеть хоть какие-то цифры. Ан нет…

[youROCK]

Надеюсь, так лучше

[snevsky]

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

[zizop]

я как-то обнаружил упоминание о том, что в случае, если используется MyISAM, можно получить прирост в скорости чтения из таблицы в 5-7 раз, если читать данные из таблицы самостоятельно

Скажите пожалуйста, а вы сравнивали скорость с HandlerSocket или Handler interface? Думается мне, они быстрее будут, т.к. читают из памяти.

[Ackrite]

> Думается мне, они быстрее будут, т.к. читают из памяти.
Handler Interface читает из стораджа, который может быть полностью загружен в память, но необязательно.

[snevsky]

а вы сравнивали скорость с HandlerSocket?

Хотелось бы увидеть цифры для:
— последовательного чтения — full scan
— произвольного чтения — index search
и сравнить их с прямыми NoSQL аналогами: HandlerSocket и memcached plugin от innoDB.
А то вроде бы начало за здравие, а в финале никаких сравнительных характеристи, может это велосипед…

[Nichola]

> 3. Сам по себе FULL SCAN в MyISAM работает в 5-10 раз быстрее, чем скан по индексу с таким же числом записей.

вот это не понятно. Нет ли какой ошибки в том где _поиск записей_ быстрее.

Если ошибки нет, то хотелось бы услышать подробней про методику сравнения: какая операция делалась = что такое «скан» по индексу, как получалось её среднее время?

[youROCK]

Допустим, у нас есть таблицы: tbl1 и tbl2
В таблице tbl2 содержится таблица tbl1 + содержится индекс на одном из полей (скажем, на поле field)

Для таблицы tbl1 делается запрос

SELECT * FROM tbl1 WHERE (условие, отсекающее 100% строк)

Для tbl2 делается такой же запрос:

SELECT * FROM tbl2 WHERE (условие, отсекающее 100% строк) ORDER BY field

Количество просмотренных строк будет одинаковое, а вот порядок выполнения — разный. В первом случае это будет обычный FULL SCAN, а во втором случае — скан по индексу (можно дополнительно поставить FORCE INDEX(field) для второго случая, чтобы никаких сомнений не осталось).
Разница по времени исполнения для этих запросов составляет 5-10 раз для обычного (незатюненного) MyISAM, в буфер ключей которого этот индекс помещается, и таблицы полностью помещаются в кеш ФС

[Nichola]

Спасибо,
понял, что ошибки нет, пойду читать
dev.mysql.com/doc/refman/5.5/en/optimization.html :)

[eexo]

Ошибки тут нет. Суть в том что при full scan происходит sequential read, т.е бошка винчестера идет подряд по секторам и не дергается. Индекс в этом примере фактически используется для выполнения сортировки, т.е _поиска_ по индексу не происходит, и происходит чтение всех записей. Поэтому во втором случае sequential read происходит только для индекса, а для чтения самих записей используется random read.
Т.к кластерных индексов в myisam нет, то бошка винчестера скачет туда-сюда, и из-за этого full index scan _в этом_ случае занимет гораздо больше времени. Кроме того, во втором случае больше информации читается с диска чем в первом.

Если бы во втором примере скан индекса использовался для поиска записей, то какая-то часть их была бы отсеена (т.е небыло бы некоторых random reads) и разница времени выполнения была бы другая.

[snevsky]

Полное сканирование по индексу всегда медленнее за исключением индексно организованных таблиц, читай любой таблицы иннодб. Там каждая таблица это индекс. Любой индекс отвергается оптимизатором если надо сканировать более 10%.