怎么編寫(xiě)高效的MySQL應用

這篇文章主要介紹“怎么編寫(xiě)高效的應用”，在日常操作中，相信很多人在怎么編寫(xiě)高效的MySQL應用問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對大家解答”怎么編寫(xiě)高效的MySQL應用”的疑惑有所幫助！接下來(lái)，請跟著(zhù)小編一起來(lái)學(xué)習吧！

MySQL對于成為一個(gè)非?？焖俚?a href='http://wap.friendlycc.com.cn/database/mysql/' target='_blank'>數據庫有著(zhù)當之無(wú)愧的名聲，它也非常容易設置和使用。隨著(zhù)它作為網(wǎng)站后端數據庫得聲望日增，其效果在去年開(kāi)始有明顯提高。但是很多MySQL用戶(hù)更多地知道如何創(chuàng )建一個(gè)數據庫并編寫(xiě)對它的查詢(xún)。就像成千上萬(wàn)的人通過(guò)載閑暇時(shí)用Linux做實(shí)驗來(lái)學(xué)習Unix那樣，很多人通過(guò)玩MySQL學(xué)習關(guān)系數據庫。這些MySQL新手的大多數既沒(méi)有關(guān)系數據庫理論的背景，又沒(méi)有時(shí)間閱讀MySQL手冊全文。

因此，我們決定研究某些方法，你可以用針對優(yōu)化性能來(lái)調節M(mǎn)ySQL。在讀完本文后，你將理解一些幫助你設計你的MySQL數據庫和查詢(xún)的技術(shù)，值得你的應用很有效率。我們將假定你熟悉MySQL和SQL基礎，但不假定你有這兩方面的廣博知識。

只存儲你需要的信息

這聽(tīng)上去是常識，但人們常常采取“廚房下水道”的方式進(jìn)行數據庫設計。他們認為可能項要得每樣東西都要存儲并設計數據庫保存所有者這些數據。你需要對你的需求現實(shí)些，并確定取確實(shí)需要什么信息。你常常能隨意產(chǎn)生一些數據而不把它存在數據庫表中。在這種情況下，從一個(gè)應用開(kāi)發(fā)者的角度看也有道理這樣做。

例如，在線(xiàn)目錄的產(chǎn)品表可能包含各種產(chǎn)品的名稱(chēng)、介紹、尺寸、重量和價(jià)格。除了價(jià)格，你可能想存儲每個(gè)項目相關(guān)的稅和運輸成本。但實(shí)際上不必這樣做。首先稅和運輸成本可以方便地（由你的應用或MySQL）計算出來(lái)。其次，如果稅和運輸成本改變了，你可能必須編寫(xiě)必要的查詢(xún)更新每個(gè)產(chǎn)品記錄中的稅和運輸的費率。

有時(shí)人們認為這太難不能在以后往數據庫表中加入字段，所以他們感覺(jué)不得不定義盡可能多的列。這是明顯的概念錯誤。在MySQL中，你可以用ALTER TABLE命令方便地修改表定義以適應你改變的需求。

例如，如果你突然認識到你需要給你的產(chǎn)品表增加一個(gè)級別列（可能你想允許用戶(hù)在你的目錄中給產(chǎn)品評級），你可以這樣做：

ALTER TABLE products ADD rank INTEGER

這給你的產(chǎn)品表增加了一個(gè)整數類(lèi)型的級別列，你能用ALTER TABLE做什么的完整介紹參見(jiàn)MySQL手冊。

只要求你需要的東西--要清晰

就像說(shuō)“只存儲你需要的東西”那樣，這可能看來(lái)是常識，但這一點(diǎn)常常被忽視，為什么呢？因為在一個(gè)應用開(kāi)發(fā)時(shí)，需求經(jīng)常改變，所以很多查詢(xún)最終看來(lái)是這樣：

SELECT * FROM sometable

