最近12306又崩潰了一次，但其實12306這樣的體量跟我們平常接觸的架構基本沒什麼太大的關係。
話又說回來，12306也是由乙個個小功能組成的。
做好自己的小螞蟻，就能讓大部隊變得更快。
因為跟資料庫、資料倉儲、查詢打交道比較多，所以我就簡單說一下資料查詢的優化過程吧。
不客氣地說，在效能優化中，其實80%的問題都是源於資料查詢。
以下步驟是以優化代價、資料量級為衡量，從低到高開始，步步進推。
（1）如果資料查詢緩慢，80%的原因都是因為sql。先找出慢sql，以oracle為例，可以通過awr報表的方式檢視。
（2）檢視慢sql的執行計畫，看看查詢的關鍵字段是不是缺失索引，新增索引。
（3）有索引，但是檢視執行計畫，並沒有走索引。此時有兩種方法，一是用hint，二是可能資料表最近被大批量的刪除、新增過，需要手動收集資料表的統計資訊，讓sql優化器正常解析sql。
（4）資料表太大，沒有合適的全域性索引。可不可以建設分割槽表？按照時間、地區進行分割槽操作。
（5）不能分割槽，或者分割槽效果也不顯著，需要考慮改動表結構了，有些字段是不是可以拆出去？做成維表、擴充套件表？
【這是垂直拆分。缺點是查詢時如果要查詢擴充套件表字段，需要join操作，插入修改時要考慮多表，事物複雜。單錶資料量還是太大。】
（6）或者可以考慮進行分庫分表操作。對於oracle來說單張1億以下資料分割槽就夠了，不需要分庫分表。
【水平拆分。缺點是會導致事物一致性更為複雜，還需引入分庫分表的管理中介軟體。】
（7）進行歷史資料分離。將一些不常用的資料，例如兩年前的資料都拆分到歷史表中。
【即冷熱資料分離。】
（8）讀寫分離，再新建個資料查詢庫，oracle用ogg、mysql用binlog做資料同步，將查詢模組更換資料來源。
（9）增加資料庫的伺服器效能，公升級硬體，例如磁碟換上ssd。這個方法是被驗證過了的，尤其是查詢批量資料、無高效索引的時候。
（10）從資料庫層面已經無法優化了，我們可以考慮在應用端使用並行查詢的方法爬出資料，然後再行合併。
【事實上，很多報表工具都是這麼做的。】
（11）並行查詢再高階點，用流行的話來說，叫分布式計算。
【12306就是用pivotal的 gemfire，將單次查詢的最長時間從15秒下降到0.2秒以下。】
（12）這個資料庫效能就是達到瓶頸了，我們來更換資料庫吧，換成效能更好的資料庫，要做資料遷移，重新測試驗證，代價不菲。
（13）從業務上去優化，看看這樣查詢是不是有道理，這些字段是不是確實需要？需不需要這麼精細？需不需要這麼頻繁？
大資料量報表每月一出就行了？那這樣就無所謂時效性了。嗯，那我們來做資料倉儲吧。
（14）我們用了hadoop + rdbms做了資料倉儲。
資料倉儲不能實時查詢怎麼辦？我們來做實時倉庫吧。
（15）我們用了kafka + spark + jstorm做了實時倉庫，結果你跟我說過時了？剛剛公升級成了spark streaming ？嗯？又換成flink了？
好吧，愛咋咋地。
說到這裡沒啥可說的了，或者以後想起來什麼還可以再說說吧。
效能優化其實是乙個持續迭代的過程，並非一蹴而就，也不是一步到位的工作。
有時候有很多方案，關鍵是看怎樣代價最小。（改造成本、硬體成本、緊急狀況）
每個人，還是先從寫好乙個sql，一段**開始吧。
撒花，結束。
end.
介面效能優化怎麼做？
後記想象一下以下幾個場景 我們在獲取乙個使用者詳情介面時，刷了無數次，瀏覽器就在那轉圈，硬是刷不出來，開啟控制台，顯示介面超時 假如我們服務a有個批量發營銷簡訊的任務，服務a用批量的userid調服務b的使用者服務以獲取使用者的手機號，從而完成簡訊傳送功能。奈何服務b的通過userid介面獲取使用者...
怎麼優化h5的效能
優化方案 資源載入 1.首屏載入 在1s內內容載入完畢，loading進度條消失 2.延時載入 先載入螢幕可視範圍內的資源，其他的在之後通過網路載入 3.滾屏載入 一種常見的動態無重新整理資料載入方法，4.響應式載入 在解析度不同的手機上使用不同的css，載入不同的資源 5.第三方資源非同步載入 引...
什麼是js資料流 當聊起前端效能優化我們要聊什麼
在前端的整個學習生涯中，我們總是能一次次聽到 效能 和 體驗 這兩個詞。前端效能優化不僅是前端工程師工作中時刻需要關注的現實問題，也是前端面試中屢屢被問到的點。面試官之所以愛問，是因為偷懶。只需問這乙個問題，就能在一定程度考察面試者的知識廣度 知識深度 總結能力 表達能力，還能沿著這條線繼續問其他問...