對與數據庫的性能，有很多注意事項
入行這些年，以為積累了這些就夠了，也以為這些是對的，其實多為表面現象，似似而非
1：不要用select *，因為這影響性能，但是人懶，沒辦法，用了那么多select *，也沒見死機不是
2：where 后面的東西要走索引，所以經常玩命的建立索引，反復的看查詢分析器，到底走索引了沒，單純為了走索引而走索引，以至於出現
nG數據2nG的索引
3：小子加with（nolock）了沒，服務器死鎖了！沒加趕快加，但是難免犯懶，這個東西加沒加也缺乏有效的檢測，經常這個人忘了加，哪個人忘了加我怎么知道，哎說多了都是淚
4：sql服務器主要的性能指標為CPU,和鏈接數，直到后來，才知道這些只是表現，sql服務器的主要指標是io，其次是cpu和連接數
5：為了提高性能，寫一個老復雜老長的sql，后來才知道，這個老復雜老長的sql表面上性能高了，實際上反而降低了,尤其是並發來的時候的時候
6：項目的開始，必然是以一個數據庫開始了，里面放了所有需要的表。。。。。。
直到有一次打電話給運維dba
問，我們要提高數據庫穩定性改咋整？
運維回復：你要做讀寫分離還是要做主從還是要做啥呢，啪啦啪啦啪啦啪啦啪啦啪啦啪啦，
最后根據你們服務器io的表現，建議啥也別做自己優化程序吧，當時就想吧第一個創建數據庫的人，第一個創建表的人（雖然已經離職N年了）拉出來，問：你當初建表的時候咋就不考慮這些呢？
從運維的角度，提高數據庫穩定性的基本手段只能是讀寫分離（確保寫入數據沒問題，保持數據流暢通，不掉鏈子），一主多從或多主多從
參考 http://blog.csdn.net/wanmdb/article/details/7515277 這篇文章，
主從庫之間是一種發布訂閱的關系，發布者和訂閱者之間並非實時同步的，通常會有幾分鍾的延時，更有甚者會有幾個小時的延時。所以我們需要通過合理的使用來避開有延時這個問題。我們希望主庫盡可能的少參與查詢，來提高寫的及時性；同時要讓從庫在不影響讀出數據的准確及時的前提下盡可能的分擔主庫的壓力
（PS:運維還說，做了主從或什么的，必須是整個數據庫進行同步，而不是某幾個表，同時，整個數據庫表的結構的修改，新增或刪除表有可能導致意外風險時同步失敗等等啪啦啪啦啪啦啪啦）
從一個數據庫變成多個一摸一樣的數據庫，是解決數據庫穩定性
隨之產生的問題就是延遲！！！！！！！！！！！！！！！！！！！！！
首先本人聲明，本人還沒做過基於mssql主從數據庫上的程序，新浪sae的APP由於讀寫分離延遲太小忽略不計了，而且是mysql的
根據項目老大和運維dba的分析影響主從時候延遲的因素主要有
1：你這個主庫寫入的數據的速度快不快啊，如果快了，那就得把寫的快的表和字段拆出去
2：你這個主庫修改的速度快不快啊，如果快了，那就得把修改快的字段拆出去
3：你這個主庫整體寫入和修改的速度快不快啊，如果快了，那就得一分為二
4：你的這個查詢啊，那些有group 等的都在那些表上，該拎出來的就拎出來
5：至於寬帶、硬盤讀寫性能、cpu等我們都是無力改變的，就當做不知道吧
6：你們看着辦吧
總而言之，言而總之，以前我對sql的性能總停留在 索引上和select * 上，這其實是不科學的表面現象，至少走沒走索引你監控不了那個查詢造成ip或cpu高了
sql服務器可以監控的指標
1：io 是否滿載，是否出現sina（x） 那樣的波浪線，頻繁的滿載
ps：很多情況下，io頻繁滿載，例如周五，各個單位做數據匯總交差，管理員后來查詢統計拉掛數據庫服務器，進而拉掛前台展示站點。。。。
2：cpu是否滿載，是否出現sina（x） 那樣的波浪線，頻繁的滿載
cpu：說實話你有沒有在sql里面寫死循環，沒寫死循環cpu應該沒事
3：連接數是否滿載，是否出現sina（x） 那樣的波浪線，頻繁的滿載
趕緊看看流量漲了沒，是漲了多少，是以前的一倍還是2倍還是多少，如果少於3倍，問題必然出在1和2上
這3個要素也是運維或dba決定怎么搞數據庫的主要指標，
話說基於主從結構的數據庫改如何設計呢？
其實我也沒設計過，最近我在折騰我自己的抓取站點，才第一次自己操刀給數據庫分表，坑多路少。。。
根據運維和dba的意見（核心思想）----不管你做什么我們一年只給年干幾次這樣的操作！也就是主從設置什么的1年只設置幾次，因為同步失敗呀什么的就不管了。
根據我入行3年的個人經驗整理如下（ps：這些均不考慮需要帶鎖的場景，我還沒用過鎖呢。。。。。）
1：以慢慢寫為主的主庫，例如博客園存放博文的表放的庫，不可能出現1分鍾1入100條數據的表
2：以快快讀為主的讀庫，禁止使用各種鎖，禁止使用各種表聯合查詢，禁止使用group等高io操作
3：以慢慢讀為主的低並發庫，例如各種要求時時查詢（分鍾級別），各種統計，各種查詢
4：以快快寫為主的庫，這個庫只作災備切換處理，例如點擊量統計、系統日志等
最后根據經過驗，實現以上4點，沒有搜索聚合數據這個工具是不行，剛開始了解lucene，了解的不多，歡迎高手拍磚。
最后就是關於orm
因為dba說，這個設置了，就不能隨便新增表和修改表的結構了
隨便應該是1小時改一次，不隨便，應該是1各月弄一次，
鑒於此，肯定需要在所有表上新增備用字段，例如 50個 bigint，50個 字符串，表也得新增備用的，假設一個月操作一次，那就准備50張表，每個表50個bigint50個字符串，這個時候，字段的命名只能是a、B、c、d等等，你知道他們是什么意思嗎？肯定不知道，這個時候，orm作為數據庫和實體的對應關系就發揮了很大的作用
1 可以定義 a 是什么，價格、點擊量等等
2 一張表可以分組映射很實體對象，方面修改查詢部分字段，減少數據庫對單個人的復雜度
其實orm在復雜查詢下的價值不是很大，但是在數據庫結構很復雜的情況下，orm的作用就很大了
不知道大家發現了沒