當你不能肯定你將需要哪一列時(shí)，要求所有列明顯是最省力的事情，然而隨著(zhù)你的表不斷增大和修改，這可能變成一個(gè)性能問(wèn)題。最好是在你的最初開(kāi)發(fā)完成后再花些時(shí)間并確定你真正從你的查詢(xún)中需要什么：

SELECT name, rank, description FROM products


這帶來(lái)了一個(gè)相關(guān)的觀(guān)點(diǎn)，即代碼維護比性能更重要。大多數變成語(yǔ)言（Perl、Python、PHP、Java等）允許通過(guò)字段名和數字編號訪(fǎng)問(wèn)一條查詢(xún)的結果，這意味著(zhù)你可以訪(fǎng)問(wèn)命名字段或字段０都可以得到相同的數據。

長(cháng)期看，最好使用列名而不是其編號位置，為什么？因為一個(gè)表中或一條查詢(xún)中地列的相對位置可以改變。它們在表中可能因為重復使用ALTER TABLE而改變，它們在查詢(xún)中將因重寫(xiě)了查詢(xún)而忘記更新應用邏輯來(lái)匹配而改變。

當然，你仍然需要小心改變列名！但如果你使用列名而非標號位置，如列名改變，你可以用grep搜索源代碼或使用編輯器的搜索能力查找你需要修改的代碼。

規范化你的表結構

如果你以前從未聽(tīng)說(shuō)過(guò)“數據規范化”，不要害怕。規范化可能是一個(gè)復雜的專(zhuān)題，你可以從只理解最基本的規范化概念中正真正獲益。

理解它的最容易的方法是認為你的表是一個(gè)電子報表。如果你想以一個(gè)報表跟蹤你的CD收藏，你可以如圖１種那樣進(jìn)行設計：

圖１

album track1 track2 track10
----- ------ ------ -------
Billboard Top Hits - 1984 Loverboy Shout St. Elmo's Fire
(Billy Ocean) (Tears for Fears) (John Parr)



這看上去很合理。大多數CD只有10首曲子，對否？不盡然。如果你擁有一張有100首曲子的CD且幾張超過(guò)20首改怎么辦。這意味著(zhù)用這種方法，在極端的情況下，你將需要一個(gè)非常寬的表格（或一個(gè)超過(guò)100個(gè)字段的表）來(lái)保存所有的數據。

規范化表結構的目標是使“空單元”的數量最少，在上述CD表的情況下，如果你允許CD可能包含100首曲子，你會(huì )有很多這樣的空單元。不管你何時(shí)處理可能擴展到類(lèi)似該CD表那樣數量的字段列表，它是你需要將你的數據分割成2個(gè)或更多表的標志，然后你一起訪(fǎng)問(wèn)并獲得你需要的數據。

很多關(guān)系數據庫的新手不真正知道關(guān)系數據庫管理系統中關(guān)系是什么。簡(jiǎn)單地說(shuō)，就像一組信息存在可以基于共性數據聯(lián)結（JOIN）在一起的不同表中，很不幸，這聽(tīng)上去更學(xué)術(shù)化和含糊，但CD數據庫提出了一個(gè)具體情況，我們可以研究如何規范數據。

每個(gè)CD列表有一個(gè)固定的屬性（標題、藝術(shù)家、年份、分類(lèi)）集和一個(gè)不定的屬性（曲目表）集的理解給了我們一些如何分成成能相互關(guān)聯(lián)的表的思路。

你可以創(chuàng )建一個(gè)所有專(zhuān)輯及其固定屬性的表，另一個(gè)包含這些專(zhuān)輯的所有曲目的表。這樣不是水平思考（像表格），你垂直思考--就好像你創(chuàng )建列表而不是行--并建立一個(gè)如圖2的表結構：



專(zhuān)輯的編號（MySQL鏡自動(dòng)為你生成，因為我們在列上使用了AUTO_INCREMENT屬性）關(guān)聯(lián)不同曲目到一給定專(zhuān)輯，tracks表中的album_id字段匹配專(zhuān)輯表中的一個(gè)id。這樣要獲得給定專(zhuān)輯的所有曲目，你應該用如下查詢(xún)：