MySQL緩慢查詢'COUNT'

以下查詢在4.5Gb MySql數據庫上運行時，2.5Ghz雙核Windows Server 2008 R2企業版需要0.7s。 sIndex10是一個varchar（1024）柱類型：MySQL緩慢查詢'COUNT'

SELECT COUNT(*) FROM e_entity 
WHERE meta_oid=336799 AND sIndex10 = ''

一種EXPLAIN顯示以下信息：

id: 1 
select_type: SIMPLE 
table: e_entity 
type: ref 
possible_keys: App_Parent,sIndex10 
key: App_Parent 
key_len: 4 
ref: const 
rows: 270066 
extra: Using Where

有230060行匹配所述第一條件和124216行子句AND操作者匹配。 meta_oid已編入索引，儘管sIndex10也已編入索引，但我認爲它正確無法將此索引作爲FORCE INDEX (sIndex10)收錄，所用時間較長。我們查看了配置參數，例如innodb_buffer_pool_size，它們看起來也是正確的。

鑑於此表已經有642532條記錄，我們是否已經達到了mysql可以提供的性能的頂部？在這一點上投資硬件是唯一的出路嗎？

來源

2016-11-21 Rafael Diaz

你有 'possible_keys：App_Parent，sIndex10' WHT宇沒有meta_oid？。你在這個專欄有適當的索引嗎？最終顯示您的表格架構 – scaisEdge

'App_Parent'是'meta_oid'列的索引名稱 –

如果app_parent覆蓋BOTH列，可能會實現小的性能增益 – Strawberry

-1

我總是做的一件事就是count(id)因爲id（總是）總是索引，只計算id只需要看索引。

因此請嘗試運行，看看它是否表現更好。測試時還應該添加SQL_NO_CACHE以更好地瞭解查詢的執行方式。

SELECT SQL_NO_CACHE COUNT(id) FROM e_entity 
WHERE meta_oid=336799 AND sIndex10 = ''

注意：這可能不是您的問題的完整答案，但它只是一個評論太長。

來源

2016-11-21 08:55:21

謝謝但這沒有什麼區別 –

'SQL_NO_CACHE'繞過了查詢緩存，如果爲ON，可以爲_repeated_查詢提供非常快的時間。 –

'COUNT（x）'檢查'x'是否爲NULL。這就是你想要的，所以'COUNT（*）'是寫出它的方法。不，索引是不相關的，因爲'WHERE'子句是索引所需要的。 –

WHERE meta_oid=336799 AND sIndex10 = ''

乞求一個複合指數

INDEX(meta_oid, sIndex10) -- in either order

即不一樣具有在列單獨的索引。

就是這樣。

Index Cookbook

來源

2016-11-21 19:25:36

如何在不查詢'sIndex10'的情況下使用'meta_oid'的查詢？ –

他們也可以使用該索引（假設給定順序）。僅使用sIndex10的查詢不能。 Cookbook說：'WHERE aaa = 123 AND ...'：一個INDEX _starting_ with'aaa'很好，等等。 –

這沒有什麼區別 –

MySQL緩慢查詢'COUNT'

回答

相關問題