面試題1: MySQL為什么用B+樹，而不用B樹？
1.b+樹只有葉子節點存數據 b樹是每個節點都存數據 在相同數據量下b樹的高度更高,所以查詢效率更低
2.b樹每一層存的是數據+索引;
b+樹是除了葉子節點存的是數據+索引以外,其余節點只存索引,所以在相同數據量的情況下,b樹的高度會比b+ 樹高很多
面試題2:微服務架構中日志有什么好方案嗎?
兩個方案，本地分析或收集匯總，收集可以走大數據的解決方案。本地分析一般是在宿主機上安裝代理，執行分析命令，上報到服務器
面試題3:Mysql主從的延遲怎么解決呢，有什么好的思路嗎？
可以從兩個方面去處理
一：架構方面
1.業務的持久化層的實現采用分庫架構，mysql服務可平行擴展，分散壓力。
2.單個庫讀寫分離，一主多從，主寫從讀，分散壓力。這樣從庫壓力比主庫高，保護主庫。
3.服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力。
4.不同業務的mysql物理上放在不同機器，分散壓力。
5.使用比主庫更好的硬件設備作為slave總結，mysql壓力小，延遲自然會變小。
二：硬件方面
硬件強勁，延遲自然會變小。一句話，縮小延遲的解決方案就是花錢和花時間。
三：主從延遲，主要還是因為主庫性能問題，合理的優化表結構和索引，控制好單表的數據量。然后我們再降低主庫的壓力，比如讀寫分離
面試題4:mysql隱式轉換不走索引怎么辦?
當操作符左右兩邊的數據類型不一致時，會發生隱式轉換。where查詢操作符左邊為數值類型時發生了隱式轉換，那么對效率影響不大，但是當左邊為字符類型時發生了隱式轉換，那么會導致索引失效，造成全表掃描效率極低。
面試題5:insert 慢有哪些原因啊?
看一下是不是數據庫堵塞了，然后排查一下插入的數據是不是特別大，然后看一下是不是到達數據庫瓶頸了。
面試題6:我們也在用RocketMQ，之前的架構比較簡單，公司准備做微服務化，現在讓我負責這一塊，感覺微服務就是拆分，想象不出有啥問題，心理有些沒底，想問下都需要注意哪些點?
微服務是一種架構方式，拆分這個事不是核心問題，重點在服務治理能力。服務治理跟不上，拆分就是災難。
那么問題來了，服務治理一般都包括哪些工作?
這個要是說起來就比較多了比如服務注冊與發現、 軟負載均衡與容錯、 服務監控與統計、 服務容量評估、 服務上線審批、. 服務下線通知等等等