背景
因為豐巢自去年年底開始在推送平台上嘗試了TiDB，最近又要將承接豐巢所有交易的支付平台切到TiDB上。我本人一直沒有抽出時間對TiDB的源碼進行學習，最近准備開始一系列的學習和分享。由於我本人沒有數據庫相關的經驗，本着學習的心態和大家一起探討，歡迎高手隨時指正。總結一下本次學習分享的目的：
- 豐巢把最重要的兩個基礎業務都放到了TiDB上，后續應該會有更多的核心系統跑在TiDB上，我們豐巢中間件團隊作為引入TiDB到豐巢的推動人和執行者，對於TiDB的穩定性和突發事件的處理，一定要做足功課；
- 以TiDB為代表的newsql代表的是現在和未來，作為個人來說，有着充足的動力去學習；
- 我們不滿足於只是作為TiDB的使用者，我們需要在TiDB上定制開發對於豐巢更有意義的模塊，如果能給社區做貢獻，那更是非常棒的一件事；
言歸正傳，說一下本文的產生原因：去年我們在推送平台上使用TiDB的過程中，就發現老版本的TiDB是無法通過外部手段kill調用慢查詢的，而慢查詢的危害對於數據庫來說會有致命的風險，后來pingcap公司在2.1版本(具體的版本參見TiDB的說明)中增加了show processlist和kill tidb命令，但是因為TiDB本身是無狀態的，這兩個命令屬於單機命令，在使用的過程中，大家還是要提前做好准備，要直連到具體的TiDB的server上才可使用，不要通過nginx等服務進行轉發請求，到時不但不能解決問題，還有可能帶來意外的風險。今天第一章，我們先來看一下show processlist這個比較簡單的命令的源碼，下一章，我們再分析kill tidb這個命令。
源碼分析
環境信息
- 軟件：TiDB2.1.7、PD2.1.4、TiKV2.1.4；
- 硬件：為了隨時調試，TiDB跑在本機的mac上、PD和TiKV跑在linux虛擬機上；
操作過程
- 打開一個直連TiDB的客戶端，輸入命令：show PROCESSLIST；
- 客戶端會輸出下圖的列表；
上面的列表中展示了當前TiDB正在處理每個連接的sql語句詳情。
問題
在我分析源碼之前，我問了自己本次分析源碼要搞清楚的兩個問題，在這里和大家分享一下：
- show processlist到底是不是單機的命令，和TiKV、PD有沒有啥關系？
- kill tidb需要使用的id字段到底代表的是什么？
接收命令
首先，啟動TiDB server.代碼在tidb-server/main.go里面，主要方法是：runServer方法
func runServer() { err := svr.Run() } 再來看一下：server/server.go源碼：
func (s *Server) Run() error { for { conn, err := s.listener.Accept() go s.onConn(conn) } } 重點代碼是監聽端口，並創建連接，啟動另一協程去服務新來的連接，接下來再看看server.go中的onConn方法：
func (s *Server) onConn(c net.Conn) { conn := s.newConn(c) conn.Run() } 其中，s.newConn方法會將net. Conn連接包裝成clientConn連接，並分配在這個TiDB server下唯一的connectionID，此connectionID為原子變量，每次新連接自增加1，我們先記住這個id，后面分析的時候會用到它。我們來看看server/conn.go下的Run方法：
func (cc *clientConn) Run() { for { data, err := cc.readPacket() cc.dispatch(data) } } Run方法主要就是不斷的輪訓讀取clientConn中的內容，並將它交給dispatch方法進行下面的分析及返回結果操作，至此關於接收show processlist命令部分已經分析完畢，當然其它的sql語句也是經過這個過程進入到dispatch方法中的。
show processlist的構建Executor
接着分析dispatch方法在處理show processlist命令的流程：
func (cc *clientConn) dispatch(data []byte) error { switch cmd { case mysql.ComQuery: return cc.handleQuery(ctx1, hack.String(data)) } } show processlist命令屬於mysql.ComQuery，因此流程會走到handleQuery方法里面，我們來看一下：
func (cc *clientConn) handleQuery(ctx context.Context, sql string) (err error) { rs, err := cc.ctx.Execute(ctx, sql) err = cc.writeResultset(ctx, rs[0], false, 0, 0) } handleQuery中處理show processlist命令的重點代碼就是上面的兩行，我們先來看一下server/driver_tidb.go中的Execute方法：
rsList, err := tc.session.Execute(ctx, sql) Execute中的重點就是調用session/session.go中的Execute方法：
func (s *session) execute(ctx context.Context, sql string) (recordSets []sqlexec.RecordSet, err error) { s.PrepareTxnCtx(ctx) stmtNodes, warns, err := s.ParseSQL(ctx, sql, charsetInfo, collation) compiler := executor.Compiler{Ctx: s} for _, stmtNode := range stmtNodes { recordSets, err = s.executeStatement(ctx, connID, stmtNode, stmt, recordSets); } } 上面的execute方法中會對sql語句進行處理及制定執行計划，處理完成后調用executeStatement方法，executeStatement中的重點方法是runStmt：
recordSet, err := runStmt(ctx, s, stmt) 我們再來看看session/tidb.go中的runStmt方法：
func runStmt(ctx context.Context, sctx sessionctx.Context, s sqlexec.Statement) (sqlexec.RecordSet, error) { rs, err = s.Exec(ctx) err = finishStmt(ctx, sctx, se, sessVars, err) } 繼續來分析executor/adapter中的(a *ExecStmt) Exec方法，一樣采取划重點的方式：
func (a *ExecStmt) Exec(ctx context.Context) (sqlexec.RecordSet, error) { e, err := a.buildExecutor(sctx) e.Open(ctx) var pi processinfoSetter if raw, ok := sctx.(processinfoSetter); ok { pi = raw sql := a.OriginText() if simple, ok := a.Plan.(*plannercore.Simple); ok && simple.Statement != nil { if ss, ok := simple.Statement.(ast.SensitiveStmtNode); ok { // Use SecureText to avoid leak password information. sql = ss.SecureText() } } // Update processinfo, ShowProcess() will use it. pi.SetProcessInfo(sql) //fmt.Println(sql) a.Ctx.GetSessionVars().StmtCtx.StmtType = GetStmtLabel(a.StmtNode) } return &recordSet{ executor: e, stmt: a, processinfo: pi, txnStartTS: txnStartTS, }, nil } (a *ExecStmt) Exec方法中raw, ok := sctx.(processinfoSetter)這段邏輯就是把當前連接正在執行的語句存儲到processinfo里面取，關於這部分細節比較簡單，在這里不展開來分析。我們先來看看buildExecutor中做了什么事情？
b := newExecutorBuilder(ctx, a.InfoSchema) e := b.build(a.Plan) 重點要來了，在executor/builder.go中的build方法做了啥事？
case *plannercore.Show: return b.buildShow(v) build方法會根據不同的語句類型來構建不同的Executor並返回，show processlist命令會匹配到plannercore.Show類型，我們看看buildShow方法的實現：
e := &ShowExec{
baseExecutor: newBaseExecutor(b.ctx, v.Schema(), v.ExplainID()), Tp: v.Tp, DBName: model.NewCIStr(v.DBName), Table: v.Table, Column: v.Column, User: v.User, Flag: v.Flag, Full: v.Full, GlobalScope: v.GlobalScope, is: b.is, } if len(v.Conditions) == 0 { return e } sel := &SelectionExec{ baseExecutor: newBaseExecutor(b.ctx, v.Schema(), v.ExplainID(), e), filters: v.Conditions, } return sel 因為v.Conditions為0，所以返回類型為ShowExec的Executor，我們接下來再剛才的Exec方法中的e.Open方法，其實就是ShowExec的Open方法,ShowExec位於executor/show.go文件中，我們查找后發現ShowExec中沒有Open方法，我當時是被搞蒙了，后來發現這是go的一個語言特性，它使用的是baseExecutor的Open方法：
func (e *baseExecutor) Open(ctx context.Context) error { for _, child := range e.children { err := child.Open(ctx) if err != nil { return errors.Trace(err) } } return nil } 上面的方法會遍歷baseExecutor中的children的Executor，然后調用它們的Open方法，但是因為ShowExec在創建它的baseExecutor的時候，沒有任何的children，所以在show processlist這個操作過程中，Open方法相當於啥也沒干，但是大家在分析其它語句時，這個Open方法是一個很重要的方法。我們再來看剛才Exec中的最后的return塊里面，返回了包裝executor、processinfo等信息的recordSet類型。至此關於show processlist命令如何包裝成Executor並和processinfo等信息作為recordSet類型的返回值返回給上層函數分析完畢。
show processlist的獲取各個連接的processinfo信息
接下來我們再來看handleQuery中的writeResultset方法：
err = cc.writeResultset(ctx, rs[0], false, 0, 0) 在server/conn.go中的writeResultset主要的邏輯就是下面的邏輯：
err = cc.writeChunks(ctx, rs, binary, serverStatus) 我們繼續來分析writeChunks中的重要部分:
func (cc *clientConn) writeChunks(ctx context.Context, rs ResultSet, binary bool, serverStatus uint16) error { for { err := rs.Next(ctx, chk) } } writeChunks里面主要就是循環調用rs.Next的方法，直到滿足條件為止，rs的類型實際上是server/driver_tidb.go下的tidbResultSet類型，我們來看一下它的Next方法：
func (trs *tidbResultSet) Next(ctx context.Context, chk *chunk.Chunk) error { return trs.recordSet.Next(ctx, chk) } tidbResultSet的Next方法主要是調用了executor/adapter.go中的recordSet類型的Next方法，我們來看看這個Next方法：
func (a *recordSet) Next(ctx context.Context, chk *chunk.Chunk) error { err := a.executor.Next(ctx, chk) } recordSet方法的重點就是調用它的executor的Next方法，我們在上一個小節 結尾處分析出recordSet的executor就是之前生成的ShowExec(可算是找到它了，我已經累暈)。那么，我們接着分析它的Next方法：
e.fetchAll() ShowExec中的Next方法的主要邏輯就是調用它的fetchAll方法，接着往下看：
case ast.ShowProcessList: return e.fetchShowProcessList() 因為匹配到了這個case，所以會調用它的fetchShowProcessList方法：
func (e *ShowExec) fetchShowProcessList() error { sm := e.ctx.GetSessionManager() pl := sm.ShowProcessList() } 上面的sm類型的server/server.go中的Server類型，我們來看看它的ShowProcessList方法：
func (s *Server) ShowProcessList() map[uint64]util.ProcessInfo { s.rwlock.RLock() rs := make(map[uint64]util.ProcessInfo, len(s.clients)) for _, client := range s.clients { if atomic.LoadInt32(&client.status) == connStatusWaitShutdown { continue } pi := client.ctx.ShowProcess() rs[pi.ID] = pi } s.rwlock.RUnlock() return rs } 它主要是遍歷當前所有的客戶端，並獲取到所有客戶端的ShowProcess，其中的client.ctx類型為server.TiDBContext，我們來看看它的ShowProcess:
func (tc *TiDBContext) ShowProcess() util.ProcessInfo { return tc.session.ShowProcess() } 邏輯比較簡單，就是調用類型為session.session的ShowProcess方法，接着往下看：
func (s *session) ShowProcess() util.ProcessInfo { var pi util.ProcessInfo tmp := s.processInfo.Load() if tmp != nil { pi = tmp.(util.ProcessInfo) pi.Mem = s.GetSessionVars().StmtCtx.MemTracker.BytesConsumed() } return pi } session的ShowProcess方法會從內存中加載當前session的processInfo信息。至此我們分析show processlist命令的源碼分析完畢，關於每個連接如何設置自身的processinfo信息，邏輯也比較簡單，大家有興趣可以自己去研究一下。
總結
我們可以回答一下開頭提出的兩個問題：
- show processlist到底是不是單機的命令，和TiKV、PD有沒有啥關系？答案是show processlist確實是一個單機命令，和TiKV、PD沒有任何關系。
- kill tidb需要使用的id字段到底代表的是什么？id字段就是在創建連接時，分配的connectionId，它在單個TiDB服務內唯一。
通過上面的分析，我們還可以總結以下的特點：
- TiDB的連接在客戶端不能夠復用，因為它處理請求時，主流程是在單協程中處理的，處理完一個再處理下一個；
- show processlist命令的處理中關於ShowExec的Open方法調用，其實是它內部的baseExecutor的Open方法；
- 每個連接的session負責獨立管理此連接的processinfo信息；
- TiDB的Executor機制靠next的方式不斷在它的鏈式處理結構上傳遞；
- show processlist因為沒有其它條件，所以它在處理時的Executor類型為ShowExec，沒有再包裝SelectionExec類型；
- 真正的語句執行(獲取show processlist的信息)其實是在write的時候，我在分析這點的時候，花了不少時間；
源碼閱讀方法
最后，我想和大家分享一下，我自己在源碼閱讀里面用到的一些方法和技巧，大的方面會有兩種方法：
- 由因導果：就是由某一行代碼，開始自頂向下的正向閱讀；
- 執果索因：就是從結果處出發，開始自底向上的反向閱讀和推導；
上面的兩種方法，會伴隨大家在源碼閱讀的各個階段，但是有了這兩種方法還是遠遠不夠的，我再分享一下我的相關技巧：
- 編譯運行：當我們在下定決心要閱讀某個框架的源碼時，第一步要做的就是，將這個框架的源碼從源碼庫拉下來后，用我們的IDE工具編譯運行起來，對於有些框架運行的難度會比較高，就比如說我這次選擇的TiDB，在編譯過程中花費了好多的時間。建議大家在這個過程中，不要放棄，第一步是一定要把它編譯運行起來；
- 資料參考：一般來講只要不是太冷門的組件，一般網上都會有比較多的源碼分享，我們需要甄別出寫的好的源碼分析資料，然后參考驗證我們的源碼閱讀；
- 重要類的結構關系圖整理：我們都知道，java體系的組件（golang的也一樣），在設計時都會有各種復雜接口和抽象類繼承關系，在閱讀源碼時，我們很容易便陷入到這種復雜的繼承關系中去，所以利用IDE工具繪出類的結構關系圖，會在我們閱讀源碼時，有很大的幫助；
- 掌握調試技巧：有較好的調試技巧可以便於我們分析代碼流程和上下游關系；
- 修改源碼：在我們不能完全確定流程分支等情況下，可以靠修改源碼去理解；
- 提問題：在本文分析show processlist源碼的過程中，提問題一直都伴隨着我們的源碼閱讀過程，提問題能讓我們更好的理解背后的含義，便於深入到源碼的架構設計中去；
- 聚焦：對於類似於TiDB如此復雜的組件，我們在一開始分析的過程中，一定要先選定分析的主線路，比如：本章的“show processlist”，在這個過程中，有意的忽略我們本次分析主線路之外的邏輯分支，目標明確，才能不會陷入到框架各種復雜的設計中去；
- 總結分享：這一點是最重要的，源碼閱讀完后，如果不進行總結，過一段時間，我們便很容易遺忘了，同時分享也很重要，開源軟件本身就是一種眾包思想，我們既然是受益方，同時也要通過知識分享回饋他人；