的Sql指數性能比較

我稱之爲「DataVisitorActivity」一個小桌子與此字段的Sql指數性能比較

id   int auto_increment primary key, 
vID   int null, 
category  varchar(128) null, 
timestamp  timestamp default CURRENT_TIMESTAMP not null, 
value   text null, 
handle  text null

它有2個索引字段

handle_index(handle) 
DataVisitorActivity_vID_index(vID)

，直到如今我沒有性能比較問題，以防萬一0.01秒所有的工作。目前桌子上有2Milion entrys，它會每天變得更大（我們保存用戶在此列表中訪問的每個網站）上次我編輯表格時唯一需要更改的是將「句柄」設置爲「文本「因爲我們真的有很長的字符串可以在這個領域得到保存。與更改查詢我使用

SELECT COUNT(*) AS `blog_count`, handle FROM DataVisitorActivity WHERE value = "blog" GROUP BY handle ORDER BY blog_count DESC Limit 5

這個時候就需要0.1 - 0.3秒依然對我很好。

我現在看到查詢somethimes（看起來隨機）需要5到15秒執行。我剛剛寫了一個while循環，讓它運行10次總共100次。大約60秒在1秒以內20小於5秒，其他大於5秒。

所以我的問題是：這個查詢花了很長時間，因爲表越來越大了？爲什麼執行時間變得如此艱難？

編輯：phpmayadmin這個查詢在每次

來源

2017-09-08 Burak Topal

如果您多次快速運行查詢，服務器只是將結果緩存一點，但有時表會發生變化，它必須爲您重新計算所有內容。另外如何使用COUNT（id）而不是確定使用*是否是神話般的性能問題。 – Recct

嘿@Recct我嘗試了與COUNT（id）現在相同的結果，坦克爲您的快速推薦 –

如何碎片整理你的數據庫？你多久重建一次索引？您應該儘量保持每週10％的零散度，並每週重建以獲得最佳性能。下面的答案也是很好的建議。你應該索引一個較小的數據類型 – MIKE

0.001秒exequtet在我會認爲你GROUP BY handle的問題。該領域有多大，你有一個索引？請在此查看文本列的索引：https://dev.mysql.com/doc/refman/5.5/en/column-indexes.html。

一個可能的解決方案是添加一個存儲的列，例如handle列的sha1哈希值。這將有一個固定的寬度，所以你可以很容易地添加一個索引 - 和GROUP BY - 。然後使用EXPLAIN查看可以改進的地方。

來源

2017-09-08 13:06:16 jeroen

我在「句柄」字段中使用了FULLTEXT INDEX。喜歡你的例子中的聆聽。谷歌refferer得到存儲裏面的「處理」字段，以便他們得到真正的長期 –

@BurakTopal我不認爲全文索引是有用的分組，但你必須嘗試一個前綴索引，以查看差異。 – jeroen

即使我不分組我有超過1秒的執行時間:(我需要一些搜索字段綁定到句柄字段的全文索引。我只能使用長度爲150-300的「前綴索引」我不認爲搜索將是乾淨的，但我會嘗試 –

的Sql指數性能比較

回答

相關問題