SQL查詢太慢甚至「使用索引」解釋

我的查詢：

SELECT 
    COUNT(sub.id) as ids 
FROM 
    subscribers as sub 
WHERE 
    suid=541839243781

EXPLAIN打印：

 
╔════╦═════════════╦═══════╦══════╦═══════════════╦═════╦═════════╦═══════╦═══════╦═════════════╗ 
║ id ║ select_type ║ table ║ type ║ possible_keys ║ key ║ key_len ║ ref ║ rows ║ Extra ║ 
╠════╬═════════════╬═══════╬══════╬═══════════════╬═════╬═════════╬═══════╬═══════╬═════════════╣ 
║ 1 ║ SIMPLE  ║ sub ║ ref ║ i3   ║ i3 ║  8 ║ const ║ 47890 ║ Using index ║ 
╚════╩═════════════╩═══════╩══════╩═══════════════╩═════╩═════════╩═══════╩═══════╩═════════════╝

因此在當我總得到的總數是48k，它需要0.0333加載......如果這個數字上升到1m或5m？那麼它可能需要年齡加載了......

我的用戶表索引是：

 
╔═════════════╦════════════╦═══════════════════╦══════════════╦═════════════╦═══════════╦═════════════╦══════════╦════════╦══════╦════════════╦═════════╗ 
║ Table ║ Non_unique ║  Key_name  ║ Seq_in_index ║ Column_name ║ Collation ║ Cardinality ║ Sub_part ║ Packed ║ Null ║ Index_type ║ Comment ║ 
╠═════════════╬════════════╬═══════════════════╬══════════════╬═════════════╬═══════════╬═════════════╬══════════╬════════╬══════╬════════════╬═════════╣ 
║ subscribers ║   0 ║ PRIMARY   ║   1 ║ id   ║ A   ║  60251 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
║ subscribers ║   1 ║ total_subscribers ║   1 ║ id   ║ A   ║  60251 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
║ subscribers ║   1 ║ total_subscribers ║   2 ║ suid  ║ A   ║  60251 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
║ subscribers ║   1 ║ i3    ║   1 ║ suid  ║ A   ║  6025 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
║ subscribers ║   1 ║ i3    ║   2 ║ uid   ║ A   ║  60251 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
║ subscribers ║   1 ║ i3    ║   3 ║ id   ║ A   ║  60251 ║ NULL  ║ NULL ║  ║ BTREE  ║   ║ 
╚═════════════╩════════════╩═══════════════════╩══════════════╩═════════════╩═══════════╩═════════════╩══════════╩════════╩══════╩════════════╩═════════╝

所以我怎樣才能讓這個查詢更有效？

來源

2012-04-17 fxuser

如果我正確讀取數據，則沒有「suid」列的專用索引。「suid」列值是全球唯一還是僅針對每個訂閱者？ – 2012-04-17 17:27:12

已編輯的索引，忘記了一個索引 – fxuser 2012-04-17 17:33:00

你可能不能。

也就是說，我期望COUNT操作必須與行數成線性比例。您可能會發現，有一百萬行需要0.12秒而不是0.0333秒。

如果它真的成爲問題，您可能可以使用預計算和緩存來解決此問題。例如，您可能有一項每小時工作計算計數並將其存儲在一張桌子上。你的計數可能會過去一小時，但檢索它們會快得多。

來源

2012-04-17 17:13:04

您可以將sys.tables加入sys.partitions。行統計信息存儲在表中。

錯誤：這適用於MS SQL Server，抱歉應該提到這一點。

來源

2012-04-17 17:26:21

列id是否允許NULL值？如果沒有，則更改爲SELECT COUNT(*)，並且引擎將無需引用表數據就能從索引單獨回答查詢。這應該可以加快速度，取決於MySQL如何存儲和檢索基數統計數據，可以使查詢瞬間完成。

來源

2012-04-17 17:42:37

id是AUTO_INCREMENT列，但似乎並沒有加快速度......我仍然獲得相同的速度 – fxuser 2012-04-17 17:45:28

您需要一個大型數據集才能查看查詢時間如何變化總數。嘗試創建500萬行並進行測試。 – 2012-04-17 17:47:28

在1.2米行上需要0.2秒，所以我想在5米它將需要約1-1.5秒...不能這樣縮小到像0.002或類似的東西？其他網站如何從db獲得這樣的數字如此之快？他們是否將它們存儲在某個地方，並且在創建/刪除新記錄時增加/減少它們的數量？ – fxuser 2012-04-19 12:56:30

SQL查詢太慢甚至 「使用索引」 解釋

回答

相關問題

SQL查詢太慢甚至「使用索引」解釋