可以在大型數據庫上導致我的長查詢掛起mysqldump？

我有一個大型數據庫（大約50GB）。它在我無法控制的服務器上，但我知道他們每晚都在使用mysqldump進行備份。可以在大型數據庫上導致我的長查詢掛起mysqldump？

我有一個查詢需要幾個小時才能完成。我將它設置爲運行，但它實際上並未完成。我注意到，在備份時間之後，所有表都有一個鎖請求（SHOW OPEN TABLES WHERE in_use> 0;列出所有表）。

從我的查詢中的表有IN_USE = 2，其他所有表有IN_USE = 1

所以......這裏發生了什麼？ a）我的查詢正常運行，阻止轉儲發生。我應該等待？ b）轉儲導致服務器掛起（可能缺少內存/磁盤空間？） c）別的東西？

編輯：使用MyISAM表

有一個服務器管理員誰也不是很能幹的，但如果我問他具體的事情他做他們。我應該讓他檢查什麼？

編輯：添加查詢

SELECT citing.article_id as citing, citing.year, r.id_when_cited, cited_issue.country 
FROM isi_lac_authored_articles as citing # 1M records 
     JOIN isi_citation_references r ON (citing.article_id = r.article_id) # 400M records 
     JOIN isi_articles cited ON (cited.id_when_cited = r.id_when_cited) # 25M records 
     JOIN isi_issues cited_issue ON (cited.issue_id = cited_issue.issue_id) # 1M records

這就是EXPLAIN不得不說：

+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+ 
| id | select_type | table  | type | possible_keys               | key         | key_len | ref       | rows | Extra  | 
+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+ 
| 1 | SIMPLE  | cited_issue | ALL | NULL                  | NULL         | NULL | NULL       | 1156856 |    | 
| 1 | SIMPLE  | cited  | ref | isi_articles_id_when_cited,isi_articles_issue_id       | isi_articles_issue_id     | 49  | func       |  19 | Using where | 
| 1 | SIMPLE  | r   | ref | isi_citation_references_article_id,isi_citation_references_id_when_cited | isi_citation_references_id_when_cited | 17  | mimir_dev.cited.id_when_cited |  4 | Using where | 
| 1 | SIMPLE  | citing  | ref | isi_lac_authored_articles_article_id          | isi_lac_authored_articles_article_id | 16  | mimir_dev.r.article_id  |  1 |    | 
+----+-------------+-------------+------+--------------------------------------------------------------------------+---------------------------------------+---------+-------------------------------+---------+-------------+

其實我不明白爲什麼它需要尋找在isi_issues表中的所有記錄。難道它不應該通過issue_id上的isi_articles（引用）來匹配嗎？這兩個字段都被編入索引。

來源

2012-03-14 pocketfullofcheese

這裏很難說，但聽起來這是更多的服務器問題，備份可能會導致資源減少。儘管對於那些需要很長時間才能完成的查詢，我會檢查一個像www.infobright.org這樣的分析數據庫。 – 2012-03-14 18:06:03

我可以要求服務器管理員檢查什麼？我不認爲他會安裝分析數據庫... – pocketfullofcheese 2012-03-14 18:18:44

我首先會找出他們使用MyIsam，InnoDB的存儲引擎是什麼樣的......第二個發現備份通常完成而不試圖運行您當時的查詢，爲您的查詢獲取基準但不運行 – 2012-03-14 19:26:17

是的 - 當備份進行時，mysqldump的某些選項會影響所有MyISAM表的鎖定，以便備份是一個時間點的一致「快照」。

InnoDB支持事務，這使得這是不必要的。它通常也比MyISAM更快。你應該使用它。 :)

來源

2012-03-14 18:12:58 duskwuff

但如果我將我的查詢設置爲在備份之前運行，我的查詢是否應該鎖定備份直到查詢結束？它不是一個交易數據庫，它用於分析。當你沒有很多查詢時，我認爲MyISAM通常比InnoDB更快。 – pocketfullofcheese 2012-03-14 18:17:32

在當前版本的MySQL中，MyISAM通常與InnoDB相同，或者更慢。 – duskwuff 2012-03-14 19:06:32

對於這種大小的MySQL數據庫，您可能需要考慮設置複製到從屬節點，然後在從屬設備上執行夜間數據庫備份。

來源

2012-03-14 18:13:12

即使我們沒有很多交易，你會推薦這個嗎？ – pocketfullofcheese 2012-03-14 18:18:17

可以在大型數據庫上導致我的長查詢掛起mysqldump？

回答

相關問題