將檔案拖放至此處

SQL 上載 ( 0 ) x -

頁面相關設定 點選此列以回到頁面頂端
請按 Ctrl+Enter 執行查詢 請按 Enter 執行查詢
遞增
遞減
排序：
SQL 偵錯
次數
執行排序
使用時間
排序依：
群組查詢
解除群組查詢
摺疊 展開 顯示追蹤 隱藏追蹤 次數： 使用時間：
書籤
重新整理
新增
無書籤
新增書籤
選項
還原預設值
摺疊 展開 重新查詢 編輯 語句分析 效能分析 書籤 查詢失敗 資料庫: 查詢時間:

建議系統

可能影響執行效率的問題

問題：
上線時間不到 1 天，根據來作效能調整的資料可能不準確。
建議：
若要取得更準確的平均資料，建議在執行分析前讓伺服器執行至少一天
實際狀況：
上線時間僅有 0 天 4 小時，26 分 35 秒
使用的變數 / 公式：
Uptime
檢驗方式：
value < 86400
問題：
long_query_time 目前設定為超過 10 秒，只有執行時間超過 10 秒的查詢會被記錄。
建議：
建議您依據您的環境將 long_query_time 設定值調低，通常建議設在 1-5 秒之間。
實際狀況：
long_query_time 目前設定為 10 秒。
使用的變數 / 公式：
long_query_time
檢驗方式：
value >= 10
問題：
未啟用「緩慢查詢記錄」。
建議：
要啟用緩慢查詢記錄，請將 slow_query_log 設為 ON，這將有助於不良查詢的故障排除。
實際狀況：
slow_query_log 目前設定為 OFF
使用的變數 / 公式：
slow_query_log
檢驗方式：
value == 'OFF'
問題：
有大量資料列需要排序。
建議：
大量排序不是錯，但請確保 ORDER BY 子句使用有索引的欄位來排序，以加速排序的執行速度。
實際狀況：
平均排序列數：3.15 每秒
使用的變數 / 公式：
Sort_rows / Uptime
檢驗方式：
value * 60 >= 1
問題：
有太多的資料表連結(join)未使用索引。
建議：
這代表資料表連結(join)時會掃描整個資料表。將連結條件所使用的欄位設定為有索引的欄位，可大幅加快資料表連結時的速度。
實際狀況：
平均資料表連結(join)次數: 3.84 每秒，此值應小於每小時 1 次
使用的變數 / 公式：
(Select_range_check + Select_scan + Select_full_join) / Uptime
檢驗方式：
value * 60 * 60 > 1
問題：
讀取第一個索引項目比率過髙。
建議：
這通常表示資料庫時常掃描全部索引。雖然掃描全部索引，會比掃描資料表速度要快，但在擁有大量資料的資料表仍需消耗不少 CPU 時間，如果這些資料表有大量的更新和刪除操作，執行 OPTIMIZE TABLE 可以減少掃描全部索引的次數或提升速度，除此之外只能靠重寫查詢來減少掃描全部索引。
實際狀況：
平均掃描索引次數：8.98 每分鐘，此值應小於每小時 1 次
使用的變數 / 公式：
Handler_read_first / Uptime
檢驗方式：
value * 60 * 60 > 1
問題：
讀取固定位置資料比率過高。
建議：
這表示許多查詢的結果需要排序，或掃描整個資料表，這包括未使用索引的資料表連結(join)查詢。請在適當的地方增加索引。
實際狀況：
平均固定位置讀取次數：3.11 每秒，這個值應小於每小時 1 次
使用的變數 / 公式：
Handler_read_rnd / Uptime
檢驗方式：
value * 60 * 60 > 1
問題：
讀取資料表下一筆資料比率過高。
建議：
這表示有許多查詢需要掃描整個資料表。請適時增加索引。
實際狀況：
平均讀取資料表下一筆資料次數：126.48 每秒，此值應小於每小時 1 次
使用的變數 / 公式：
Handler_read_rnd_next / Uptime
檢驗方式：
value * 60 * 60 > 1
問題：
太多的暫存資料表寫入至磁碟，而非儲存在記憶體。
建議：
增加 max_heap_table_size 和 tmp_table_size 可能有所幫助，但某些暫存資料表仍然會寫到磁碟，與這些變數無關。要解決這個問題，必須重寫查詢條件，避免在暫存資料表中儲存 BLOB 或 TEXT 類型的欄位，或者使用長度大於 512 位元組的欄位，如 MySQL 說明文件所提到的狀況
實際狀況：
暫存資料表寫入至磁碟的比率：18.81 每分鐘，此值應小於每小時 1 次
使用的變數 / 公式：
Created_tmp_disk_tables / Uptime
檢驗方式：
value * 60 * 60 > 1
問題：
MyISAM 鍵值緩衝區 (索引快取) % 使用率過低。
建議：
可能需要減少 key_buffer_size 的值，重新檢視資料表，是否曾經刪除過索引，或檢視查詢是否如預期的使用了索引。
實際狀況：
MyISAM 鍵值緩衝區最大使用 %：0%，此值應該要在 95% 以上
使用的變數 / 公式：
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
檢驗方式：
value < 95
問題：
資料表開啟比率過高。
建議：
開啟資料表會大量使用磁碟存取。增加 table_open_cache 或能避免此問題。
實際狀況：
資料表開啟比率：31.06 每小時，此值應該低於每小時 10 次
使用的變數 / 公式：
Opened_tables / Uptime
檢驗方式：
value*60*60 > 10
問題：
檔案開啟比率過高。
建議：
請考慮增加 open_files_limit，並在更改 open_files_limit 設定後，重新啟動伺服器，並檢查錯誤記錄是否有異常。
實際狀況：
檔案開啟次數：17.11 每小時，此值應該低於每小時 5 次
使用的變數 / 公式：
Open_files / Uptime
檢驗方式：
value * 60 * 60 > 5
問題：
查詢快取的使用比例低於 80%。
建議：
可能是 query_cache_limit 太低所引起的。清空查詢快取可能改善狀況。
實際狀況：
目前的閒置查詢快取記憶體，為全部查詢快取的大小的 12%；這個值應高於 80%
使用的變數 / 公式：
100 - Qcache_free_memory / query_cache_size * 100
檢驗方式：
value < 80
問題：
查詢快取結果集的上限為預設的 1 MB。
建議：
更改 (通常是增加) query_cache_limit 可以提高效率。這個變數用來限制可以儲存在查詢快取中的查詢結果。如果有許多超過 1 MB 的查詢是適合快取的 (讀取多，寫入少)，那麼增加 query_cache_limit 將會增加效率。反之，若許多超過 1 MB 的查詢結果是不適合快取的 (往往因資料表更新而失效)，那麼增加 query_cache_limit 就反而會降低效率。
實際狀況：
query_cache_limit 目前設定為 1 MB
使用的變數 / 公式：
query_cache_limit
檢驗方式：
value == 1024*1024