At 09:10 PM 4/7/2010, you wrote:
>Also depends on your data access pattern as well.
>If you can take advantage of clustering my primary key for your
>selects, then InnoDB could do it for you.
>My suggestion would be to write some queries based on projected
>workload, build 2 tables with lots and lots of data, and do some
>isolated testing. For work, I do a lot of query profiling using
>maatkit. Be sure to clear out as much of the caching as possible
>including the OS cache.
In a related topic, does anyone know how well InnoDb is going to perform if
you have a 250 million row table (100gb) and only 8gb of RAM? It was my
understanding that InnoDb needed to fit as much of the table into memory as
it could for it to be fast. Also, how long is it going to take to load 250
million rows (using Load Data InFile) compared to a MyISAM table? I've
always found InnoDb to be incredibly slow at loading large amounts of data
and nothing I could think of would speed things up. I too would like to
switch to InnoDb but until I can solve these problem I'm sticking with
MyISAM for large tables.
>On Mon, Apr 5, 2010 at 7:25 AM, Jan Steinman <Jan@stripped> wrote:
> >> From: Gavin Towey <gtowey@stripped>
> >> InnoDB should be your default for all tables, unless you have specific
> >> requirements that need myisam. One specific example of an appropriate
> >> for myisam is where you need very high insert throughput, and you're not
> >> doing any updates/deletes concurrently.
> > A couple other things: InnoDB does relations better, MyISAM does search of
> > text fields.
> > ----------------
> > If we can control fuel we can control the masses; if we can control food we
> > can control individuals. -- Henry Kissinger
> > :::: Jan Steinman, EcoReality Co-op ::::
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>MySQL General Mailing List
>For list archives: http://lists.mysql.com/mysql
>To unsubscribe: http://lists.mysql.com/mysql?unsub=1