Optimize running time of MySQL query - mysql

Question

There is a table users with primary key as user_id and an indexed column called verified.
Another table user_profile has PK as profile_id and FK as user_id and has a column - name
Now, I need to find all verified users and their names. so i need to join these 2 tables on user_id -
Query becomes -
select p.name from user_profile p inner join user u on p.user_id = u.user_id
where u.verified = 1;
There are 700000 records in profile table and same number of records in user table. This query above takes 13 seconds to run. Please let me know, how can I optimize the running time.
MySQL version 5.5 , YII
EDIT
CREATE TABLE IF NOT EXISTS `tbl_profile` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL,
`regyear` int(4) DEFAULT NULL,
`firstname` varchar(128) NOT NULL,
`gender` varchar(10) NOT NULL,
`occupation` int(5) NOT NULL,
`street` varchar(255) DEFAULT NULL,
`state` int(10) DEFAULT NULL,
`city` int(10) DEFAULT NULL,
`zip` int(10) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`),
KEY `state` (`state`),
KEY `firstname` (`firstname`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=626494 ;
--
-- Table structure for table tbl_user
CREATE TABLE IF NOT EXISTS `tbl_user` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`email` varchar(255) DEFAULT NULL,
`password` varchar(128) NOT NULL,
`createtime` int(10) NOT NULL DEFAULT '0',
`lastvisit` int(10) NOT NULL DEFAULT '0',
`status` int(1) NOT NULL DEFAULT '0',
`verified` int(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`),
KEY `status` (`status`),
KEY `verified` (`verified`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=626494 ;
Output of EXPLAIN SELECT - I have written same query as above but substituting 999 for 1 and using column status instead of verified, which is equivalent to problem statement.
EXPLAIN SELECT p.firstname
FROM tbl_profile p
INNER JOIN tbl_user u ON p.user_id = u.id
WHERE u.status =999
+----+-------------+-------+------+----------------+---------+---------+-------------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+----------------+---------+---------+-------------+--------+-------------+
| 1 | SIMPLE | u | ref | PRIMARY,status | status | 4 | const | 313333 | Using index |
| 1 | SIMPLE | p | ref | user_id | user_id | 4 | newone.u.id | 1 | |
+----+-------------+-------+------+----------------+---------+---------+-------------+--------+-------------+

Answer 1

Suggestion 1
Adding an index on (user_id, first_name) will improve efficiency of this specific query:
ALTER TABLE tbl_profile
ADD INDEX user_id_first_name_IX -- just a name for the index
(user_id, first_name) ;
But if you also have similar queries, where you are selecting other columns, you'll need more indexes like this. And adding 5-10 indexes in the table is not too bad (it will only slow your inserts a bit.) But adding too many indexes will be harmful in the end.
Suggestion 2
If every user has maximum of 1 profile, then there is no need to have an auto-incrementing id in table profiles. I suggest you drop that column and make the user_id the primary key. I would also make that a foreign key as well:
ALTER TABLE tbl_profile
DROP PRIMARY KEY,
DROP COLUMN id,
ADD CONSTRAINT profile_PK
PRIMARY KEY (user_id),
ADD CONSTRAINT user_profile_FK
FOREIGN KEY (user_id)
REFERENCES tbl_user (id) ;
This is far better than suggestion 1, as you will basically make the user_id the clustered index of the table. Any query that uses user_id for a join on this table will be able to use this (primary and clustered) index.

Answer 2

You may gain a performance improvement by moving the condition into the join's ON clause:
select p.name
from user_profile p
join user u on p.user_id = u.user_id and u.verified = 1;
This reason it may perform better is that the WHERE clause is evaluated after all rows are joined - it's a filter on the result set. However the ON condition is evaluated as the join is being made, so there is a possibility that the database will have to deal with a lot less rows, and thus a lot less memory/resources.
Other than that change, I can't see anything else you could do.