By: Michael Mior

Michael Mior — Mon, 07 Nov 2011 14:32:56 +0000

I can’t recall the data model, but I have encountered a situation where MySQL would not use an index prefix and a separate index on just the first column produced a vastly different (and superior) query plan.

As I said, I don’t really recall anything about the data, but I’m curious to know if anyone else has experienced this in practice.

By: Xaprb

Xaprb — Mon, 01 Aug 2011 20:31:40 +0000

Shashidhar, this is an example of when the query might touch so many columns that you need to use a trick such as the type that Peter Zaitsev calls a “delayed join”, which you can see here: http://www.mysqlperformanceblog.com/2007/04/06/using-delayed-join-to-optimize-count-and-limit-queries/

You might also be interested in this book: http://www.xaprb.com/blog/2010/09/19/a-review-of-relational-database-design-and-the-optimizers-by-lahdenmaki-and-leach/

By: Shashidhar

Shashidhar — Mon, 01 Aug 2011 07:08:22 +0000

Well, First of all I have to say thanks for such a nice article.

But I have small questions to clarify here with you. I hope this thread is still alive, and author is there to listen (hopefully).

When you say -
“For MyISAM, put the columns in the WHERE clause first in the index, then add the columns named in the SELECT clause at the end.”

say, I have a table(tableA) with 50 columns and couple of them have index’s (single/individually). But selection is based on something like this
1. select tableA.col1, tableA.col2,tableA.col3, tableA.col4, tableA.col5,tableA,col6, tableA,col7, tableA.col8, tableA.col9, tableA.col10 from tableA where col15= AND col16=

In this scenario, and after your suggestion, I understand I have to create index on (col15, col16, col1,col2,col3…col10) Correct?

But this seems to be huge index? My doubt, how true is your statement for huge tables (with more columns, specially?)

Could you please clarify my doubt please?

Cheers in advance,

Shashidhar

By: toto

toto — Mon, 24 Jan 2011 00:59:02 +0000

> Since InnoDB secondary indexes already contain all columns from the primary key,
> there’s no need to add them to the secondary index unless the index needs them at the front of the index.
> In particular, adding an index on (price, variety) to the apples table above is completely redundant.

I don’t think so. (I know, this article have been written long time ago.)

I created table like below.
—————————————————————————————-
CREATE TABLE tab_lsu (
fdpk1 char(10) NOT NULL,
fdpk2 char(10) NOT NULL,
fd3 char(10) DEFAULT NULL,
fd4 char(10) DEFAULT NULL,
PRIMARY KEY (fdpk1,fdpk2),
KEY ix_fd3_fdpk1_fdpk2 (fd3,fdpk1,fdpk2),
KEY ix_fdpk1_fd3 (fdpk1,fd3),
KEY ix_fd3 (fd3)
) ENGINE=InnoDB DEFAULT ROW_FORMAT=COMPACT — // (and also test REDUNDANT ROW_FORMAT)
—————————————————————————————-

InnoDB’s table monitor print out like this
—————————————————————————————-
INDEX: name ix_fd3_fdpk1_fdpk2, id 0 978, fields 3/3, uniq 3, type 0
root page 4, appr.key vals 16030, leaf pages 39, size pages 97
FIELDS:
fd3
fdpk1
fdpk2

INDEX: name ix_fdpk1_fd3, id 0 979, fields 2/3, uniq 3, type 0
root page 5, appr.key vals 15991, leaf pages 39, size pages 97
FIELDS:
fdpk1
fd3
fdpk2

INDEX: name ix_fd3, id 0 980, fields 1/3, uniq 3, type 0
root page 6, appr.key vals 15991, leaf pages 39, size pages 97
FIELDS:
fd3
fdpk1
fdpk2
—————————————————————————————-

And I dumped these 3 index’s pages. (all 3 index have only one index page)
(But index’s page contents never changed when index pages is greater than 2)

—————————————————————————————-
ix_fd3_fdpk1_fdpk2

[root@toto:~/temp/innodb-recovery-0.3/result/pages-1295763380/0-978]$ hexdump -v -C 4-00000004.page
00000000 0d 19 f0 3c 00 00 00 04 ff ff ff ff ff ff ff ff |..<….|
00000010 00 00 00 03 aa b4 02 15 45 bf 00 00 00 00 00 00 |….E…|
00000020 00 00 00 00 01 ef 00 0a 07 05 80 29 00 00 00 00 |……….)….|
00000030 06 e3 00 02 00 26 00 27 00 00 00 00 00 00 00 00 |….&.'……..|
00000040 00 01 00 00 00 00 00 00 03 d2 00 00 01 ef 00 00 |…………..|
00000050 00 02 02 72 00 00 01 ef 00 00 00 02 01 b2 01 00 |…r……..

