關於 find_in_set 的性能問題

同事很多數據表設計的時候使用一個字段來存儲多對多關係，好比 表 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, 不過有些表的數據可能永遠就那麼點數據，這個時候爲了減小表數量，卻是能夠用這樣的方法作。