編寫高效的MySQL應用(轉)
編寫高效的MySQL應用(轉)[@more@]藉助諸如Apach、Perl、PHP和Python等工具,構建一個MySQL應用時很容易的。然而確保它們執行快速,則需要一點洞察力。本文就是你需要知道的東西。
MySQL對於成為一個非常快速的資料庫伺服器有著當之無愧的名聲,它也非常容易設定和使用。隨著它作為網站後端資料庫得聲望日增,其效果在去年開始有明顯提高。但是很多MySQL使用者更多地知道如何建立一個資料庫並編寫對它的查詢。就像成千上萬的人透過載閒暇時用Linux做實驗來學習Unix那樣,很多人透過玩MySQL學習關聯式資料庫。這些MySQL新手的大多數既沒有關聯式資料庫理論的背景,又沒有時間閱讀MySQL手冊全文。
因此,我們決定研究某些方法,你可以用針對最佳化效能來調節MySQL。在讀完本文後,你將理解一些幫助你設計你的MySQL資料庫和查詢的技術,值得你的應用很有效率。我們將假定你熟悉MySQL和SQL基礎,但不假定你有這兩方面的廣博知識。
只儲存你需要的資訊
這聽上去是常識,但人們常常採取“廚房下水道”的方式進行資料庫設計。他們認為可能項要得每樣東西都要儲存並設計資料庫儲存所有者這些資料。你需要對你的需求現實些,並確定取確實需要什麼資訊。你常常能隨意產生一些資料而不把它存在資料庫表中。在這種情況下,從一個應用開發者的角度看也有道理這樣做。
例如,線上目錄的產品表可能包含各種產品的名稱、介紹、尺寸、重量和價格。除了價格,你可能想儲存每個專案相關的稅和運輸成本。但實際上不必這樣做。首先稅和運輸成本可以方便地(由你的應用或MySQL)計算出來。其次,如果稅和運輸成本改變了,你可能必須編寫必要的查詢更新每個產品記錄中的稅和運輸的費率。
有時人們認為這太難不能在以後往資料庫表中加入欄位,所以他們感覺不得不定義儘可能多的列。這是明顯的概念錯誤。在MySQL中,你可以用ALTER TABLE命令方便地修改表定義以適應你改變的需求。
例如,如果你突然認識到你需要給你的產品表增加一個級別列(可能你想允許使用者在你的目錄中給產品評級),你可以這樣做:
ALTER TABLE products ADD rank INTEGER
這給你的產品表增加了一個整數型別的級別列,你能用ALTER TABLE做什麼的完整介紹參見MySQL手冊。
只要求你需要的東西--要清晰
就像說“只儲存你需要的東西”那樣,這可能看來是常識,但這一點常常被忽視,為什麼呢?因為在一個應用開發時,需求經常改變,所以很多查詢最終看來是這樣:
SELECT * FROM sometable
當你不能肯定你將需要哪一列時,要求所有列明顯是最省力的事情,然而隨著你的表不斷增大和修改,這可能變成一個效能問題。最好是在你的最初開發完成後再花些時間並確定你真正從你的查詢中需要什麼:
SELECT name, rank, description FROM products
這帶來了一個相關的觀點,即程式碼維護比效能更重要。大多數變成語言(Perl、Python、PHP、Java等)允許透過欄位名和數字編號訪問一條查詢的結果,這意味著你可以訪問命名欄位或欄位0都可以得到相同的資料。
長期看,最好使用列名而不是其編號位置,為什麼?因為一個表中或一條查詢中地列的相對位置可以改變。它們在表中可能因為重複使用ALTER TABLE而改變,它們在查詢中將因重寫了查詢而忘記更新應用邏輯來匹配而改變。
當然,你仍然需要小心改變列名!但如果你使用列名而非標號位置,如列名改變,你可以用grep搜尋原始碼或使用編輯器的搜尋能力查詢你需要修改的程式碼。
規範化你的表結構
如果你以前從未聽說過“資料規範化”,不要害怕。規範化可能是一個複雜的專題,你可以從只理解最基本的規範化概念中正真正獲益。
理解它的最容易的方法是認為你的表是一個電子報表。如果你想以一個報表跟蹤你的CD收藏,你可以如圖1種那樣進行設計:
圖1
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且幾張超過20首改怎麼辦。這意味著用這種方法,在極端的情況下,你將需要一個非常寬的表格(或一個超過100個欄位的表)來儲存所有的資料。
規範化表結構的目標是使“空單元”的數量最少,在上述CD表的情況下,如果你允許CD可能包含100首曲子,你會有很多這樣的空單元。不管你何時處理可能擴充套件到類似該CD表那樣數量的欄位列表,它是你需要將你的資料分割成2個或更多表的標誌,然後你一起訪問並獲得你需要的資料。
很多關聯式資料庫的新手不真正知道關聯式資料庫管理系統中關係是什麼。簡單地說,就像一組資訊存在可以基於共性資料聯結(JOIN)在一起的不同表中,很不幸,這聽上去更學術化和含糊,但CD資料庫提出了一個具體情況,我們可以研究如何規範資料。
每個CD列表有一個固定的屬性(標題、藝術家、年份、分類)集和一個不定的屬性(曲目表)集的理解給了我們一些如何分成成能相互關聯的表的思路。
你可以建立一個所有專輯及其固定屬性的表,另一個包含這些專輯的所有曲目的表。這樣不是水平思考(像表格),你垂直思考--就好像你建立列表而不是行--並建立一個如圖2的表結構:
專輯的編號(MySQL鏡自動為你生成,因為我們在列上使用了AUTO_INCREMENT屬性)關聯不同曲目到一給定專輯,tracks表中的album_id欄位匹配專輯表中的一個id。這樣要獲得給定專輯的所有曲目,你應該用如下查詢:
MySQL對於成為一個非常快速的資料庫伺服器有著當之無愧的名聲,它也非常容易設定和使用。隨著它作為網站後端資料庫得聲望日增,其效果在去年開始有明顯提高。但是很多MySQL使用者更多地知道如何建立一個資料庫並編寫對它的查詢。就像成千上萬的人透過載閒暇時用Linux做實驗來學習Unix那樣,很多人透過玩MySQL學習關聯式資料庫。這些MySQL新手的大多數既沒有關聯式資料庫理論的背景,又沒有時間閱讀MySQL手冊全文。
因此,我們決定研究某些方法,你可以用針對最佳化效能來調節MySQL。在讀完本文後,你將理解一些幫助你設計你的MySQL資料庫和查詢的技術,值得你的應用很有效率。我們將假定你熟悉MySQL和SQL基礎,但不假定你有這兩方面的廣博知識。
只儲存你需要的資訊
這聽上去是常識,但人們常常採取“廚房下水道”的方式進行資料庫設計。他們認為可能項要得每樣東西都要儲存並設計資料庫儲存所有者這些資料。你需要對你的需求現實些,並確定取確實需要什麼資訊。你常常能隨意產生一些資料而不把它存在資料庫表中。在這種情況下,從一個應用開發者的角度看也有道理這樣做。
例如,線上目錄的產品表可能包含各種產品的名稱、介紹、尺寸、重量和價格。除了價格,你可能想儲存每個專案相關的稅和運輸成本。但實際上不必這樣做。首先稅和運輸成本可以方便地(由你的應用或MySQL)計算出來。其次,如果稅和運輸成本改變了,你可能必須編寫必要的查詢更新每個產品記錄中的稅和運輸的費率。
有時人們認為這太難不能在以後往資料庫表中加入欄位,所以他們感覺不得不定義儘可能多的列。這是明顯的概念錯誤。在MySQL中,你可以用ALTER TABLE命令方便地修改表定義以適應你改變的需求。
例如,如果你突然認識到你需要給你的產品表增加一個級別列(可能你想允許使用者在你的目錄中給產品評級),你可以這樣做:
ALTER TABLE products ADD rank INTEGER
這給你的產品表增加了一個整數型別的級別列,你能用ALTER TABLE做什麼的完整介紹參見MySQL手冊。
只要求你需要的東西--要清晰
就像說“只儲存你需要的東西”那樣,這可能看來是常識,但這一點常常被忽視,為什麼呢?因為在一個應用開發時,需求經常改變,所以很多查詢最終看來是這樣:
SELECT * FROM sometable
當你不能肯定你將需要哪一列時,要求所有列明顯是最省力的事情,然而隨著你的表不斷增大和修改,這可能變成一個效能問題。最好是在你的最初開發完成後再花些時間並確定你真正從你的查詢中需要什麼:
SELECT name, rank, description FROM products
這帶來了一個相關的觀點,即程式碼維護比效能更重要。大多數變成語言(Perl、Python、PHP、Java等)允許透過欄位名和數字編號訪問一條查詢的結果,這意味著你可以訪問命名欄位或欄位0都可以得到相同的資料。
長期看,最好使用列名而不是其編號位置,為什麼?因為一個表中或一條查詢中地列的相對位置可以改變。它們在表中可能因為重複使用ALTER TABLE而改變,它們在查詢中將因重寫了查詢而忘記更新應用邏輯來匹配而改變。
當然,你仍然需要小心改變列名!但如果你使用列名而非標號位置,如列名改變,你可以用grep搜尋原始碼或使用編輯器的搜尋能力查詢你需要修改的程式碼。
規範化你的表結構
如果你以前從未聽說過“資料規範化”,不要害怕。規範化可能是一個複雜的專題,你可以從只理解最基本的規範化概念中正真正獲益。
理解它的最容易的方法是認為你的表是一個電子報表。如果你想以一個報表跟蹤你的CD收藏,你可以如圖1種那樣進行設計:
圖1
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且幾張超過20首改怎麼辦。這意味著用這種方法,在極端的情況下,你將需要一個非常寬的表格(或一個超過100個欄位的表)來儲存所有的資料。
規範化表結構的目標是使“空單元”的數量最少,在上述CD表的情況下,如果你允許CD可能包含100首曲子,你會有很多這樣的空單元。不管你何時處理可能擴充套件到類似該CD表那樣數量的欄位列表,它是你需要將你的資料分割成2個或更多表的標誌,然後你一起訪問並獲得你需要的資料。
很多關聯式資料庫的新手不真正知道關聯式資料庫管理系統中關係是什麼。簡單地說,就像一組資訊存在可以基於共性資料聯結(JOIN)在一起的不同表中,很不幸,這聽上去更學術化和含糊,但CD資料庫提出了一個具體情況,我們可以研究如何規範資料。
每個CD列表有一個固定的屬性(標題、藝術家、年份、分類)集和一個不定的屬性(曲目表)集的理解給了我們一些如何分成成能相互關聯的表的思路。
你可以建立一個所有專輯及其固定屬性的表,另一個包含這些專輯的所有曲目的表。這樣不是水平思考(像表格),你垂直思考--就好像你建立列表而不是行--並建立一個如圖2的表結構:
專輯的編號(MySQL鏡自動為你生成,因為我們在列上使用了AUTO_INCREMENT屬性)關聯不同曲目到一給定專輯,tracks表中的album_id欄位匹配專輯表中的一個id。這樣要獲得給定專輯的所有曲目,你應該用如下查詢:
QUOTE:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617731/viewspace-948132/,如需轉載,請註明出處,否則將追究法律責任。
請登入後發表評論
登入
全部評論
|
相關文章
- 編寫高效能HTML網頁應用HTML網頁
- (轉載)編寫高效的jQuery程式碼jQuery
- 為Linux 應用程式編寫 DLL(轉)Linux
- 用VB編寫COM+應用時碰到問題? (轉)
- Go 編寫 Web 應用GoWeb
- 用VB寫高效的影像處理程式 (轉)
- 編寫高效能的JavaScriptJavaScript
- 編寫友好的命令列應用程式命令列
- 用Delphi編寫DelTree程式 (轉)
- 用Java編寫ASP元件 (轉)Java元件
- 用Excel編寫小遊戲 (轉)Excel遊戲
- 用PHP編寫Android應用程式PHPAndroid
- 如何編寫高效的 Shell 指令碼指令碼
- 編寫高效能的JavaScript事件JavaScript事件
- 編寫高效的Android程式碼Android
- 編寫高效的 CSS 選擇器CSS
- 編寫高效能JavaScriptJavaScript
- ddosify:用Golang編寫的高效能負載測試工具Golang負載
- 用VC++編寫CGI程式 (轉)C++
- 用VB編寫抽獎程式 (轉)
- 編寫高效能的Java程式碼Java
- 如何編寫高效的Android程式碼Android
- 高效編寫Dockerfile的幾條準則Docker
- 編寫高效能的 Swift 程式碼Swift
- 編寫高效能的 Lua 程式碼
- 編寫高效的執行緒安全類執行緒
- 用LoadRunner編寫socket應用的測試指令碼指令碼
- 編寫可以在所有WINDOWS平臺上執行的應用軟體 (轉)Windows
- 編寫Linux實用程式的藝術(轉)Linux
- [譯] 如何編寫全棧 JavaScript 應用全棧JavaScript
- 編寫iOS應用程式有何不同iOS
- Mysql高效的模糊查詢(轉)MySql
- 用Delphi編寫安裝程式(1) (轉)
- 用VB編寫標準CGI程式 (轉)
- 用 C++Builder 編寫 Tray 程式 (轉)C++UI
- 用PHP編寫email群發器 (轉)PHPAI
- 如何編寫乾淨高效的CSS程式碼CSS
- 高效的jQuery程式碼編寫技巧總結jQuery