JOIN Performance & Charsets
We have written before about the importance of using numeric types as keys, but maybe you've inherited a schema that you can't change or have chosen string types as keys for a specific reason. Either way, the character sets used on joined columns can have a significant impact on the performance of your queries.
Take the following example, using the InnoDB storage engine:
-
CREATE TABLE `t1` (
-
`char_id` char(6) NOT NULL,
-
`v` varchar(128) NOT NULL,
-
PRIMARY KEY (`char_id`)
-
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-
-
CREATE TABLE `t2` (
-
`id` int UNSIGNED NOT NULL AUTO_INCREMENT,
-
`char_id` char(6) NOT NULL,
-
`v` varchar(128) NOT NULL,
-
PRIMARY KEY (`id`),
-
KEY (`char_id`)
-
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
t1 has been populated with 100,000 records, while t2 has 400,000. The data set fit easily in memory.
-
mysql> EXPLAIN EXTENDED SELECT SQL_NO_CACHE COUNT(t1.char_id)
-
> FROM t1
-
> JOIN t2 USING (char_id)\G
-
*************************** 1. row ***************************
-
id: 1
-
select_type: SIMPLE
-
TABLE: t2
-
type: INDEX
-
possible_keys: NULL
-
KEY: char_id
-
key_len: 6
-
ref: NULL
-
rows: 394424
-
Extra: USING INDEX
-
*************************** 2. row ***************************
-
id: 1
-
select_type: SIMPLE
-
TABLE: t1
-
type: eq_ref
-
possible_keys: PRIMARY
-
KEY: PRIMARY
-
key_len: 18
-
ref: func
-
rows: 1
-
Extra: USING WHERE; USING INDEX
-
2 rows IN SET, 1 warning (0.00 sec)
-
-
mysql> SHOW WARNINGS\G
-
*************************** 1. row ***************************
-
Level: Note
-
Code: 1003
-
Message: SELECT sql_no_cache count(`test`.`t1`.`char_id`) AS `COUNT(t1.char_id)` FROM `test`.`t1` JOIN `test`.`t2` WHERE (`test`.`t1`.`char_id` = convert(`test`.`t2`.`char_id` USING utf8))
-
1 row IN SET (0.00 sec)
Notice the differences in key_len and the explicit call to CONVERT() in the WHERE clause. This is a result of the joined columns being of different character sets.
The above query took an average of 4.33 seconds to execute with t1 as utf8 and t2 as latin1. Converting both tables to utf8 resulted in an average execution time of 3.12 seconds and had the following EXPLAIN:
-
*************************** 1. row ***************************
-
id: 1
-
select_type: SIMPLE
-
TABLE: t1
-
type: INDEX
-
possible_keys: PRIMARY
-
KEY: PRIMARY
-
key_len: 18
-
ref: NULL
-
rows: 99414
-
Extra: USING INDEX
-
*************************** 2. row ***************************
-
id: 1
-
select_type: SIMPLE
-
TABLE: t2
-
type: ref
-
possible_keys: char_id
-
KEY: char_id
-
key_len: 18
-
ref: test.t1.char_id
-
rows: 1
-
Extra: USING INDEX
-
2 rows IN SET, 1 warning (0.00 sec)
-
-
mysql> SHOW WARNINGS\G
-
*************************** 1. row ***************************
-
Level: Note
-
Code: 1003
-
Message: SELECT sql_no_cache count(`test`.`t1`.`char_id`) AS `COUNT(t1.char_id)` FROM `test`.`t1` JOIN `test`.`t2` WHERE (`test`.`t2`.`char_id` = `test`.`t1`.`char_id`)
-
1 row IN SET (0.00 sec)
Notice here how there is no CONVERT() required and the key_len on both tables match. Just this simple change resulted in more than a 25% improvement in average execution time, from 4.33 to 3.12 seconds.
This test was performed with MySQL 5.0.67, FreeBSD 7, on a box with 2GB RAM.
del.icio.us
diggNo Comments