In this case (because bar1 can be NULL) innodb will create its internal primary key which is not exposed on the top level. That primary key will be when used for reference from unique keys.
If bar1 would be NOT NULL the first unique key would be in fact primary key.

you say that all other keys will refer to the rows by primary key.

What about if the table doesn’t have a primary key, e.g. a table with columns:
– foo NOT NULL
– bar1 NULL
– bar2 NULL
UNIQUE (foo, bar1)
UNIQUE (foo, bar2)
?

These methods fix it, but I’m not entirely sure of the repercussions:

1) select id from view.MediumTextView order by id limit 10
2) select id from view.MediumTextView force index (primary) limit 10
3) select id from view.MediumTextView where id > ”

Perhaps the optimizer is finding the most compact storage location of primary keys? If it uses the clustered index, it has to load all the leaf data pages (avg ~1kb in this table), and parse out the ids. But if it uses the secondary index, it’s much fewer data pages to parse through.

Is there a good method for creating a secondary index that’s optimized for selecting large ranges of ids? Theoretically, you could make a zero-field b-tree index, which would then just be a huge list of primary keys, but i’m not sure you can do that. What about an index on a bit field where all rows have the same bit value?

It would be interesting to see your thoughts on low cardinality indexes and short-prefix indexes resulting in low cardinality. What happens if I have a 5 million row table with an index on a true/false column? Does it form two large trees of primary keys? Or is it some inefficient list structure.

I guess i better stop now… thanks

1) this table has previously been converted to MyISAM and back to InnoDB, but has been modified much since then

2) the primary keys all start with the same 18 latin1 characters, and maybe the primary key is only indexed to 10 characters? If this is the case, what does the internal data storage structure look like?

The problem is that the table is about 3.6 million rows, and I do range selects that pull about 300,000 ids at a time. If they’re not in order, I’m not sure I’ll get the correct id’s, and I can’t add an “order by id” clause because that will hurt performance too much.

Further, I can’t find any way to assert an index’s prefix length on MySQL 5.1. It does not display in a “show create table” statement nor a “show index from” nor a “describe table” statement!

Here is example output without and with an “order by id” clause:

—————————————

select id from view.MediumTextView limit 10

modelQuadTokens_1_030233102111321211233320001_23260356_RealtyTrac
modelQuadTokens_1_021333011030113102211010101_23264578_RealtyTrac
modelQuadTokens_1_023101030110202002021310021_23265168_RealtyTrac
modelQuadTokens_1_023012311310002011100033022_23258199_RealtyTrac
modelQuadTokens_1_023012311312130313023213020_23265583_RealtyTrac
modelQuadTokens_1_023012311103021221232131110_23258157_RealtyTrac
modelQuadTokens_1_023013210320212220101012001_23256624_RealtyTrac
modelQuadTokens_1_023012130130003202121231312_23256294_RealtyTrac
modelQuadTokens_1_023012130102300210002011120_23256413_RealtyTrac
modelQuadTokens_1_023010203333201133300002301_23266647_RealtyTrac

select id from view.MediumTextView order by id limit 10

modelQuadTokens_1_002231332112003321210202031_1279355_LandWatch
modelQuadTokens_1_002231332112003321210202031_253830_LandWatch
modelQuadTokens_1_002302203000032102223033220_GZ14768_Worldspan
modelQuadTokens_1_003222003112121300202000120_WV0932_Worldspan
modelQuadTokens_1_020010301121310313312101300_2266695_Point2
modelQuadTokens_1_020010301221110133133221233_1733075_Point2
modelQuadTokens_1_020010301221110133133221233_1809187_Point2
modelQuadTokens_1_020010301221110133133221233_1863296_Point2
modelQuadTokens_1_020010301221110133133223011_1477083_Point2
modelQuadTokens_1_020010320312133200303333333_1698538_Point2
————————-

I have some workarounds, but It’s strange that I can’t find many others having a similar problem.

Have you ever encountered this?

Matt