分析的優化SQL查詢

我已經實施了現在表現非常差的分析系統。爲了解釋它，我需要解釋一下表結構查詢分析的優化SQL查詢

我有兩個InnoDB表

表1：包含約每小時統計（stats_id，file_id的，時間）表2記載：載有超過800萬行。

表2結構

full_stats (
    stats_id Int 
    file_id Int 
    stats_week Int 
    stats_month Int 
    stats_year Int 
    stats_time DATETIME

）

我所試圖做的是計算從hourly_stats對於給定的時間段內通過file_id的總的看法和分組記錄，然後我添加/將記錄更新到full_stats表。平均需要1-2分鐘處理一行。我試圖優化查詢以獲得更好的性能。

下面是我在做什麼

有跡象表明，在FILE_ID爲full_stats某一週，一個月，一年，40分％的機會已經存在，是不存在60分％的機會。

所以在第一個查詢我嘗試使用更新記錄查詢

UPDATE full_stats 
    SET total_views=XXX 
WHERE stats_week=XX stats_month=X 
    AND stats_year=YYYY

後，我檢查，如果受影響的行爲零，則我插入記錄如下。插入或更新完成後，hourly_stats中的記錄將根據file_id和給定的時間段被刪除。

你可以給我任何建議如何優化查詢並降低鎖定率嗎？

來源

2010-08-13 Maximus

您在此表上設置了哪種索引？ – FrustratedWithFormsDesigner 2010-08-13 15:58:23

使用SSD加入RAID陣列，應該加快I/O速度。真的嗎？只要添加了索引，就應該儘可能快地工作。在這種情況下，任何優化都不會對性能產生影響。也許你正在考慮對系統進行全面的重新設計，但是這裏沒有提供線索，因爲如果你推入一個地方，你會失去另一個地方，並且只有很少的細節才能弄清楚什麼可以做得更好。 – AlexanderMP 2010-08-13 16:02:51

我試圖在周，月，年添加索引，但之後性能非常緩慢，因此我必須將其刪除。 – Maximus 2010-08-13 16:08:43

當每次插入/更新後索引必須重寫或更新時，索引導致性能較差。這對於常規索引更有可能。
然而，就你而言，這聽起來像你需要一個唯一的索引無論如何。有了這個，你可能沒有這個問題（那麼多）。

確保您的表使用InnoDB引擎並且在(stats_year, stats_month, stats_week)上有唯一索引。

然後，不要先執行更新，然後檢查受影響的行並在必要時插入，請使用INSERT...ON DUPLICATE KEY UPDATE。這種方式在40％的情況下可以省去前面的更新說明。
請注意，獨特的索引對於本聲明至關重要！

來源

2016-06-01 08:26:16 fancyPants

分析的優化SQL查詢

回答

相關問題