需要太多時間的Mysql查詢

我有關於mysql數據庫的問題。我是Linux的web服務器管理員，我面臨着一個MySQL查詢的問題。數據庫非常小。我試圖跟蹤日誌，發現查詢至少需要5秒才能做出迴應。網站的第一頁來自數據庫。客戶正在使用cms。當服務器獲得一定數量的命中時，數據庫服務器開始非常緩慢地響應並等待時間從5秒增加到幾秒。需要太多時間的Mysql查詢

我檢查慢速查詢日誌

{ 
Query_time: 11.480138 Lock_time: 0.003837 Rows_sent: 921 Rows_examined: 3333 

SET timestamp=1346656767; 
SELECT `Tender`.`id`, 
    `Tender`.`department_id`, 
    `Tender`.`title_english`, 
    `Tender`.`content_english`, 
    `Tender`.`title_hindi`, 
    `Tender`.`content_hindi`, 
    `Tender`.`file_name`, 
    `Tender`.`start_publish`, 
    `Tender`.`end_publish`, 
    `Tender`.`publish`, 
    `Tender`.`status`, 
    `Tender`.`createdBy`, 
    `Tender`.`created`, 
    `Tender`.`modifyBy`, 
    `Tender`.`modified` 
FROM `mcms_tenders` AS `Tender` 
WHERE `Tender`.`department_id` IN (31, 33, 32, 30); 
}

在日誌中的每一行是相同的只是有在查詢的時間差異。有什麼辦法可以調整性能嗎？

更新：這裏是EXPLAIN結果：

+----+-------------+--------+------+---------------+------+---------+------+-‌-----+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+--------+------+---------------+------+---------+------+----‌--+-------------+ 
| 1 | SIMPLE  | Tender | ALL | NULL   | NULL | NULL | NULL | 3542 | Using where | 
+----+-------------+--------+------+---------------+------+---------+------+----‌--+-------------+ 
1 row in set, 1 warning (0.00 sec)

客戶是說他們使用的指數，所以我跑的命令檢查索引。

我得到以下輸出。這是否意味着他們正在使用索引。

+ -------------- + ------------ + ---------- + ------ -------- + ------------- ----------- + + ------------ + - -------- + -------- + ------ + ------------ + --------- + |表| Non_unique | Key_name | Seq_in_index | Column_name |整理|基數| Sub_part |包裝|空| Index_type |評論| + -------------- + ------------ + ---------- + --------- ----- + ------------- ----------- + ------------- + + ---- ------ + -------- + ------ + ------------ + --------- + | mcms_tenders | 0 | PRIMARY | 1 | id | A | 4264 | NULL | NULL | | BTREE | | + -------------- + ------------ + ---------- + --------- ----- + ------------- ----------- + ------------- + + ---- ------ + -------- + ------ + ------------ + --------- +

來源

2012-09-10 aditya

嘗試使用EXPLAIN並檢查查詢是否使用索引等。 – j0nes

使用'EXPLAIN EXTENDED'來代替。爲您提供更多信息。 –

@ j0nes @ Rene Pot + ---- + ------------- + -------- + ------ + --------- ------ + ------ + --------- + ------ + ------ + ------------ - + | id | select_type |表| |鍵入| possible_keys |鍵| key_len | ref |行|額外| + ---- + ------------- + -------- + ------ + ------------- - + ------ + --------- + ------ + ------ + ------------- + | 1 | SIMPLE |招標| ALL | NULL | NULL | NULL | NULL | 3542 |使用where | + ---- + ------------- + -------- + ------ + ------------- - + ------ + --------- + ------ + ------ + ------------- + 1行集，1個警告（0.00秒） – aditya

「當服務器獲得一些命中數」

定義「某個數字」。當數據庫使用率更高時，讀取數據庫的速度會更慢。另外，MySQL有一個查詢緩存，在對數據進行更改時完全無效。因此，每當有人在此表中插入，刪除或修改記錄時，下一個查詢將會變慢，因爲表格日期仍未解壓縮。

但是，對於像這樣的查詢來說，11秒是非常緩慢的，所以無論是負載太高，硬件不足或損壞，或者你的數據庫缺乏索引（我總是忘記提及，因爲我假設添加索引對於任何使用數據庫的人來說都是第二天性）。

來源

2012-09-10 09:38:15 GolezTrol

數量從253變化到521.if我檢查進程列表中所有正在運行的查詢都同樣喜歡我在任何上面的查詢不存在貼。我不知道爲什麼mysql查詢緩存不工作。它肯定沒有人正在修改，只有選擇查詢正在工作。由於我不是開發人員，能否請您提出我們可以做些什麼 – aditya

@ GolezTrol硬件很好，因爲它的配置是48核心cpu和64 GB RAM。儘管其他共享託管站點的其他數據庫運行良好。 – aditya

共享主機讓它變得艱難。可能是在該服務器上運行的數百萬個數據庫。你怎麼知道的？但首先檢查索引。他們查詢本身很簡單，但由於在where子句中使用了'department_id'，該列上的索引可能會嚴重加速查詢。只有開始尋找其他地方，如果這不能解決問題。 – GolezTrol

像這樣調整查詢性能的常規方法是在department_id上創建一個索引。

但是，這個假定Tenders實際上是一張表而不是一個視圖。您應該確認這一點，因爲問題可能在視圖中。

此外，從您描述的問題可能是從服務器到最終用戶的連接。我會嘗試在服務器上本地運行查詢（或嚴格檢查服務器上的執行時間），以查看查詢是否確實需要很長時間。

來源

2012-09-10 14:00:09

@ Gordon Linoff。如果我在本地服務器上運行它，同樣的時間。儘管我已經增加了查詢緩存大小。並解決了問題。另外，我會告訴客戶在任何可能的地方使用索引。非常感謝 – aditya

需要太多時間的Mysql查詢

回答

相關問題