Comments on: Obscure MySQL variable explained: max_seeks_for_key

By: Larry Siden

Larry Siden — Sat, 02 Oct 2010 00:10:31 +0000

Thanks for that great post. I referenced it from my own blog: http://westside-consulting.blogspot.com/2010/10/getting-mysql-to-use-indexes.html.

By: Franck

Franck — Tue, 09 Mar 2010 15:11:00 +0000

r I C h, thanks a bunch !
Just when I was considering giving up, I came across your post which gave me the solution. Stupid me !
I

By: r I C h

r I C h — Fri, 13 Mar 2009 04:23:34 +0000

This falls in the category of "i'm an idiot", but when you're looking up on a varchar column, make sure you put the lookup in quotes. eg (if 'reg_id' is a varchar): GOOD: "select name from user where reg_id='1234567'" BAD: "select name from user where reg_id=1234567" Not doing so will force the MySQL optimizer to do a full table scan, and no amount of 'force index' or 'max_seeks_for_key' will fix that.

By: dbnewz » Blog Archive » Cardinalité, sélectivité et distributivité d’un index MySQL : quel impact sur le plan d’exécution ?

Thu, 04 Sep 2008 22:37:43 +0000

[...] Sachez qu’il existe une variable serveur, max_seeks_for_key (on en parle aussi ici et là) sur laquelle il est possible de jouer pour orienter les choix de [...]

By: Georgi Kodinov

Georgi Kodinov — Fri, 31 Aug 2007 12:06:09 +0000

hmm : the formula is :
max_seeks_for_key = / .

Stupid HTML

By: Georgi Kodinov

Georgi Kodinov — Fri, 31 Aug 2007 12:04:45 +0000

Indeed the documentation is not very clear about what max_seeks_for_key is.
Actually it's not the cardinality. It is the number of rows you'll find for a unique value of the key.
So this makes it :
max_seeks_for_key = / .
What limiting max_seeks_for_key means ? This means that it will still consider indexes that have very low cardinality to be considered otherwise.
This is why it's not 1000 by default, but rather is set to the MAX_INT, so it can leave the optimizer to decide based on the statistics that it has.