最近決定將以前同事寫(xiě)的存儲(chǔ)過(guò)程查看一遍，尋找一些代碼上寫(xiě)的不太好的地方，爭(zhēng)取進(jìn)行修改以后讓這些過(guò)程達(dá)到一個(gè)很好的運(yùn)行速度。下面是遇到的最多的幾個(gè)問(wèn)題。

我遇到了這樣的一個(gè)SQL：

select name, count(*) from (select name from table_1) a group by a.name;

MySQL的執(zhí)行計(jì)劃對(duì)于這種派生表的解釋非常的不友好，但是能直觀的感覺(jué)到的是，這個(gè)SQL執(zhí)行速度特別的慢。查看這個(gè)表table_1發(fā)現(xiàn)，name字段是有索引的。審視這段代碼，可以推斷出當(dāng)時(shí)程序員的想法，應(yīng)該是想讓數(shù)據(jù)庫(kù)掃描更小的結(jié)果集，因?yàn)閟elect *是很不好的習(xí)慣。不過(guò)他應(yīng)該忽略了一個(gè)MySQL的很重要的特點(diǎn)就是索引。MySQL的索引是個(gè)很有意思的東西，是我從Oracle轉(zhuǎn)過(guò)來(lái)感覺(jué)***玩的東西，好玩的地方就在于，可以?xún)?yōu)化group by。當(dāng)我把這個(gè)SQL改成如下SQL以后：

select name, count(*) from table_1 group by name;

這樣一來(lái)，這段SQL的執(zhí)行速度就非常的快了,extra列明確的顯示了using index，索引覆蓋查詢(xún)，速度杠杠的。

其實(shí)這種錯(cuò)誤應(yīng)該是程序員常犯的，因?yàn)槌绦騿T對(duì)Java等代碼超級(jí)熟悉，但是對(duì)于SQL，基本上都是大學(xué)的時(shí)候?qū)W習(xí)的SQL，用SQLServer練出來(lái)的，基本上沒(méi)有對(duì)數(shù)據(jù)庫(kù)進(jìn)行非常深入的研究，其實(shí)每種數(shù)據(jù)庫(kù)中，同一條SQL的執(zhí)行計(jì)劃都是不盡相同的，這也就是企業(yè)有一個(gè)專(zhuān)業(yè)的DBA的一個(gè)作用。

下面，就是一個(gè)讓人很頭疼的錯(cuò)誤：

select name, userid from table_1 where name = null;

不管是MySQL還是Oracle，對(duì)這種SQL的寫(xiě)法的規(guī)范都是where name is (not) null。null這個(gè)值，在不管什么數(shù)據(jù)庫(kù)里都是一個(gè)讓人（包括程序員和DBA）都很頭疼的東西。我對(duì)MySQL的理解還不夠深入，但是根據(jù)某一本《Oracle DBA手記》中記載，Oracle中每種數(shù)據(jù)類(lèi)型的null都代表了不一樣的意義。

做了下面一個(gè)實(shí)驗(yàn)：

可以看出來(lái)，不管是“= null”還是“<> null”，得到的值其實(shí)都是不確定，也就是null。因此，必須要寫(xiě)成is (not) null。在《劍破冰山》這本書(shū)里也有對(duì)Oracle的null值的詳細(xì)介紹。

總結(jié)一下最近的工作，我研究了小半年時(shí)間的MySQL，發(fā)現(xiàn)這個(gè)開(kāi)源的數(shù)據(jù)庫(kù)并不像我過(guò)去認(rèn)為的那樣，就是一個(gè)互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)。這個(gè)數(shù)據(jù)庫(kù)在面向OLAP復(fù)雜計(jì)算的方面確實(shí)和Oracle，DB2等商用數(shù)據(jù)庫(kù)之間有不小的差距，不過(guò)在MariaDB這個(gè)分支中，這部分有了不小的進(jìn)步，相信后面的MySQL版本中也會(huì)越來(lái)越好。其實(shí)這個(gè)數(shù)據(jù)庫(kù)最讓我感興趣的不是開(kāi)源，因?yàn)槲掖_實(shí)看不懂那么長(zhǎng)的源代碼，我的C語(yǔ)言水平就是大學(xué)畢業(yè)水平。這個(gè)數(shù)據(jù)庫(kù)最讓我感興趣（起碼現(xiàn)在來(lái)講）是它的索引，它的索引和Oracle有很大的不同，尤其是InnoDB的表整個(gè)就是用索引組織起來(lái)的，在簡(jiǎn)單的查詢(xún)的時(shí)候，一個(gè)索引覆蓋查詢(xún)就可以無(wú)敵于天下了，在group by和order by的時(shí)候，如果是索引字段，效率會(huì)相當(dāng)?shù)母摺?/p>

其實(shí)我還想說(shuō)的就是，一個(gè)團(tuán)隊(duì)里，如果涉及到大量存儲(chǔ)過(guò)程的編寫(xiě)，一定要有一個(gè)專(zhuān)業(yè)的DBA人員參與其中。SQL是一個(gè)標(biāo)準(zhǔn)，橫跨了所有的關(guān)系型數(shù)據(jù)庫(kù)，但是每一種關(guān)系型數(shù)據(jù)庫(kù)對(duì)SQL的實(shí)現(xiàn)又不盡相同，因此同樣的一段SQL，放到不同的數(shù)據(jù)庫(kù)上執(zhí)行，效率上就會(huì)千差萬(wàn)別。而SQL又非常容易用人最習(xí)慣最簡(jiǎn)單的思維寫(xiě)出來(lái)，比如搜索一個(gè)訂單表里美國(guó)員工生成的訂單信息，SQL有可能是這樣的：

select * from orders t1
where t1.employee_id in (select employee_id from employee t2 
where t2.nation = 'USA');

如果是Oracle這樣的商業(yè)數(shù)據(jù)庫(kù)，這個(gè)SQL的執(zhí)行效率可能會(huì)比較好，但是應(yīng)該不如用exists的SQL。但是當(dāng)這段SQL在MySQL中執(zhí)行的時(shí)候，效率就很差了，因?yàn)楹芏嗳硕贾?，MySQL的子查詢(xún)效率實(shí)在是不敢恭維。這段代碼會(huì)被改為相關(guān)子查詢(xún)，而且隨著數(shù)據(jù)量的增長(zhǎng)，執(zhí)行時(shí)間會(huì)越來(lái)越長(zhǎng)。這段代碼如果改成下面的SQL，效果會(huì)更好：

select t1.*
  from orders t1
inner join employee t2
    on t1.employee_id = t2.employee_id
where t2.nation = 'USA';

如果表上有索引，執(zhí)行速度快極了。

寫(xiě)SQL，還是要首先研究這個(gè)數(shù)據(jù)庫(kù)的原理，然后慎而又慎的寫(xiě)。