MySQL中的視圖及性能問題
視圖是MySQL 5.0中增加的三大新功能之一（另外兩個是存儲過程與觸發(fā)器），也是一般稍微“高級”一點的數(shù)據(jù)庫所必需要有的功能。MySQL在定義視圖上沒什么限制，基本上所有的查詢都可定義為視圖，并且也支持可更新視圖（當然只有在視圖和行列與基礎表的行列之間存在一一對應關(guān)系時才能更新），因此從功能上說MySQL的視圖功能已經(jīng)很完善了。
然而若要在應用中使用視圖，還需要了解處理視圖時的性能，而MySQL在這方面問題是比較大的，需要特別注意。首先要知道MySQL在處理視圖時有兩種算法，分別稱為MERGE和TEMPTABLE。在執(zhí)行"CREATE VIEW"語句時可以指定使用哪種算法。所謂MERGE是指在處理涉及到視圖的操作時，將對視圖的操作根據(jù)視圖的定義進行展開，有點類似于C語言中的宏展開。比如設有以下的表（類似于博客中的評論）：
CREATE TABLE `comment` (
? `id` int(11) NOT NULL,
? `user_id` int(11) default NULL,
? `content` varchar(255) default NULL,
? PRIMARY KEY? (`id`),
? KEY `idx_comment_uid` (`user_id`)
) ENGINE=InnoDB;
假設user_id < 10000的用戶為VIP用戶，我們可以這樣創(chuàng)建一個視圖來表示VIP用戶的評論：
CREATE VIEW vip_comment AS SELECT * FROM comment WHERE user_id < 10000;
這時我們在操作vip_comment視圖時使用的就是MERGE算法。如：
mysql > EXPLAIN EXTENDED SELECT count(*) FROM vip_comment WHERE user_id < 0;
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
| id | select_type | table?? | type? | possible_keys?? | key???????????? | key_len | ref? | rows | Extra??????????????????? |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
|? 1 | SIMPLE????? | comment | range | idx_comment_uid | idx_comment_uid | 5?????? | NULL |?? 10 | Using where; Using index |
+----+-------------+---------+-------+-----------------+-----------------+---------+------+------+--------------------------+
mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
| Note? | 1003 | select count(0) AS `count(*)` from `test`.`comment` where ((`test`.`comment`.`user_id` < 0) and (`test`.`comment`.`user_id` < 10000)) |?
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------+
可以看到，對vip_comment的操作已經(jīng)被擴展為對comment表的操作。
一般來說在能夠使用MERGE算法的時候MySQL處理視圖上沒什么性能問題，但并非在任何時候都能使用MERGE算法。事實上，只要視圖的定義稍稍有點復雜，MySQL就沒辦法使用MERGE算法了。準確的說，只要視圖定義中使用了以下SQL構(gòu)造塊就無法使用MERGE算法：
聚集函數(shù)DISTINCTGROUP BYHAVING集合操作（在MySQL中只有UNION, UNION ALL，沒有EXCEPT和INTERSECT）子查詢確實，在視圖定義比較復雜的情況下，要對視圖操作進行有效的優(yōu)化是非常困難的。因此在這個時候，MySQL使用了一種以不變應萬變的方法，即先執(zhí)行視圖定義，將其結(jié)果使用臨時表保存起來，這樣后續(xù)對視圖的操作就轉(zhuǎn)化為對臨時表的操作。不能不說從單從軟件設計的角度看，這樣的方法非常的優(yōu)雅，然而從性能角度，這一方法也是非常的差。
比如我們希望使用如下的視圖來表示每個用戶的評論數(shù)，即：
CREATE VIEW comment_count AS SELECT user_id, count(*) AS count FROM comment GROUP BY user_id;
使用這個視圖的時候，我們可能心里有個小算盤。目前我們先用這個視圖頂著，如果性能確實有問題，那我們就再來搞一張comment_count的表，其中就記下來每個用戶的評論數(shù)。而我們現(xiàn)在先用這個視圖是為了將來要是改的話會方便點（這也是視圖--即教科書中所謂的外模式--這個東西存在的主要原因之一，另一主要原因是便于權(quán)限控制）。但是遇到了MySQL這個蠢貨，我們的算盤鐵定會失敗。
我們來看一下指定user_id從comment_count選取記錄時的執(zhí)行策略：
mysql> explain select count(*) from comment_count where user_id = 90;
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
| id | select_type | table????? | type? | possible_keys | key???????????? | key_len | ref? | rows?? | Extra?????? |
+----+-------------+------------+-------+---------------+-----------------+---------+------+--------+-------------+
|? 1 | PRIMARY???? |
下載文檔
