|
MySQL.RU - Webboard
 Вернуться
 InnoDB кто сталкивался? (Quad) 24/10/2001 - 13:49:28
 Re: InnoDB кто сталкивался? (walrus) 24/10/2001 - 14:27:05
Re: InnoDB кто сталкивался? (Quad) 24/10/2001 - 14:34:04
Re: InnoDB кто сталкивался? (walrus) 24/10/2001 - 14:40:10
Re: InnoDB кто сталкивался? (Quad) 24/10/2001 - 15:25:25
Re: InnoDB кто сталкивался? (Maxim) 25/10/2001 - 13:33:15
> Original message text:
> From: Quad - 24/10/2001 - 13:49:28
> Subject:InnoDB кто сталкивался?
> -----------------
> Hi ALL!
>
> Откликнитесь кто сталкивался с InnoDB?
> Кто объяснит: пишут, что оно должно быть быстрее чем myISAM, а у меня получается наоборот.... :(
>
> ХЕЛП!
>
From: walrus - 24/10/2001 - 14:40:10
Subject:InnoDB кто сталкивался?
-----------------
Это я отвечает..
Но если надо кого-нибудь повесомее, то вот пожалуйста из
maillist комментарий Михаэля Видениуса, по кличке Monti,
основного разработчика mysql:
I have
just the following to comment about this discussion:
Thanks to versioning, Innodb should be faster than MyISAM when you
have a very high write/update/select conflicts where any of the
statement could take a significant long time.
When it comes to other usage, InnoDB is faster in some cases and
MyISAM is faster in other cases.
To understand the reason for most major speed difference one should
understand how data is stored in the different table handlers:
In MyISAM indexes are stored in one file and data is stored in another
file. This means that all index are equally and that table scanning
is fast (as we can do this sequentially). To fetch a row we have
first to look in the index file (if we are using index) and then fetch
the row, based on a file offset, from the data file.
In InnoDB, the primary key and the row is stored together. Other keys
are stored as the new key + the primary key. This means that fetch on
the primary key is probably faster than in MyISAM (because we don't
have to do a separate fetch of the data). Using secondary keys are
much slower, because they row has to be looked up through the primary
key. Using 'big rows' will also decrease performance (compared to
MyISAM) as you get room for less data in the tree leafs.
There are many other differences (transactional overhead, locking
overhead, compressed keys, different buffering, different optimization
algorithms) that comes in play when one compares the two database
handlers and there is no definitive winner; It's trivial to do a test
that shows that either table handler is much better than the other.
The simply truth is that the table handler complements each other and
it's depending on how the application works which is better.
I hope that the new benchmark page will make it easy for anyone to
decide which table type is most suitable for them for each table.
Regards,
Monty
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
474
|
|
