開篇語
最近12306又崩潰了一次，但其實12306這樣的體量跟我們平常接觸的架構基本沒什么太大的關系。
話又說回來，12306也是由一個個小功能組成的。
做好自己的小螞蟻，就能讓大部隊變得更快。
因為跟數據庫、數據倉庫、查詢打交道比較多，所以我就簡單說一下數據查詢的優化過程吧。
不客氣地說，在性能優化中，其實80%的問題都是源於數據查詢。
以下步驟是以優化代價、數據量級為衡量，從低到高開始，步步進推。
GO
（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.