大家應(yīng)該都遇到過WEB應(yīng)用數(shù)據(jù)庫訪問慢的問題，如果只是少量的頁面訪問有問題（性能問題）時，優(yōu)化是非常簡單的。但是如果是“所有的都慢”，需要如何做呢？
10年積累的網(wǎng)站設(shè)計、成都網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有昭化免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
看那些來自于數(shù)據(jù)庫并且在頁面上顯示的信息。這是重要的，因為這些信息是需要用這樣或那樣的方法從數(shù)據(jù)庫中讀取出來的，如果確實是打算這樣顯示的話。任務(wù)就是要使用最高效的方法，從數(shù)據(jù)庫中得到這些信息。
考查這些信息的動態(tài)性。如果很少改變，或者干脆就是靜態(tài)的，那么比較好的方法是預(yù)先創(chuàng)建（pre-create）或者緩存它。只是要記住，優(yōu)化數(shù)據(jù)庫訪問的最好的方法，就是避免訪問數(shù)據(jù)庫。這對于其他的類似事情也適用----如果可以完全避免動態(tài)頁面的產(chǎn)生，并且使用服務(wù)器的緩存來解決，就更好了。
檢查從數(shù)據(jù)庫讀出的數(shù)據(jù)與需要顯示的信息是否相符。從數(shù)據(jù)庫出讀取的信息，往往比生成頁面所需要的信息要多。輕一點的像是SELECT*FROMtbl，而不是只列出那些真正需要的列；嚴(yán)重的可以是用SELECT*FROMtbl來計算表中有多少行記錄（不是開玩笑）。有時候會看到查詢了100個stories，其中任一個會被選擇顯示出來，由應(yīng)用程序?qū)幼鲞^濾。有時候在應(yīng)用程序?qū)舆@樣做是高效的，但是通常應(yīng)該使查詢只返回需要的信息。
檢查結(jié)果集的記錄數(shù)。這是非常重要、而且經(jīng)常被遺忘的步驟。如果一個查詢返回很少的行數(shù)，有些人就認(rèn)為它是簡單的，而真正重要的是這個查詢分析了多少行數(shù)據(jù)。比如SELECTCOUNT(*)FROMlinksWHEREdomain=“mysql.com”;只返回一行，但卻掃描了成千上萬的記錄（或者索引節(jié)點）。其他通常的殺手查詢是GROUPBY查詢和SORT查詢----SELECTname,descrFROMtitlesORDERBYrankDESCLIMIT10----如果沒有適當(dāng)?shù)乃饕?，就會使用“filesort”，會有些問題。此外就是JOIN（關(guān)聯(lián)）----關(guān)聯(lián)是高代價的（當(dāng)然是相對的），并且確實增加了為了產(chǎn)生結(jié)果集而使用的數(shù)據(jù)量----如果不得不關(guān)聯(lián)10個表來組合出想要的結(jié)果，那么會比從一個表中得到同樣的數(shù)據(jù)要慢很多。
檢查結(jié)果集的生成實際需要的記錄數(shù)。有時查詢需要使用大量數(shù)據(jù)來產(chǎn)生結(jié)果集，是因為沒有適當(dāng)?shù)乃饕?---這是容易發(fā)生的。比如我們的ORDERBYrank查詢就是這樣----為rank列增加索引，會使這個查詢僅使用10行數(shù)據(jù)來返回10行----恰恰是我們想要的。然而我們的COUNT(*)查詢是不同的----即使在domain列上有索引，它仍然需要掃描很多行數(shù)據(jù)來得到結(jié)果集。這樣的查詢需要重新設(shè)計，而不是簡單地調(diào)整----比如匯總表（summarytable）保存了每個域的link數(shù)量，就可以解決。
檢查查詢的次數(shù)。如果可以使用一個查詢得到所需要的數(shù)據(jù)，那么就好于用多個查詢得到同樣的數(shù)據(jù)，前提是這一個查詢不會因為與那些查詢優(yōu)化方式不同而需要分析更多行的數(shù)據(jù)。這里一個典型的例子是SELECT*FROMtblWHEREid=5執(zhí)行了很多次，每次使用不同的常量----用類似IN(5,7,4,56)來替換是非常有效的。但也不要被這樣的方法迷住。我曾經(jīng)看到有人嘗試用UNION（需要適當(dāng)填充以使不同的字段數(shù)目及類型能夠匹配）連接所有的查詢----這不是個好主意。然而，如果可以減小查詢的次數(shù)，而又不會增加應(yīng)用程序架構(gòu)的復(fù)雜性，那么是值得做的。
重慶分公司
重慶分公司