00000060 02 00 1e 69 6e 66 69 6d 75 6d 00 08 00 0b 00 00 |…infimum……|
00000070 73 75 70 72 65 6d 75 6d 0a 0a 0a 00 10 00 11 00 |supremum……..|
00000080 2b 46 44 33 23 23 23 23 23 23 23 50 4b 31 23 23 |+FD3#######PK1##|
00000090 23 23 23 23 23 50 4b 32 23 23 23 23 23 23 23 00 |#####PK2#######.|
000000a0 00 00 0a 0a 0a 0a 00 00 00 19 00 2b 46 44 33 30 |………..+FD30|
000000b0 30 30 30 32 30 35 50 4b 31 30 30 30 30 32 30 35 |000205PK10000205|
000000c0 50 4b 32 30 30 30 30 32 30 35 00 00 00 0b 0a 0a |PK20000205……|
000000d0 0a 00 00 00 21 00 2b 46 44 33 30 30 30 30 36 31 |….!.+FD3000061|
000000e0 36 50 4b 31 30 30 30 30 36 31 36 50 4b 32 30 30 |6PK10000616PK200|
000000f0 30 30 36 31 36 00 00 00 11 0a 0a 0a 00 04 00 29 |00616……….)|
00000100 00 2b 46 44 33 30 30 30 31 30 32 37 50 4b 31 30 |.+FD30001027PK10|
00000110 30 30 31 30 32 37 50 4b 32 30 30 30 31 30 32 37 |001027PK20001027|
00000120 00 00 00 15 0a 0a 0a 00 00 00 31 00 2b 46 44 33 |……….1.+FD3|
00000130 30 30 30 31 34 33 38 50 4b 31 30 30 30 31 34 33 |0001438PK1000143|
00000140 38 50 4b 32 30 30 30 31 34 33 38 00 00 00 1a 0a |8PK20001438…..|
—————————————————————————————-

—————————————————————————————-
ix_fdpk1_fd3

[root@toto:~/temp/innodb-recovery-0.3/result/pages-1295763380/0-979]$ hexdump -v -C 5-00000005.page
00000000 0b f0 fa 66 00 00 00 05 ff ff ff ff ff ff ff ff |….|
00000010 00 00 00 03 aa b4 03 01 45 bf 00 00 00 00 00 00 |….E…|
00000020 00 00 00 00 01 ef 00 0a 07 05 80 29 00 00 00 00 |……….)….|
00000030 06 e3 00 02 00 26 00 27 00 00 00 00 00 00 00 00 |….&.'……..|
00000040 00 01 00 00 00 00 00 00 03 d3 00 00 01 ef 00 00 |…………..|
00000050 00 02 03 f2 00 00 01 ef 00 00 00 02 03 32 01 00 |………..2..|
00000060 02 00 1e 69 6e 66 69 6d 75 6d 00 08 00 0b 00 00 |…infimum……|
00000070 73 75 70 72 65 6d 75 6d 0a 0a 0a 00 10 00 11 00 |supremum……..|
00000080 2b 50 4b 31 23 23 23 23 23 23 23 46 44 33 23 23 |+PK1#######FD3##|
00000090 23 23 23 23 23 50 4b 32 23 23 23 23 23 23 23 00 |#####PK2#######.|
000000a0 00 00 0c 0a 0a 0a 00 00 00 19 00 2b 50 4b 31 30 |………..+PK10|
000000b0 30 30 30 32 30 35 46 44 33 30 30 30 30 32 30 35 |000205FD30000205|
000000c0 50 4b 32 30 30 30 30 32 30 35 00 00 00 0d 0a 0a |PK20000205……|
000000d0 0a 00 00 00 21 00 2b 50 4b 31 30 30 30 30 36 31 |….!.+PK1000061|
000000e0 36 46 44 33 30 30 30 30 36 31 36 50 4b 32 30 30 |6FD30000616PK200|
000000f0 30 30 36 31 36 00 00 00 12 0a 0a 0a 00 04 00 29 |00616……….)|
00000100 00 2b 50 4b 31 30 30 30 31 30 32 37 46 44 33 30 |.+PK10001027FD30|
00000110 30 30 31 30 32 37 50 4b 32 30 30 30 31 30 32 37 |001027PK20001027|
00000120 00 00 00 16 0a 0a 0a 00 00 00 31 00 2b 50 4b 31 |……….1.+PK1|
00000130 30 30 30 31 34 33 38 46 44 33 30 30 30 31 34 33 |0001438FD3000143|
00000140 38 50 4b 32 30 30 30 31 34 33 38 00 00 00 1b 0a |8PK20001438…..|
—————————————————————————————-

