7.1.1. mysql設計侷限與折衷
當使用myisam儲存引擎時，mysql使用極快速的表鎖定，以便允許多次讀或一次寫。使用該儲存引擎的最大問題出現在同乙個表中進行混合穩定資料流更新與慢速選擇。如果這只是某些表的問題，你可以使用另乙個儲存引擎。
mysql可以使用事務表和非事務表。為了更容易地讓非事務表順利工作(如果出現問題不能回滾)，mysql採用下述規則。請注意這些規則只適用於不執行在嚴格模式下或為insert或update使用ignore規定程式時。
· 所有列有預設值。請注意當執行在嚴格sql模式(包括traditional sql模式)時，必須為not null列指定預設值。
· 如果向列內插入不合適的或超出範圍的值，mysql將該列設定為「最好的可能的值」，而不是報告錯誤。對於數字值，為0、可能的最小值或最大值。對於字串，為空字串或列內可以儲存的字串。請注意當執行在嚴格模式或traditional sql模式時該行為不 適用。
· 所有表示式的計算結果返回乙個表示錯誤狀況的訊號。例如，1/0返回null。(使用error_for_division_by_zero sql模式可以更改該行為)。
如果正使用非事務表，不應該使用mysql來檢查列的內容。一般情況，最安全的(通常是最快的)方法徑是讓應用程式確保只向資料庫傳遞合法值。
7.1.2. 為可移植性設計應用程式
因為不同sql伺服器實現了標準sql的不同部分，需要花功夫來編寫可移植的sql應用程式。對很簡單的選擇/插入，很容易實現移植，但是需要的功能越多則越困難。如果想要應用程式對很多資料庫系統都快，它變得更難！
為了使乙個複雜應用程式可移植，你需要選擇它應該工作的sql伺服器，並確定這些伺服器支援什麼特性。
所有資料庫都有一些弱點。這就是它們不同的設計折衷導致的不同行為。
可以使用mysql的crash-me程式來找出能用於資料庫伺服器選擇的函式、型別和限制。crash-me並不能找出所有的特性，但是其廣度仍然很合理，可以進行大約450個測試。
crash-me可以提供的一種型別的資訊的例子：如果想要使用informix或db2，不應該使用超過18個字元的列名。
crash-me程式和mysql基準程式是獨立於資料庫的。通過觀察它們是如何編寫的，編可以知道必須為編寫獨立於資料庫的應用程式做什麼。基準本身可在mysql原始碼分發的「sql-bench」目錄下找到。它們用dbi資料庫介面以perl寫成。使用dbi本身即可以解決部分移植性問題，因為它提供與資料庫無關的的訪問方法。
如果你為資料庫的獨立性而努力，需要很好地了解每個sql伺服器的瓶頸。例如，mysql在檢索和更新myisam表記錄方面很快，但是在同乙個表上混合慢速讀者和寫者方面有乙個問題。另一方面，當你試圖訪問最近更新了(直到它們被重新整理到磁碟上)的行時，在oracle中有乙個很大的問題。事務資料庫總的來說在從記錄檔案表中生成總結表方面不是很好，因為在這種情況下，行鎖定幾乎沒有用。
為了使應用程式「確實」獨立於資料庫，需要定義乙個容易擴充套件的介面，用它可操縱資料。因為c++在大多數系統上可以適用，使用資料庫的乙個c++ 類介面是有意義的。
如果你使用某個資料庫特定的功能(例如mysql專用的replace語句)，應該為sql伺服器編碼乙個方法以實現同樣的功能。儘管慢些，但確允許其它伺服器執行同樣的任務。
如果高效能真的比準確性更重要，就像在一些web應用程式那樣，一種可行的方法是建立乙個應用層，快取所有的結果以便得到更高的效能。通過只是讓舊的結果在短時間後『過期』，能保持快取合理地重新整理。這在極高負載的情況下是相當不錯的，在此情況下，能動態地增加快取並且設定較高的過期時限直到一切恢復正常。
在這種情況下，表建立資訊應該包含快取初始大小和表重新整理頻率等資訊。
實施應用程式快取的一種方法是使用mysql查詢快取。啟用查詢快取後，伺服器可以確定是否可以重新使用查詢結果。這樣簡化了你的應用程式。
7.1.3. 我們已將mysql用在何處？
該節描述了mysql的早期應用程式。
在mysql最初開發期間，mysql的功能適合大多數客戶。mysql為瑞典的一些最大的零售商處理資料倉儲。
我們從所有商店得到所有紅利卡交易的每週總結，並且我們期望為所有店主提供有用的資訊以幫助他們得出他們的廣告戰如何影響他們的顧客。
資料是相當巨量的(大約每月7百萬宗交易總結)並且我們儲存4-10年來的資料需要呈現給使用者。我們每週從顧客那裡得到請求，他們想要「立刻」訪問來自該資料的新報告。
我們通過每月將所有資訊儲存在壓縮的「交易」表中來解決它。我們有一套簡單的巨集/指令碼用來生成來自交易表的不同條件( 產品組、顧客id，商店...)的總結表。報告是由乙個進行語法分析網頁的小perl指令碼動態生成的網頁，在指令碼中執行sql語句並且插入結果。我們很想使用php或mod_perl，但是那時它們還不可用。
對圖形資料，我們用c語言編寫了乙個簡單的工具，它能基於那些結果處理sql查詢結果並生成gif圖形。該工具也從分析web網頁的perl指令碼中動態地執行。
在大多數情況下，乙個新的報告通過簡單地複製乙個現有指令碼並且修改其中的sql查詢來完成。在一些情況下，我們將需要把更多的列加到乙個現有的總結表中或產生乙個新的，但是這也相當簡單，因為我們在磁碟上儲存所有交易表。（目前我們大約有50g的交易表和200g的其它顧客資料)。
我們也讓我們的顧客直接用odbc訪問總結表以便高階使用者能自己用這些資料進行試驗。
該系統工作得很好，我們可以毫無問題地用很適度的sun ultra sparc工作站硬體(2x200mhz)來處理資料。該系統被逐步移植到了linux中。
7.1.4. mysql基準套件
本節應該包含mysql基準套件(和crash-me)的技術描述，但是該描述還沒寫成。目前，你可以通過在mysql原始碼分發中的「sql-bench」目錄下的**和結果了解基準套件是如何工作的。
通過基準使用者可以了解乙個給定的sql實現在哪方面執行得很好或很糟糕。
注意，這個基準是單執行緒的，它可以測量操作執行的最小時間。我們計畫將來在基準套件中新增多執行緒測試。
要使用基準套件，必須滿足下面的要求：
· 基準指令碼用perl編寫而成，使用perl dbi模組訪問資料庫伺服器，因此必須安裝dbi。還需要為每個待測試的伺服器提供伺服器專用dbd驅動程式。例如，要測試mysql、postgresql和db2，必須安裝dbd::mysql、dbd::pg和dbd::db2模組。
獲得mysql原始碼分發後，可以在sql-bench目錄找到基準套件。要執行基準測試，應構建mysql，然後進入sql-bench目錄並執行run-all-tests指令碼：
shell> cd sql-bench
shell> perl run-all-tests --server=server_name
server_name是乙個支援的伺服器。要獲得所有選項和支援的伺服器，呼叫命令： shell> perl run-all-tests --help
crash-me指令碼也位於sql-bench目錄。crash-me嘗試通過實際執行查詢確定資料庫支援的特性以及其功能和限制。例如，它確定：
· 支援什麼列型別
· 支援多少索引
· 支援什麼函式
· 查詢可以多大
· varchar列可以
7.1.5. 使用自己的基準
一定要測試應用程式和資料庫，以發現瓶頸在哪兒。通過修正它(或通過用乙個「啞模組」代替瓶頸)，可以很容易地確定下乙個瓶頸。即使你的應用程式的整體效能目前可以接受，至少應該對每個瓶頸做乙個計畫，如果某天確實需要更好的效能，應知道如何解決它。
關於一些可移植的基準程式的例子，參見mysql基準套件。可以利用這個套件的任何程式並且根據你的需要修改它。通過這樣做，可以嘗試不同的問題的解決方案並測試哪乙個是最好的解決方案。
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...
資料庫優化
資料庫優化 1 合理使用索引 索引是資料庫中重要的資料結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下 在經常進行連線，但是沒有指定為外來鍵的列上建立索引，而不經常連線的字段則由優化器自動生成索引 在頻繁進行排序或分組 即進行groupby或orderby操作 的列上建立索引...