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