共計 2530 個字符，預計需要花費 7 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章主要介紹“怎么編寫高效的 MySQL 應用”，在日常操作中，相信很多人在怎么編寫高效的 MySQL 應用問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么編寫高效的 MySQL 應用”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
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:
到此，關于“怎么編寫高效的 MySQL 應用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！
向 AI 問一下細節
