Comments on: MySQL processlist phrase book

By: Domas Mituzas

Domas Mituzas — Thu, 29 Oct 2009 15:47:54 +0000

David, to run your blog, mostly. :)

FT is bad argument, anyone sane may use Lucene or Sphinx for that.

Better read performance is a myth – MyISAM key cache mutex will have quite sad effects, whereas InnoDB will continue to scale with more cores, as well as InnoDB does data buffering, whereas MyISAM goes to FS all the time.

So yes, Isotopp said it – full table scans may be faster with MyISAM, but various index range reads and such will be faster with InnoDB, at high performance environments.

And if it isn’t a high performance environment, one can use whatever they want, it doesn’t matter then – and MyISAM will have smallest footprint on environment.

By: Isotopp

Isotopp — Thu, 29 Oct 2009 08:56:44 +0000

Yes, there is. Data that is not changing because it is not written to or is batch-loaded can easily be MyISAM. A regular MyISAM tables stores data in about half the space that InnoDB requires to store the same data, the actual size can vary a lot depending on a lot of factors all of which are InnoDB related.

If you care to run myisampack on your unchanging data, which you can, because it never changes, then you end up with a storage that is about 5 times smaller than the same amount of data in InnoDB.

If you need to run a full table scan on your data (which happens a lot in a DWHy environment) it may matter a lot of your query that took 20 minutes before now finishes in 4 minutes.

By: Shoan Motwani

Shoan Motwani — Thu, 29 Oct 2009 03:01:58 +0000

@David Gerard: Yes. Full text search is currently supported only in MyISAM. In addition, MyISAM has better read performance.

The key to success is in mixing and matching the storage engines leveraging the strengths of each of the them.

By: David Gerard

David Gerard — Wed, 28 Oct 2009 09:07:19 +0000

Hah!

Tell me, is there *ever* a reason to run MyISAM over InnoDB?

By: xmariachi

xmariachi — Tue, 13 Oct 2009 14:32:10 +0000

Very intersting, thanks for “translating”
Cheers

By: Ronald Bradford

Ronald Bradford — Mon, 05 Oct 2009 04:20:19 +0000

Pingback http://twitter.com/MySQLExpert/status/4620744676

By: Log Buffer #164: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #164: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 02 Oct 2009 17:22:34 +0000

[...] Domas Mituzas knows what kind of documentation we need. Here is his MySQL processlist phrase book. [...]

By: masid

masid — Wed, 30 Sep 2009 16:46:24 +0000

>> “Locked” – Even bigger chance that it is MyISAM table waiting to be converted to InnoDB

Definitely true.

By: Shlomi Noach

Shlomi Noach — Sun, 27 Sep 2009 14:03:17 +0000

Domaz,

Cool! Thanks

By: Domas Mituzas

Domas Mituzas — Sun, 27 Sep 2009 13:44:51 +0000

Shlomi,

no need to edit limits.conf, just put open_files_limit=XXXX into [mysqld] section of your my.cnf.

mysqld is started as root, will increase the resources before calling setuid().

By: Shlomi Noach

Shlomi Noach — Sun, 27 Sep 2009 13:42:25 +0000

Hi Domaz,

Not unless you edit /etc/security/limits.conf to read
“mysql – nofile 8192″ (or what number have you)
Otherwise 1024 is the default max-open-files for all users.
Please correct me if I’m wrong.

By: Domas Mituzas

Domas Mituzas — Sun, 27 Sep 2009 13:28:09 +0000

Shlomi, Linux will accept much more than 1024, if you specify –open-files-limit …

By: Shlomi Noach

Shlomi Noach — Sun, 27 Sep 2009 11:35:53 +0000

“…
“Opening table” – the idiot thread (or not that smart DBA who thinks that table_cache should be set to current value)
…”

Just don’t forget your OS is, by default, unlikely to accept higher values. Windows will limit open files to 2048, Linux by default to 1024.