1. 首頁
  2. 問答
  3. 表'/tmp/#sql_3c51_0.MYI'的密鑰文件不正確;嘗試修復它

表'/tmp/#sql_3c51_0.MYI'的密鑰文件不正確;嘗試修復它

2012-08-04 60 views
28

我寫了一個查詢，這可以正常運行我的本地服務器上具有較少的數據，表'/tmp/#sql_3c51_0.MYI'的密鑰文件不正確;嘗試修復它

，但是當我在生產服務器上運行這一點，得到一個錯誤 - （這大約有6GB多數據）

Incorrect key file for table '/tmp/#sql_3c51_0.MYI'; try to repair it

這裏是我的查詢

SELECT 
    `j25_virtuemart_products`.`virtuemart_product_id`, 
    `product_name`, 
    `product_unit`, 
    `product_s_desc`, 
    `file_url_thumb`, 
    `virtuemart_custom_id`, 
    `custom_value` 
    FROM 
    `j25_virtuemart_product_customfields`, 
    `j25_virtuemart_products`, 
    `j25_virtuemart_products_en_gb`, 
    `j25_virtuemart_product_medias`, 
    `j25_virtuemart_medias`  
    WHERE 
    (
    `j25_virtuemart_products`.`virtuemart_product_id`=`j25_virtuemart_products_en_gb`.`virtuemart_product_id` 
    AND 
    `j25_virtuemart_products`.`virtuemart_product_id`=`j25_virtuemart_product_customfields`.`virtuemart_product_id`) 

AND 

    `j25_virtuemart_products`.`virtuemart_product_id`=`j25_virtuemart_product_medias`.`virtuemart_product_id` 
    AND 
    `j25_virtuemart_product_medias`.`virtuemart_media_id`=`j25_virtuemart_medias`.`virtuemart_media_id` 

    GROUP BY `j25_virtuemart_products`.`virtuemart_product_id` 

    LIMIT 0, 1000;

任何人都知道如何從錯誤中恢復 - 像otimize此查詢或任何其他方式 謝謝

來源

2012-08-04 Suneth Kalhara

回答

7

操作步驟

停止mysql服務

重命名.MYI文件x.old

啓動MySQL

REPAIR all the tables in query，MySQL將重建密鑰文件

來源

2012-08-04 04:05:50 Hawili

+0

no mate，site is working corretly http://tsiopelakos.dev-centiva.com/index.php？選項= com_virtuemart和視圖=類別和virtuemart_category_id = 2657＆ITEMID = 134 但這隻有當上面的查詢運行，你有一個關於優化知道這個查詢:)這些表的 – 2012-08-04 04:10:30

+1

一個有一個壞的密鑰文件'j25_virtuemart_product_customfields'饒人， 'j25_virtuemart_products'， ' j25_virtuemart_products_en_gb'， 'j25_virtuemart_product_medias'， 'j25_virtuemart_medias'，你要修復它，然後查詢應該工作 – Hawili 2012-08-04 04:13:46

+0

感謝的人它工作得很好，我修好上述表 EX- REPAIR TABLE cent_virtuemart_products_en_gb 現在的工作很好:)偉大的.. – 2012-08-04 04:34:51

3

通過運行df -h來檢查您的tmp目錄的位置。確保有足夠的空間來生成臨時文件，它可以是幾個演出。

編輯：如果您有足夠的可用空間，我會檢查並確保您在WHERE子句中包含或包含的每個列都被編入索引。

來源

2012-08-04 04:00:00 ajacian81

+0

我知道我想辦法從，恢復東西像這樣優化的查詢或... – 2012-08-04 04:02:56

+0

多少免費空間你有/ tmp /？ – ajacian81 2012-08-04 04:03:23

+0

我沒有cPanel訪問權限，我只是通過我的php文件運行此代碼 http://tsiopelakos.dev-centiva.com/index.php?option=com_jumi&view=application&fileid=2&Itemid=322&txtTitle=&txtIsbn=&txtIsbn13=&txtAuthor= ＆txtEditor =＆txtDfrom =＆txtDto =＆txtType =＆txtPricefrom =＆txtPriceto = – 2012-08-04 04:12:20

51

問題是由/ tmp文件夾中缺少磁盤空間引起的。 /tmp卷用於需要創建臨時表的查詢。即使查詢僅使用帶有InnoDB的表，這些臨時表也使用MyISAM格式。

這裏有一些解決方案：

來源

2013-10-23 20:44:39

+1

在我們的例子中，它是根（/）文件夾，因爲我們的虛擬機擁有一個分區中的所有內容，並且/ var/logs /目錄已經填滿。太空建議雖然榮譽！ – oucil 2015-06-30 17:11:30

+0

這是正確的答案。對於innodb尤其是，因爲修復表不被支持。謝謝！ – lucian303 2015-11-17 19:20:52

+0

這應該是被接受的答案。如上所述，特別是InnoDB表格。我將我的tmp目錄移動到一個有12GB可用空間的捲上，並且在生成一個19GB大小的tmp文件後，我的查詢運行沒有問題。 – 2016-01-28 19:59:42

0

檢查數據庫服務器是否有足夠的磁盤空間。如果磁盤已滿，則顯示此錯誤。現在，您應該查看哪些文件夾取決於您的設置。

來源

2015-01-09 11:12:05 klodoma

7

上面有很多答案，問題的所有者已經按照@Hawili的建議得到了解決方案，並且在提出這個問題後已經過了很長一段時間。但是，由於這是一個常見問題，我想分享我的經驗，以便如果由於不同的原因再次遇到此問題，則可以從此處獲得解決方案。

案例1：

最常見的原因是，查詢獲取比你的/ tmp分區的大小更大的數據。每當在查詢過程中遇到此問題時，請查看/ tmp文件夾大小。臨時表創建並自動刪除，如果可用空間此查詢過程在這裏下到0就意味着要麼你需要優化你的查詢或需要增加/ tmp目錄的分區大小。

注意：有時它不是一個單獨的查詢：如果重查詢的組合做到這一點在同一時間在同一臺服務器上，那麼你可以得到這樣的問題，而正常情況下的各個查詢將執行沒有任何錯誤。

案例2：

在您需要修復損壞的MyISAM表的情況下，該目錄路徑會比在錯誤信息的/ tmp不同。

案例3：（極少數情況下）

有時由於不正確的表連接，你可以得到這個錯誤。這實際上是一個語法錯誤，但是mysql可以拋出這個錯誤。您可以在下面使用此命令行/etc/init.d/mysqld restart在終端點擊此處查看詳細信息鏈路

Incorrect key file for table '/tmp/#sql_18b4_0.MYI'; try to repair it

來源

2015-07-08 11:31:00

0

我用這下面的命令和錯誤走了：

mysqlcheck --all-databases -r #repair

我從cpanel forum

來源

2016-10-23 14:15:33

0

同樣的問題該解決方案對我

運行df -h，看看你的分區/ tmp目錄有足夠的空間

在我的情況的/ tmp是溢出文件系統：

overflow 1,0M 24K 1000K 3% /tmp

發生了什麼事：

我這裏有一些問題，我劃分/得滿滿的，然後Debian的發行版中創建RAM MEMOR一個新的分區/tmp，臨時使用。這/tmp 1MB分區不是供系統使用足夠大。

解決方案： 運行以下命令來刪除此臨時創建的分區/tmp

sudo umount -l /tmp

來源

2018-01-15 18:43:58

相關問題

 相關問題