你可能需要給 primary key 加上 uniqle 約束了
資料表結構：
field
type
null
keydefault
extra
id int(10) unsigned
no pri
null
auto_increment
midvarchar(50)
no uni
null
urlvarchar(500)
no
null
status
tinyint(1)
no
0
worker
varchar(45)
yesnull
在存入了400多萬條資料庫之後我發現即便是簡單的查詢操作也變得慢地難以接受（count 查詢），一開始我懷疑原因出在主鍵的選擇上，於是後來重新設計表，新增了自增欄位 id，然而，count 操作還是很慢。
mysql> select count(*) from develop.task;
+----------+
| count(*) |
+----------+
| 4570649 |
+----------+
1 row in set (2 min 44.73 sec)看看查詢計畫：
idselect_type
table
partitions
type
possible_keys
keykey_len
refrows
filtered
extra
1 ******
task
null
index
null
mid_unique
152null
4446235
100.00
using index
還是按照 mid 這個欄位來查詢。不應該呀，新新增的 id 字段可是主鍵啊，為什麼不按這個鍵來查，而是來按 uniqle 的 mid 來查詢呢？後來我為 id 也新增了uniqle的約束之後，查詢計畫就變了，查詢速度也快了許多：
idselect_type
table
partitions
type
possible_keys
keykey_len
refrows
filtered
extra
1 ******
task
null
index
null
id_unique
4 null
4446235
100.00
using index
> mysql> select count(*) from develop.task;
+----------+
| count(*) |
+----------+
| 4570649 |
+----------+
1 row in set (1.11 sec)為什麼 count 查詢會優先選擇 uniqle 鍵而不是主鍵呢，而在主鍵新增uniqle約束之後又會選擇主鍵，我還不明白。 為什麼key的長度會顯著影響遍歷速度？
前後兩個查詢計畫中最顯著的區別就是 key_len，乙個長度為4位元組，乙個為152位元組，這導致了count查詢速度的巨大差異。
在試圖求解這個問題過程中，覺得必要有用的參考資料：
其中有提到幾種解決 count 問題的方法，有依靠統計量近似估計的，也有另外通過新增欄位在增刪改查時記錄資料變化的。 primary key與unique key對比:
key是index的同義詞。當要為列建立索引，但不是主鍵或唯一鍵時使用key。
unique索引為其值必須是唯一的列建立約束。與primary索引不同，mysql在unique索引中允許有null值。 乙個表也可以有多個unique索引。
例如，users表中的使用者的email和username必須是唯一的。可以為email和username列定義unique索引，如下語句所示：
在username列上新增unique索引
alter table users
add unique index username_unique (username asc) ;
MySQL學習筆記 count的查詢
count 計算乙個表的行數 select count from t在事務支援，併發能力，資料安全上innodb引擎表現都較myisam表現優良 innodb是索引組織表 主鍵索引樹的葉子節點是資料 普通索引樹的葉子節點是主鍵值 普通索引樹主鍵索引樹小很多 對於count 的操作，遍歷哪個索引樹得到...
MySQL查詢優化之COUNT
count 聚合函式，以及如何優化使用了該函式的查詢，很可能是mysql中最容易被誤解的前10個話題之一，在網上隨便搜尋一下就能看到很多錯誤的理解，可能比我們想象的多得多。在做優化之前，先來看看count 函式的真正作用是什麼。count 的作用 count 的另外乙個作用是統計結果集的行數。當my...
mysql聯合查詢時count使用的問題
select t1.id shopid t1.shop name shopname t1.logo url logourl t1.keyword keyword t1.seller id sellerid count t2.id ordercount from hx shop info t1 lef...