緩慢的查詢與類似的位置，排序和限制

Question

我遇到了一個查詢的速度問題，我不想做。 房間表中有2685588行，而room_active小於100，但對於普通查詢來說速度並不慢。

查詢是：

SELECT rooms.*, room_active.active_users 
FROM rooms LEFT JOIN room_active ON (room_active.roomid = rooms.id) 
WHERE caption LIKE '%room%' ORDER BY room_active.active_users LIMIT 50 

運行：4.3s

它需要5秒以上來執行時，它應該不到一個喜歡做這一個：

SELECT rooms.*, room_active.active_users 
FROM rooms LEFT JOIN room_active ON (room_active.roomid = rooms.id) 
WHERE caption LIKE '%room%' LIMIT 50 

運行時間：0.3s

的描述第一個查詢是這樣的：

+----+-------------+-------------+--------+----------------+---------+---------+----------------+---------+----------------------------------------------+ 
| id | select_type | table  | type | possible_keys | key  | key_len | ref   | rows | Extra          | 
+----+-------------+-------------+--------+----------------+---------+---------+----------------+---------+----------------------------------------------+ 
| 1 | SIMPLE  | rooms  | ALL | NULL   | NULL | NULL | NULL   | 2210576 | Using where; Using temporary; Using filesort | 
| 1 | SIMPLE  | room_active | eq_ref | PRIMARY,roomid | PRIMARY | 4  | xukys.rooms.id |  1 | NULL           | 
+----+-------------+-------------+--------+----------------+---------+---------+----------------+---------+----------------------------------------------+ 

指標：

+-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| rooms |   0 | PRIMARY  |   1 | id   | A   |  2210613 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | owner  |   1 | owner  | A   |  2210613 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | roomtype |   1 | roomtype | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | caption  |   1 | caption  | A   |  2210613 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | category |   1 | category | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | users_now |   1 | users_now | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | tags  |   1 | tags  | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | users_max |   1 | users_max | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | description |   1 | description | A   |  368435 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | state  |   1 | state  | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | model_name |   1 | model_name | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | public_ccts |   1 | public_ccts | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | score  |   1 | score  | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | password |   1 | password | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | icon_bg  |   1 | icon_bg  | A   |   954 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | icon_fg  |   1 | icon_fg  | A   |   18 | NULL  | NULL |  | BTREE  |   |    | 
| rooms |   1 | badge_id |   1 | badge_id | A   |   804 | NULL  | NULL |  | BTREE  |   |    | 
+-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
+-------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table  | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+-------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| room_active |   0 | PRIMARY  |   1 | roomid  | A    |   116 | NULL  | NULL |  | BTREE  |   |    | 
| room_active |   0 | roomid  |   1 | roomid  | A   |   116 | NULL  | NULL |  | BTREE  |   |    | 
| room_active |   1 | active_users |   1 | active_users | A   |   29 | NULL  | NULL |  | BTREE  |   |    | 
+-------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 

Answer 1

的ORDER BY被移除的LIMIT 50優勢，因爲能夠通過他對50個第一要素訂購獲取所有記錄。

也許如果你告訴我們你想要什麼，我們可以幫助查詢。例如，你是否真的需要做一個LEFT JOIN，並讓所有沒有room_active的房間？

不知道是否有幫助，但試試這個

SELECT rooms.*, room_active.active_users 
FROM room_active ra JOIN rooms r ON (room_active.roomid = rooms.id) 
WHERE r.caption LIKE '%room%' ORDER BY ra.active_users LIMIT 50 

將忽略不具有room_active房間，降低了提取的記錄

Answer 2

1，你可能想也許在指數命令？

2你不需要％room％嗎？房間％會更快，你有效地搜索所有文件，如果你不

3如果你可以，只有想要活躍？而不是內連接，因爲它需要較少的連接（它不連接那些空連接）

4不要選擇*除非需要？

5.也許你可以使用一個不同的充功能，例如包含，如果你使用的是Oracle

6.將指數說明它是搜索質量也許這就是問題

Answer 3

按照下面的步驟和檢查性能。

1. 在字段'caption'上爲其前4個字符和'active_users'創建索引。
2. 而不是「rooms。*」，顯式選擇字段。
3. 使用「caption LIKE'room％'」而不是「caption LIKE'％room％'」。

如果這仍然很慢，您應該爲您的聯接查詢創建一個視圖，然後在視圖上執行簡單的select語句。