开发者

MySQL - basic 2 table query slow - where, index?

开发者 https://www.devze.com 2023-01-27 17:05 出处:网络
I have a MySQL 5.0 query regularly taking 14+ seconds, called from a web page, and users are impatient. It\'s fairly simple, selecting 11 columns from 2 tables. I have three questions:

I have a MySQL 5.0 query regularly taking 14+ seconds, called from a web page, and users are impatient. It's fairly simple, selecting 11 columns from 2 tables. I have three questions:

  1. Does placement of join matter?
  2. Does order of where clause matter, or will MySQL optimize?
  3. Would and index help in my case?

sql:

select table1.id, table1.DateOpened, table1.Status, table2.Name, etc
from (table1 join table2 on((table1.CurrentName = table2.id))) 
where table1.Type = 'Add' and (Status = 'Open' OR Status = 'Pending');

table/column info:

table1 has 750,000 rows, table2 1.5M rows.
indexed: table1.id, table2.id
INT columns: id, table1.CurrentName
table1.Status = always populated with 1 of 4 values, 
 开发者_运维百科               maybe 300 are 'Open' or 'Pending'
table1.Type = 3 possible values: 'Add', 'Change', or null
  1. Is there any advantage JOINing in the FROM, vs adding 'table1.CurrentName = table2.id' in the WHERE clause?

  2. There are 3 WHERE clauses (with the join). I ran EXPLAIN with various order combinations, and results seemed to be the same.

  3. I thought adding an index to table1.CurrentName may help, but now I'm thinking not. I modified the query to remove references to table2, and it still ran slow. (see 3b)

  4. Seems like the bulk of the slowdown may be just reading 800K records looking at the Type and Status values. Does it make sense to index these two columns, where there are only 3 or 4 possible values? I thought it only made sense when there were more unique values.

explain results:

+----+-------------+--------+--------+---------------+---------+---------+-----------------------+--------+-------------+ 
| id | select_type | table  | type   | possible_keys | key     | key_len | ref                   | rows   | Extra       |         
+----+-------------+--------+--------+---------------+---------+---------+-----------------------+--------+-------------+ 
|  1 | SIMPLE      | table1 | ALL    | CurrentName   | NULL    | NULL    | NULL                  | 733190 | Using where | 
|  1 | SIMPLE      | table2 | eq_ref | PRIMARY       | PRIMARY | 4       | db.table1.CurrentName | 1      |             | 
+----+-------------+--------+--------+---------------+---------+---------+-----------------------+--------+-------------+ 
2 rows in set (0.00 sec)


Does placement of join matter?

The order they are written does not matter for INNER JOINs.

Does order of where clause matter, or will MySQL optimize?

No. The written order in a WHERE clause does not matter to the MySQL query parser and optimizer

Would and index help in my case?

Potentially. A compound index type_status (Type, Status) on table1 could help since that is where your WHERE clause could reduce the initial rows read.

Is there any advantage JOINing in the FROM, vs adding 'table1.CurrentName = table2.id' in the WHERE clause?

For INNER JOINs, it doesn't matter if the JOIN condition is in the FROM clause or the WHERE clause.

I thought adding an index to table1.CurrentName may help, but now I'm thinking not. I modified the query to remove references to table2, and it still ran slow. (see 3b)

An index on table1.CurrentName would not help the query.

Seems like the bulk of the slowdown may be just reading 800K records looking at the Type and Status values.

This reinforces my thought above. To add the compound index (potentially not a good thing to do online), it'd be something like

ALTER TABLE table1 ADD INDEX type_status (Type, Status);

I thought it only made sense when there were more unique values.

Selectivity definitely helps, but high cardinality is not the only suitable context.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号