網站建設需要做好數據庫優化
網速再怎麼快，程序語言如JSP再怎麼先進，如果你的數據庫沒有優化好，查詢一個幾百條數據庫就很吃力的話，那麼網站建設是失敗的，做好網站的優化，數據庫是關鍵，大多的網站都是動態的，需要實時連接數據庫，那麼數據庫的優化問題就值得大家去了解了，下面長沙久安網絡公司爲你分析數據庫如何優化。
那什麼是數據庫優化了，數據庫優化，簡單地說，是根據一開始網站數據庫設計而進行的優化。開始網站設計的時候，可能考慮的不是很全面。後期網站訪問量增加，出現頁面數據顯示過慢，程序執行效果差等現象。優化數據庫從而加速數據讀取，頁面訪問速度加快
A.sql語句優化，指對查詢語句，增，刪，改等進行優化
B.增加索引，索引需要在數據量超大的時候加，一般不建議加，因爲每增加一條記錄會索引一次，添加時慢，可以到了一萬條或幾萬，一次生成索引，就方便多。淘寶購物網 www.taotaoww.com 淘寶購物網,數據庫索引做得不錯，打開速度快
B.程序優化，指如ASP，PHP，JSP等程序對數據庫的接口語句優化。
數據庫優化，只有優化了數據庫，使其性能提升，運用數據庫時才能方便快捷。目前web2.0的程序，很大瓶頸是數據庫的吞度量。不過，如何才能確定系統的瓶頸是數據庫呢，因爲只有確定數據庫是整個系統的瓶頸，我們纔有必要去優化他，畢竟，還有這麼多需求等待我們去做。
知道數據庫是瓶頸了，如何來進行優化呢?
1 我們第一個想到是看看數據庫的容量是不是太大了，如果數據庫表太大的話，索引文件也會比較大，每次的更新操作就會更加的費時。需要考慮進行分庫和分表了。
分庫分表按照一定的規則來對數據庫中的記錄進行分區來存儲，一方面可以做到一定的負載均衡，將請求平分下來，每個區段去獨自承受;另一方面，分庫分表可以使我們存儲和操作更多的數據。
不過分庫分表需要多之前基於單庫的程序進行修改，存在一定的風險，因此，在程序設計之初就應該考慮到分庫分表的需要，最好是將數據庫操作層獨立出來，便於擴展和更改。
2 如果數據庫表不是很大，但是查詢慢的話，我們需要檢查一下我們的sql查詢語句，利用mysql的explain語句看看是不是使用了索引，如果沒有使用索引，那我們需要在相應的字段上建上索引，反覆的使用explain，尋找到個一個合適的索引。
確定數據庫是瓶頸?
1 如果程序設計良好，有一個數據庫操作邏輯層，可以從這個層的統計數據看到每個請求花費的時間，如果平均時間已經不能讓你容忍的話，數據庫已經是瓶頸了。
2 在數據庫的服務器上使用top命令，看看mysql服務器佔用資源的情況，看看機子的平均負載。
如果服務器的平均負載已經很高，mysql佔用了塊100%的cpu資源，說明mysql服務器很忙了。
3 在數據庫服務器上使用iostat命令，看看磁盤IO，如果block住的操作比較多的話，說明數據庫操作還是過於頻繁了，磁盤都響應不急了。
4 建議打開mysql的慢查詢日誌，這樣grep select看一下日誌中的慢查詢的數量，如果數量較多，說明慢查詢的數量很多，需要進行調整了。
5 如果有一天數據庫無法插入了，需要檢查一下數據庫表是不是過大了。32位的操作系統上一個表最大的容量是2^32這麼大。不過還是建議增加一個數據庫操作的邏輯層，在數據庫操作的前後記錄下操作的時間，進行統計上報，利用監控程序來報警相關負責人，這樣可以及早的知道數據庫是瓶頸，提前做出優化。
建索引時需要考慮：
1)數據庫的索引要做到越少越好：因爲每次更新都需要更新索引，索引過多就會降低寫入的速度
2)最窄的字段放在鍵的左邊：這樣提高了索引中每一個點的基數，帶來更好的索引讀寫性能
3)儘量避免file sort排序、臨時表和表掃描：對於大表，全表掃描會導致大量的磁盤IO的操作，會導致操作非常的緩慢
4)對於大表，儘量不要將索引建在字符串類型的列上，字符串的匹配是很費時的，需要付出很高的性能代價，如果一定有必要，建議對字符串列進行hash後取一個整形的值來進行索引。
3 如果更新操作有點慢，而讀操作的響應要求不需要很及時的話，可以考慮利用mysql的主從熱備來分擔讀寫的壓力。
畢竟對數據庫的操作，寫少讀多。因此，我們將對數據庫的寫操作放到mysql的主服務器上，利用mysql的熱備，我們在備份的數據庫服務器上進行讀操作，由於可以有多個熱備mysql，於是可以將讀操作分佈在多個熱備上面，從而將讀操作均衡開來，提高讀操作的性能。
4 緩存的使用
緩存是一切後臺程序的根本，因爲80%的請求是對應20%的數據，我們只需要少量的內存將20%的數據緩存起來，就可以大大的滿足我們系統需求，何樂而不爲呢。
1)mysql設置中儘量增加key cache，thread cache、查詢的cache
2)在應用程序層增加一個memcached這樣的通用cache
3)對於少量數據，但是操作頻繁的表使用mysql提供的內存heap表，可以獲得極高的寫入和讀取速度
5 數據庫的設計上進行優化
對於傳統的數據庫設計我們講究建模範式，避免數據的冗餘從而導致髒數據。然而在我們實際的應用中需要根據情況來使用第三範式的一些規則，對於一些頻繁需要在多個地方出現的數據，如同一個論壇這種用戶和主題以及回覆等有關聯的應用中，如果我們將用戶同主題和回覆分開來存儲，每次查詢一下一篇文章或者一個回覆的情況都需要對用戶表和主題表或者回復表進行聯查，如果數據量小的話，這樣聯查的性能還是可以接受的，如果表大一點，上了3、4十萬以上的數據，聯查的速度就會比較慢了。
該範式化的地方需要進行範式化，但是還是需要根據情況來設計我們的表，從而達到性能和良好設計的折中。
其它的話：
1 對於數據庫的操作建議分層處理，至少分爲兩層，一層是數據庫操作的邏輯層，一層是數據庫的cache層。
從一開始就考慮如此，可以很方便在未來對數據庫進行劃分部署、分庫分表擴展
2 增加mysql的監控，監控mysql的慢查詢日誌，監控mysql的請求情況
3 根據自己的需要來選擇mysql的存儲引擎
myisam有較高的讀寫速度，但是由於表鎖定，不能同時進行快速的讀和寫。
innodb支持事務，提供了行級的鎖，但是爲了使用事務，表空間會比較大，而且不支持全文索引
heap將表放到內存中，適合與表小而需要頻繁操作的情況，如用戶信息，其讀寫很快，但是不是持久的，需要自己來寫工具讓其持久
4 mysql服務器的一些狀態檢測的命令
show slave status：可以看到主從同步的情況
show [full] processlist：可以看到mysql服務器的請求情況，如果發現lock情況很多，需要注意了
show status：可以看到mysql服務器的各種請求情況。
數據庫優化是一門複雜的學問。數據庫引擎優化顧問用於分析在一個或多個數據庫中運行的工作負荷的性能效果。
數據庫優化需要注意的問題
A 對什麼列建索引 不是列越多越好，而是你的程序常用哪些字段排序或條件。
B 必要時重建索引 索引用久了會引起碎片，重建索引需要謹慎。
C 索引的個數問題 越少越好，一個表最多不要超過二個。
D 複合索引要注意列順序