—————————————————————————————-
ix_fd3
[root@toto:~/temp/innodb-recovery-0.3/result/pages-1295763380/0-980]$ hexdump -v -C 6-00000006.page
00000000 1d 9d 1b 81 00 00 00 06 ff ff ff ff ff ff ff ff |……..|
00000010 00 00 00 03 aa b4 03 ed 45 bf 00 00 00 00 00 00 |….E…|
00000020 00 00 00 00 01 ef 00 0a 07 05 80 29 00 00 00 00 |……….)….|
00000030 06 e3 00 02 00 26 00 27 00 00 00 00 00 00 00 00 |….&.'……..|
00000040 00 01 00 00 00 00 00 00 03 d4 00 00 01 ef 00 00 |…………..|
00000050 00 02 05 72 00 00 01 ef 00 00 00 02 04 b2 01 00 |…r……..
00000060 02 00 1e 69 6e 66 69 6d 75 6d 00 08 00 0b 00 00 |…infimum……|
00000070 73 75 70 72 65 6d 75 6d 0a 0a 0a 00 10 00 11 00 |supremum……..|
00000080 2b 46 44 33 23 23 23 23 23 23 23 50 4b 31 23 23 |+FD3#######PK1##|
00000090 23 23 23 23 23 50 4b 32 23 23 23 23 23 23 23 00 |#####PK2#######.|
000000a0 00 00 0e 0a 0a 0a 00 00 00 19 00 2b 46 44 33 30 |………..+FD30|
000000b0 30 30 30 32 30 35 50 4b 31 30 30 30 30 32 30 35 |000205PK10000205|
000000c0 50 4b 32 30 30 30 30 32 30 35 00 00 00 0f 0a 0a |PK20000205……|
000000d0 0a 00 00 00 21 00 2b 46 44 33 30 30 30 30 36 31 |….!.+FD3000061|
000000e0 36 50 4b 31 30 30 30 30 36 31 36 50 4b 32 30 30 |6PK10000616PK200|
000000f0 30 30 36 31 36 00 00 00 13 0a 0a 0a 00 04 00 29 |00616……….)|
00000100 00 2b 46 44 33 30 30 30 31 30 32 37 50 4b 31 30 |.+FD30001027PK10|
00000110 30 30 31 30 32 37 50 4b 32 30 30 30 31 30 32 37 |001027PK20001027|
00000120 00 00 00 17 0a 0a 0a 00 00 00 31 00 2b 46 44 33 |……….1.+FD3|
00000130 30 30 30 31 34 33 38 50 4b 31 30 30 30 31 34 33 |0001438PK1000143|
00000140 38 50 4b 32 30 30 30 31 34 33 38 00 00 00 1c 0a |8PK20001438…..|
00000150 0a 0a 00 00 00 39 00 2b 46 44 33 30 30 30 31 38 |…..9.+FD300018|
00000160 34 39 50 4b 31 30 30 30 31 38 34 39 50 4b 32 30 |49PK10001849PK20|
00000170 30 30 31 38 34 39 00 00 00 21 0a 0a 0a 00 00 00 |001849…!……|
—————————————————————————————-

And all dumped result are same whether row_format is REDUNDANT or COMPACT ( have not test baracuda file format yet.)

So, I think,
"INDEX (not_pk_column + pk_column1 + pk_column2)" and "INDEX (not_pk_column)" index have same internal structure.
the only different thing is second index have only 1 user defined index column, but first case have 3 user defined index column.

And "INDEX (pk_column1 + not_pk_column + pk_column2)" and "INDEX (pk_column1 + not_pk_column)" are same.

Finally (If this is right),
Index columns are same whether I defined or not trailing primary key columns, I think first case is better than second case.
In Second case, other people cannot notice that the creator really expected appended primary key for sort or group by or else.
For example,
If table's index is "INDEX (fd1)", you can't tell the creator of index want "INDEX (fd1 + fd_pk)" or "INDEX(fd1)".
But, in this case the index is created with "INDEX (fd1 + fd_pk)", then we can tell this index's Primary key column is also used
for searching or grouping or sorting…

What do you think about this. ?

By: Munnabhai [Dhanashree Inc]

Munnabhai [Dhanashree Inc] — Thu, 18 Nov 2010 12:58:23 +0000

Nice Help.. Thanks

Comments on: How to exploit MySQL index optimizations

By: Michael Mior

By: Xaprb

By: Shashidhar

By: toto

By: Munnabhai [Dhanashree Inc]