mysql是開源資料庫，在網際網路界非常受歡迎，有著極為廣泛的應用。這是由mysql的特點和網際網路公司的使用場景決定的。首先從mysql的特點上看，mysql簡單易用，有著極高的穩定性，同時簡單查詢時效能極高；mysql的功能很完備，常用的功能幾乎都有；開源，功能可自己定製，使用成本低廉；可以支援多種不同用途的儲存引擎，以應對不同的業務場景等。同時mysql又是脆弱的，乙個複雜sql或者大表join就可能是mysql負載過重，資源耗盡。
網際網路公司往往有高併發、大資料量的特點，同時為了在和競品的競爭中佔得先機，產品會不斷迭代，新產品不斷推出。從技術的角度講，面臨的問題往往很難**；同時為了拉新使用者或者**，往往有大規模的運營推廣活動，例如著名的「雙十一」，活動期間訪問和交易流量往往是平時的幾倍甚至幾十倍，如果把系統容量擴充套件到活動的容量，因為平時的流量沒這麼大，會造成資源浪費；如果活動期間不擴充套件系統容量，系統又扛不住突增的流量，從技術的角度講，希望系統有伸縮能力，既能在活動期間擴容，可以應對突增的流量，又能在活動結束後縮容，不造成資源的浪費，所以網際網路公司往往對系統伸縮能力有著執著的追求。
結合mysql的特點和網際網路公司的特點，為什麼mysql會在網際網路界廣受歡迎呢，大體有以下幾點：
1. 免費：網際網路公司內部很多設施需要使用資料庫，有些系統會使用多個資料庫，如果使用強大的商用資料庫，按許可收費，成本高的驚人。國內網際網路公司往往走微利模式，創業前幾年幾乎沒有盈利能力，廣泛使用雖然強大但使用成本高昂的商用資料庫對絕大多數網際網路公司是不可承受之重，就算使用也往往只能在某些關鍵系統中使用；
2. 開源：網際網路公司面臨的場景和問題很複雜，如果依靠廠商提供技術支援，很難及時處理遇到的問題，影響自身業務的發展。而使用開源的mysql可以根據自身的業務特點和面臨的問題，自行開發需要的功能，解決資金的問題；
3. 網際網路公司普遍追求橫向擴充套件性：面臨高併發、大資料量難題時，網際網路公司普遍採用分庫分表的方式擴充套件容量，使用mysql時不需要考慮分庫時增加資料庫許可的成本；
4. 網際網路公司業務一般不複雜，而且讀遠多於寫，剛好是mysql擅長的場景；
在這裡提一下mysql的innodb儲存引擎。從mysql5.5之後，innodb成為預設的儲存引擎，innodb是個相當全面，而且均衡的儲存引擎，支援全面的acid事務特性；引入行級鎖，大幅度提公升了併發能力；使用mvcc方式也大幅提公升併發效能；查詢效能與myisam相比並不差。
在網際網路公司高併發的場景下，對mysql的使用稍有失誤就可能讓mysql負載增加，速度降低，所以在設計和使用mysql時要比較小心，任何乙個無用都可能帶來嚴重的後果。在高併發、大資料量的網際網路應用中，系統的擴充套件性是個至關重要的考量，基於這點考慮，往往把業務邏輯寫在容易擴充套件的應用**中，因為擴充套件資料庫的難度和代價遠遠大於擴充套件應用。只要應用是無狀態的，只要往應用集群中增加機器，應用就能線性擴充套件；而要擴充套件資料庫就就不得不做分庫分表了，而做分庫分表時不論是資料遷移，還是改造應用層或使用中介軟體都需要相當大的工作量。所以在設計網際網路應用時，在資料庫的設計和使用有相應的原則，下面就從核心設計原則和表，字段，索引的設計和使用sql方面分別描述。
核心設計原則：
不要在資料庫裡做運算，不要使用儲存過程、觸發器等(原因：資料庫的擴充套件的能力遠不如應用程式強，一旦使用了儲存過程、觸發器，當資料庫遇到瓶頸，想擴充套件就非常難了。所以，設計網際網路應用時，在合適的地方做合適的事情。就讓資料庫做資料儲存和查詢吧，至於資料轉移、運算、業務邏輯都讓應用來做吧)
平衡正規化和冗餘。在網際網路應用中為了優化查詢效能，會將必要的資訊冗餘存放，冗餘儲存的式違反了第三正規化，在提高查詢效能的同時也會帶來資料一致性的問題，這需要在業務邏輯**中保證
在網際網路應用中，資料庫訪問頻率很高，cpu、記憶體、io、網路都是緊缺資源，因此在滿足業務的前提下，降低sql尤其是高頻sql的資源消耗就是個非常重要的優化原則了，在設計表結構時，應該考慮哪些是高頻執行的sql從而採取針對性措施。
庫表設計原則：
單表字段數應控制在20個以內。乙個表的字段越多，面臨的業務場景就會越複雜，面臨可能的變化也越多。當查詢時，也會因為需要過濾的字段過多，導致更多的io消耗。這個原則也可以用另外用另外一種形式表達：拆分表中字段來分離冷熱資料。大字段和訪問頻率低的字段都會降低查詢的效率，分離冷熱資料後，能提示熱資料的訪問效能，降低io消耗，提高快取命中概率
控制表的資料量。當資料量超過千萬級別後，即使硬體效能強大，sql執行時間也會下降
選擇字段型別時，在滿足正確儲存業務資料要求的前提下，選擇最短的。越小的字段，訪問效率越高。不要使用text、blob型別；不得不使用text、blob型別時，拆分到單獨表中；用decimal代替float和double儲存精確浮點數；使用整數替代浮點數：比如用分為單位表示以元為單位的金額；使用數字或enum代替字元或字串
如果可能的話所有欄位均定義為not null，因為null值使索引失效。對於資料量比較大的表而言，索引失效時查詢將是災難性的低效
索引對於效能來說非常關鍵，尤其是資料量非常越大時。查詢時使用到索引可以減少查詢時掃瞄的資料量、避免排序、將隨機io轉為順序io。代價就是修改或刪除資料時，索引需要重新排序，降低了效能。索引還能使查詢條件命中的索引作為行鎖的條件
索引設計使用原則：
將索引建立在高區分度欄位上。索引是按照字段內容排序的，如果字段值區分度不高，在索引中將有很多大段的相同值，用這樣的索引查詢時，過濾效果非常不明顯，所以不要在區分度低的字段上建立索引。字段值區分度高時可以根據查詢值迅速定位查詢結果，提示查詢效率
索引應該建立在短字段上。盡量不要建在長字串上，如果不可避免，可以選擇字串的開頭幾位。建立索引時要把字段內容儲存到索引中，所以欄位越長，索引占得硬碟空間也就越大，查詢時消耗的硬碟io資源也就越大，耗時越長
建立復合索引時索引的列順序至關重要。查詢有多個條件時，適合使用復合索引查詢。如果有多種查詢組合條件，復合索引建立得當的話，復合索引可以復用。建立復合索引時，自個欄位的順序仍然優先按照區分度，其次再考慮索引復用
不要在索引列上進行數**算、函式運算（會使索引失效）
單張表中索參數量不超過5個，單個索引中的字段數不超過5個，通常將選擇性最高的列放在最前面。如果乙個表的索引太多，最可能的原因是開始時這個表擔負了太多的職責，考慮將此表的職責拆分。
sql使用原則：
拒絕大sql，盡可能不做表之間的join操作原因：
- mysql更擅長簡單查詢，尤其是單錶主鍵或二級索引查詢；mysql一條sql只能使用乙個cpu，有大表join的情況下，效能下降明顯
- 大sql不僅慢，而且會大幅度降低資料庫的併發能力，甚至拖垮資料庫
- 使用多條簡單sql，使快取命中率更高，還可以使用多核
- 高併發場景下，不要使用兩個或以上的表join限制返回結果條數，否則返回滿足條件的所有記錄。大多數情況下這是不必要的，應用在處理返回的大量結果時可能崩潰
不要使用select *，只查詢需要的列
a、select * 消耗了更多的cpu，記憶體，io，網路資源；
b、使用具體字段除了減少資源消耗，還減小了表增加欄位時的影響；
避免關聯子查詢。mysql的關聯子查詢實現非常糟糕，除非有非常高深的優化功力，否則不要寫關聯子查詢。
避免負向查詢，不要使用not、!=、<>、!、not exists、not in、 not like等。不能使用索引，導致全表掃瞄，效率低下。
避免使用count。除非是非常小的表，否則盡可能使用冗餘字段計數或其他方式。
分頁時避免傳統的limit offset, size方式分頁。這種方式隨著偏移量大，效能越來越差，可以考慮把分頁轉換成條件查詢。
使用in代替or，in的值不超過200個。in的效率（o(log n)）比or的效率(o(n))高很多。
使用預編譯的sql。使用預編譯的sql不僅能防sql注入攻擊，還可以避免mysql伺服器編譯的開銷。
杏樹林研發 劉亞輝
mysql 網際網路 MySQL網際網路業務使用建議
一 基礎規範 表儲存引擎必須使用innodb 表字符集預設使用utf8，必要時候使用utf8mb4 解讀 1 通用，無亂碼風險，漢字3位元組，英文1位元組 2 utf8mb4是utf8的超集，有儲存4位元組例如表情符號時，使用它 禁止使用儲存過程，檢視，觸發器，event 解讀 1 對資料庫效能影響...
網際網路及其應用
網際網路以tcp ip進行資料通訊，是建立在一組共同協議之上的網路裝置和線路的物理集合，實現資料交換和資源共享 網際網路網路系統由網路硬體和網路軟體組成。網路硬體包括 伺服器，工作站，網絡卡，通訊介質。網路軟體包括 網路協議和協議軟體 網路通訊軟體和網路作業系統 網際網路的網路體系結構是一種高度結構...
網際網路最近技術應用1 網際網路電視
網路電視 ntv，network television 是以寬頻網路為載體，以視音訊多 為形式，以互動個性化為特性，為所有寬頻終端使用者提供全方位有償服務的業務。網路電視是在數位化和網路化背景下產生，是網際網路絡技術與電視技術結合的產物，在整合電視與網路兩大傳播媒介過程中，網路電視既保留了電視形象直...