phoenix=hbase+sql
可以理解為在hbase的上層套了一層sql引擎，支援用sql方式訪問hbase。
支援毫秒到秒級的低延時oltp和操作型分析查詢
1.支援標準的sql語法 轉為hbase api
2.支援將運算元、過濾條件下推到server端，並行執行
3.二級索引、分頁查詢、join、輕量級事務等能力
優點:1.sql門檻低，使用便利，使用者接入成本低
2.使用者無需關心 rowkey設計, 熱點、分頁，簡單join等的設計
3.部分場景下讀取效能比直接讀hbase有提公升
為什麼部分場景比直接讀hbase快？
1.編譯sql成為原生hbase的可並行執行的scan
2.計算下推，server端的coprocessor執行聚合
3.下推where過濾條件到server端的scan filter上
4.利用統計資訊優化、選擇查詢計畫
5.二級索引提高非行鍵查詢效能
6.skip scan 能力來優化in，like和or查詢
7.可選的對行鍵進行加鹽以實現負載均衡，避免熱點
缺點:1.寫入效能相比hbase下降: 寫入時需要對字段做一定處理，對狀態表更新，效能有一定下降，在20%以內
2.複雜join、groupby 效能低: 掃瞄資料量大
3.與二級索引的一致性不夠完善，僅有3種策略
4.部分場景讀效能有提公升，但如果使用者將自己的需求以hbase原生api實現，效能相較於phoenix是更優的。phoenix內部經過解析，優化執行計畫等一些操作是有一定耗時的。
1.jdbc api
2.使用python編寫的命令列工具（sqlline, sqlline-thin和psql等）
讀:客戶端:
1.接收sql
2.parser 解析sql ，生成執行計畫queryplan
3.optimizer 優化查詢計畫(判斷索引表是否可用，如可用則替換為索引表的查詢計畫)
4.轉化成hbase 的 scan，傳送rpc請求到regionserver上
5.如有orderby count等聚合計算，請求到對應的協處理器方法上
服務端:
1.接受rpc請求，處理查詢
2.聚合計算先在多個rs上計算後，把多個計算後的結果返回給客戶端，客戶端再計算。
客戶端:
1.接收sql
2.解析轉成hbase的put ，傳送rpc請求到regionserver上(主表)
服務端:
1.接受rpc請求，處理主表的put
2.協處理器的後台執行緒，定時將新寫入主表的資料讀出，再put到索引表對應的hbase表上。
phoenix表的主鍵是由乙個或多個字段組成，適合按rowkey，或字首部分rowkey過濾查詢。但如有其他查詢場景無法指定字首rowkey，要按其他欄位做查詢條件，查詢需要掃瞄表的全量資料。hbase不適合掃瞄全表操作，資料量稍微大點掃瞄全表就不可用了。
使用索引表，查詢時可以根據索引表的主鍵快速掃瞄出需要的資料。
1.建立索引表時指定查詢場景下where 的字段和select的字段，最終索引表主鍵由做where條件的字段和主表主鍵字段一起組成，二級索引表底層也是hbase表。
2.查詢時客戶端解析sql，判斷是否有合適的二級索引，如果有則優化查詢計畫將scan落到索引表對應的hbase表上。
4.在索引表對應的hbase表上，索引表主鍵相當於rowkey，按rowkey進行掃瞄即可。
3.server端的協處理器的後台執行緒會定時將新寫入主表的資料同步到二級索引表中。(歷史資料可通過非同步補二級索引程式跑)
1.非同步建索引錶比同步建索引表多加了async標識
2.非同步索引表建好後一直是building狀態(可寫不可讀)，
3.單純依賴phoenix內部補資料線程補資料很慢，且會增加集群負載，通常直接跑非同步二級索引，跑完後索引表就是active狀態
4.新建的主表一般建同步的索引表，如果主表已經有資料 就建非同步索引表。
(如果主表有資料 建了同步的索引表，建索引表時會補數，補數完成才建立成功，耗時很久，若有同時有新寫入可能追不上)
什麼時候需要跑非同步二級索引？
建好非同步索引表後，需要補歷史主表資料的情況下需要跑。
如何跑?
使用phoenix的內建工具indextool執行。
如有需求可聯絡@資料引擎服務號v2 。
原理:
indextool是phoenix內建的工具，用作build主表全量索引資料：
工具內使用snapshot，後起indextool mr job，output並bulkload到對應hbase集群索引表，對regionserver讀寫無壓力。
為什麼會發生?
受主表索引表一致性策略影響，預設策略是: 當寫索引表失敗後，disable索引表，不阻塞主表寫。
這樣帶來的風險是:當寫索引表失敗時，索引表被disable，所有查詢落到主表上，出現掃全表情況，查詢慢超時，rs宕機，還可能影響其他業務。
ps:第3種策略是disable索引表，不阻塞主表寫，這樣資料會不一致，不建議使用。
影響:查詢時落到主表會掃全表
恢復:
1.確定寫索引表失敗原因，機器問題就挪出。更新索引表狀態為active
2.寫入還是失敗可能需要重啟rs（主表和索引表盡量在不同分組，避免滾動公升級期間寫索引表失敗引發一系列問題）
現象: 索引表禁用時間戳(index_disable_timestamp)>0
影響: sql的查詢落到了主表上，沒有落到索引表上。由於主鍵不同，落到主表上後會掃全表，帶來rs壓力變大甚至宕機的風險。
需要做:
1.確定索引表狀態(查system.catalog表)
2.恢復主表下所有索引表狀態為active(alter set)
alter index idx_p002 on test_ns.p003 active;
3.如有主表索引表資料不一致的風險，需要補資料。
索引表被disable期間，如果繼續寫資料，資料會有不一致的情況。
狀態:
SQ 模糊查詢
between.and.在資料庫內部是做作特殊優化的,執行效率比 and 等這種方式快 between a and b 相當於 字段 a and欄位 b 例如 select from dbo.mystudent where s age between 20 and 30 between and還可以...
SQ優化策略
1.對查詢進行優化，要盡量避免全表掃瞄，首先應考慮在進行條件判斷的字段上建立索引 2.應盡量避免在where子句中對字段進行null值判斷，否則將導致引擎放棄使用索引而進行全表掃瞄 select from scott emp where job is null 3.應盡量避免在where字句中使用 ...
sq分頁原理
查詢第x頁,每頁y條記錄 最基本的處理方法 原理 如果表中有主鍵 記錄不重複的字段也可以 可以用類似下面的方法,當然y,x 1 y要換成具體的數字,不能用變數 select top y from 表 where 主鍵 not in select top x 1 y 主鍵 from 表 如果表中無主鍵...