MySQL very slow with 20 Million Records -
doing simple query
select state, count(state) cnt big_data status=0 group state
takes 20 seconds. here table def:
create table `newtable` (`id` bigint(22) not null auto_increment , `city` varchar(32) character set latin1 collate latin1_swedish_ci not null , `state` varchar(2) character set latin1 collate latin1_swedish_ci not null , `miles_away` int(5) not null , `member_id` int(11) not null , `gender` varchar(17) character set latin1 collate latin1_swedish_ci not null , `profile` varchar(128) character set latin1 collate latin1_swedish_ci not null , `status` varchar(1) character set latin1 collate latin1_swedish_ci not null , primary key ( `id`, `city`, `state`, `miles_away`, `member_id`, `gender`, `profile`, `status`), unique index `id` (`id`) using btree , unique index `profile` (`profile`) using btree , index `city` (`city`) using btree , index `state` (`state`) using btree , index `miles_away` (`miles_away`) using btree , index `member_id` (`member_id`) using btree , index `gender` (`gender`) using btree , index `status` (`status`) using btree) engine=innodb default character set=latin1 collate=latin1_swedish_ci auto_increment=12889691 row_format=compact;
even simple id lookup based on primary key takes long. server has 72 cores (4th gen xeon es2690 64gb ram)
here screenshot of explain:
multi threads http://gaysugardaddyfinder.com/shot.png
help!
use explain
show execution plan.
reference: https://dev.mysql.com/doc/refman/5.5/en/using-explain.html
for best performance, provide suitable index optimizer can avoid "using file sort" operation satisfy group by
.
i'd suggest:
create index `newtableix1` on `newtable` (`status`,`state`)
(i suggest because query includes equality predicate on status
column, , performing group operation on state
column. new index, i'd expect explain
output show it's using new index, , show query being satisfied entirely index -- "using index" shown in column of explain output.)
with new index defined, separate index on status
column redundant, , can dropped.
followup
since id
unique , not null, serve primary key table. there's no need primary key include every column in table. (the secondary indexes going large table itself, since primary key going stored in each index "pointer" cluster index.)
if table, i'd replace this:
primary key ( `id`, `city`, `state`, `miles_away`, `member_id`, `gender`, `profile`, `status`), unique index `id` (`id`) using btree ,
with this:
primary key (`id`)
(i'd create new table, , copy data old table.)
Comments
Post a Comment