Архив метки: mysql

Конвертируем MyISAM в InnoDB

Очень старая (2005 год) статья от Петра Зайцева (Percona) о конвертировании  MyISAM таблиц в InnoDB

http://peter-zaitsev.livejournal.com/6154.html

Are there any performance benefits with Innodb tables when ? Yes there are, even if you forget about support
of transactions, row level locking and consistent reads. Innodb tables are clustered by PRIMARY KEY. This
means a lot of overhead for writes but PRIMARY KEY reads could be twice as fast compared to MyISAM tables for
disk bound loads. To retrieve the row by PRIMARY KEY MyISAM normally needs 2 reads, while Innodb only one.
If you have table small enough to fit in memory there are more benefits — Innodb caches both data and index
in memory, while MyISAM caches only index, using OS cache for caching data, which means Innodb can have much
better performance especially for Random IO (joins), moreover Innodb builds hash indexes in the buffer pool based on
BTREE indexes, which speeds up lookups even further. This all makes Innodb up to 3 times faster for some heavy join
queries, when data is in memory. Even if tables do not fit in memory you get asynchronous read-ahead and asynchronous
dirty buffers flush which is helpful in some cases.

 

СУБД-шечка #1

Репликация из MySQL в Tarantool

Интересный кейс использования Tarantool вместо MySQL-сервера. Репликатор имеет свои ограничения и особенности, надеемся он продолжит развиваться. Видео

Запомнилось: в MySQL 5.7 нет и не будет режима handler socket

MySQL на стеройдах

Кратко описана история создания и развития MySQL-сревера. Покупка SUN-ом, далее покупка Oracle.

Рассматриваются актуальные на тот момент (2011 год) форки MySQL. Более полное описание форков

Uber Причины перехода с Postgres на MySQL

Перевод довольно нашумевшей статьи.

Запомнилось: MySQL в индексе хранит ссылку на pk таблички (id), postgres в индексе хранит адрес на диске

Про MySQL 5.7

Небольшая выжимка от нашей команды об изменениях в версии 5.7 на основе двух докладов.

Обязательно посмотрите сами доклады!

MySQL. InnoDB. COUNT.

Думаю многие упирались в скорость отработки COUNT при работе с MySQL и InnoDB таблицами.

Мы уже даже привыкли с этим жить и нашли костыли способы как с этим бороться.

Почитывая блог «перконы» наткнулся на объяснение такого поведения, виной всему MVCC:

This is pretty common request which is of high priority as soon as I know. It is however not as trivial as it sounds as Innodb is multi versioning engine so each transaction could see different amount of rows in the table which needs extra handling. Not what it is impossible just not as trivial as you’re saying.

At this poing if you have no holes in your primary key and it goes from one select max(id) is frequently good and fast way to get the count. You also could use counter table especially now with Triggers in MySQL 5.0

Yes I know it is ugly but we have to live with what we have ?