關於 find_in_set 的性能問題

https://www.iteye.com/blog/jonny131-771753

同事不少數據表設計的時候使用一個字段來存儲多對多關系，比如 表 user中有一個字段叫 category, category存儲的是 "1,3,9" 這樣的類型的數據，實際上是category的id 用逗號分隔開來的。

 

要查詢一個用戶屬於id為2分類的用戶可以這么寫

 

 

select * from `user` where find_in_set('2',`user`.`category`)

 

具體find_in_set 的使用請參照手冊

http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_find-in-set

 

 

雖然這樣很好用，但問題是如果數據量大的情況下怎么辦，性能會是問題么，手冊上有說對find_in_set 做的優化，但在沒有索引的情況下他的性能應該是個問題。

 

於是做了個測試，user 表錄入 100萬的數據，同時建立 user_category 表，每個user有 3 個分類，那么category表里有300萬條記錄。

 

CREATE TABLE `user_category` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) DEFAULT NULL,
  `category_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `category_id` (`category_id`),
  KEY `user_id` (`tax_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT

 

 

現在比較一下在百萬級的數據量上使用 join 鏈接外鍵查詢和find_in_set查詢的性能

 

1. 使用 find_in_set 查詢，平均時間在2.2秒左右

 

 

SELECT SQL_NO_CACHE COUNT(*) FROM `user` WHERE FIND_IN_SET(65,category)

 

 

 

2. 使用left join ， 使用了右表中的索引，平均時間在0.2秒左右

 

 

SELECT SQL_NO_CACHE COUNT(DISTINCT(`user`.id)) FROM `user`
LEFT JOIN `user_category` ON `user`.`id`= `user_category`.`user_id`
WHERE `user_category`.`category_id`=75

 

 

所以在大數據量的情況下還是不適合用find_in_set, 不過有些表的數據可能永遠就那么點數據，這個時候為了減少表數量，倒是可以用這樣的方法做。