怎么編寫高效的MySQL應(yīng)用

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

MySQL對于成為一個非常快速的數(shù)據(jù)庫服務(wù)器有著當(dāng)之無愧的名聲，它也非常容易設(shè)置和使用。隨著它作為網(wǎng)站后端數(shù)據(jù)庫得聲望日增，其效果在去年開始有明顯提高。但是很多MySQL用戶更多地知道如何創(chuàng)建一個數(shù)據(jù)庫并編寫對它的查詢。就像成千上萬的人通過載閑暇時用Linux做實驗來學(xué)習(xí)Unix那樣，很多人通過玩MySQL學(xué)習(xí)關(guān)系數(shù)據(jù)庫。這些MySQL新手的大多數(shù)既沒有關(guān)系數(shù)據(jù)庫理論的背景，又沒有時間閱讀MySQL手冊全文。

因此，我們決定研究某些方法，你可以用針對優(yōu)化性能來調(diào)節(jié)MySQL。在讀完本文后，你將理解一些幫助你設(shè)計你的MySQL數(shù)據(jù)庫和查詢的技術(shù)，值得你的應(yīng)用很有效率。我們將假定你熟悉MySQL和SQL基礎(chǔ)，但不假定你有這兩方面的廣博知識。

只存儲你需要的信息

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

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

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

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

ALTER TABLE products ADD rank INTEGER

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

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

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

SELECT * FROM sometable

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

SELECT name, rank, description FROM products


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

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

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

規(guī)范化你的表結(jié)構(gòu)

如果你以前從未聽說過“數(shù)據(jù)規(guī)范化”，不要害怕。規(guī)范化可能是一個復(fù)雜的專題，你可以從只理解最基本的規(guī)范化概念中正真正獲益。

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

圖１

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



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

規(guī)范化表結(jié)構(gòu)的目標(biāo)是使“空單元”的數(shù)量最少，在上述CD表的情況下，如果你允許CD可能包含100首曲子，你會有很多這樣的空單元。不管你何時處理可能擴(kuò)展到類似該CD表那樣數(shù)量的字段列表，它是你需要將你的數(shù)據(jù)分割成2個或更多表的標(biāo)志，然后你一起訪問并獲得你需要的數(shù)據(jù)。

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

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

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



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

　

到此，關(guān)于“怎么編寫高效的MySQL應(yīng)用”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>