MySQL進程花費了非常多的時間

我有一項每小時運行一次的任務，並且已經運行了幾個月。該過程從MySQL（MariaDB）獲取分析並彙總數據。通常需要1-5分鐘才能完成。MySQL進程花費了非常多的時間

然而自從13個小時前，它現在需要26分鐘的時間。我重新啓動了MySQL服務器，沒有任何改變。進程列表顯示聚合負責很長時間（有些查詢需要500秒才能完成，他們用了不到30秒）。

我查詢的表格是2600萬行大。

究竟是什麼原因導致了處理時間的跳躍？它一直工作很好，很長一段時間！

你建議我現在做什麼？數據庫可能已經腐敗了嗎？

查詢：

*************************** 2. row *************************** 
     Id: 76042556 
    User: ----- 
    Host: -------- 
     db: mydb 
Command: Query 
    Time: 456 
    State: Sending data 
    Info: SELECT avg(analytics.event) AS `avg_session`, count(*) AS `count` FROM `analytics` WHERE `analytics`.`app_id` = '436' AND `analytics`.`event_type` = 'session' AND `analytics`.`created_at` >= '2015-06-19 12:16:41' AND `analytics`.`created_at` <= '2015-07-19 12:16:41' ORDER BY `analytics`.`id` ASC 
Progress: 0.000

解釋：

EXPLAIN EXTENDED SELECT `analytics`.`event` AS `event`, `analytics`.`created_at` AS `a_created_at`, EXTRACT(DAY FROM analytics.created_at) AS `interval`, count(analytics.id) AS `count` FROM `analytics` WHERE `analytics`.`app_id` = '436' AND `analytics`.`event_type` = 'startup' AND `analytics`.`created_at` >= '2015-06-21 09:32:41' AND `analytics`.`created_at` <= '2015-07-21 09:32:41' GROUP BY `interval` ORDER BY `a_created_at` ASC 
    -> ; 
+------+-------------+-----------+------+---------------+--------+---------+-------+----------+----------+----------------------------------------------+ 
| id | select_type | table  | type | possible_keys | key | key_len | ref | rows  | filtered | Extra          | 
+------+-------------+-----------+------+---------------+--------+---------+-------+----------+----------+----------------------------------------------+ 
| 1 | SIMPLE  | analytics | ref | app_id  | app_id | 5  | const | 15236882 | 100.00 | Using where; Using temporary; Using filesort | 
+------+-------------+-----------+------+---------------+--------+---------+-------+----------+----------+----------------------------------------------+

P.S：請，不聽課我如何削減長的查詢，而不是幫助我理解這個特定的問題。

來源

2015-07-19 zed

你能在這裏發表您的查詢？ – Akhil

查詢已添加 – zed

您的'innodb_buffer_pool_size'值是什麼？這可能是因爲MariaDB無法適應內存中的數據集，並且正在使用磁盤來查找它應該聚合的記錄 - 在數據庫世界中執行某些操作的時間非常長，這幾乎總是意味着它們受到I/O限制。在機械盤的情況下，這意味着你的設置變得像蝸牛一樣慢，直到用手計算東西快得多。請確認您的數據是否適合內存，並且如果可能（並且您沒有） - 嘗試將SSD用於與機械驅動器相對的永久存儲器。 –

我認爲，你可以試試：

OPTIMIZE TABLE（S）
修表（S） - 數據實際上可能已損壞或可能有一些重載
檢查鎖：也許一些刀片上通過聚集查詢查詢表（一個或多個）執行（也許有些功能已經最近新增用戶更頻繁地提交形式...）

我認爲指標的明確界定，也不會被別人不知情的情況下更新的數據庫結構;）

來源

2015-07-19 09:52:43

優化表並沒有影響性能 – zed

我使用的是InnoDB引擎，所以沒有修復功能，只有傾銷和恢復。 – zed

啊 - 好的 - 所以這可能會有所幫助（如果表腐敗是問題的根源......）：https：//www.percona.com/blog/2008/07/04/recovering-innodb-table-corruption/ –

幾點建議

BY子句中刪除訂單，因爲它不此查詢任何好處
根據您的數據性質添加適當的索引。可能是app_id。
如果在analytics中執行了太多更新/刪除操作，則執行optimize table analytics。這將重新結構的指標

它會幫助我們，如果您發佈explain結果也

來源

2015-07-19 09:56:56 Akhil

我已經添加了解釋並優化了表格。優化並沒有解決問題。 – zed

app_id上的索引似乎無法幫助您。因此，您可以嘗試創建一個名爲app_id，event_type的組合索引。這會給你最大的性能。但是，如果您頻繁插入，則會遇到一些問題。您是否充分配置了innodb緩衝池大小？ – Akhil

您是否嘗試通過刪除訂單？ – Akhil

MySQL進程花費了非常多的時間

回答

相關問題