MySQL slow queries with rows sent/examined equal to 0

I have a Rails (v.2.3.8) application with a MySQL database. In the slow query log on the database server, there are a large number of entries such as:

# Query_time: 3.471884  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 0
use prod;
SET timestamp=1312909843;
SELECT * FROM `pages` WH开发者_开发问答ERE (`pages`.`controller` = 'forum_categories' AND `pages`.`action` = 'show')  LIMIT 1;

Note that the query time is 3.47 seconds, while the number of rows sent and examined are both 0. When I run this same query using the MySQL client (both on the MySQL server and on the application server), I get a result in less than 100ms. All necessary table fields are indexed and there are only 70 records in the table. Any idea why these long-running, seemingly useless queries would be running?

Thanks.

---

Here’s an example from a slow query log:

1 # Time: 030303 0:51:27
2 # User@Host: root[root] @ localhost []
3 # Query_time: 25 Lock_time: 0 Rows_sent: 3949 Rows_examined: 378036
4 SELECT ...

Line 1 shows when the query was logged, and line 2 shows who executed it. Line 3 shows how many seconds it took to execute, how long it waited for table locks at the MySQL server level (not at the storage engine level), ...

Be careful not to read too much into the slow query log. If you see the same query in the log many times, there’s a good chance that it’s slow and needs optimization. But just because a query appears in the log doesn’t mean it’s a bad query, or even necessarily a slow one. You may find a slow query, run it yourself, and find that it executes in a fraction of a second. Appearing in the log simply means the query took a long time then; it doesn’t mean it will take a long time now or in the future. There are many reasons why a query can be slow sometimes and fast at other times:
• A table may have been locked, causing the query to wait. The Lock_time indi- cates how long the query waited for locks to be released.
• The data or indexes may not have been cached in memory yet. This is common when MySQL is first started or hasn’t been well tuned.
• A nightly backup process may have been running, making all disk I/O slower.
• The server may have been running other queries at the same time, slowing down this query.
As a result, you should view the slow query log as only a partial record of what’s happened. You can use it to generate a list of possible suspects, but you need to investigate each of them in more depth.

The data were quoted from the book: “High Performance MySQL: Optimization, Backups, Replication, and More, Second Edition, by Baron Schwartz et al. Copyright 2008 O’Reilly Media, Inc., 9780596101718.”

---

Do you have index key on column pages.controller and pages.action?

The table might have a lot of entries, and thus query needs 3.47 secs to look for the correct row one by one if you don't implement index key.