先介紹一下《MySQL資料庫開發的三十六條軍規》，這裡只介紹核心的，具體內容大家可以自行百度，這是從底層開發人員到管理者必須知道規範。出自58趕集。 介紹兩個例子。這個適合用STAR法則。STAR法則是情境(situation)、任務(task)、行動(action)、結論(result)四項的縮寫 ...
先介紹一下《MySQL資料庫開發的三十六條軍規》，這裡只介紹核心的，具體內容大家可以自行百度，這是從底層開發人員到管理者必須知道規範。出自58趕集。
寫在前面的話： 總是在災難發生後，才想起容災的主要性； 總是在吃過虧後，才記得有人提醒過。
核心軍規： 不在資料庫做計算，CPU計算務必移至業務層； 控制單表數據量，單表記錄控制在千萬級； 控制列數量，欄位數控制在20以內； 平衡範式與冗餘，為提高效率可以犧牲範式設計，冗餘數據； 拒絕3B(big)，大SQL、大數據、大批量
介紹兩個例子。這個適合用STAR法則。STAR法則是情境(situation)、任務(task)、行動(action)、結論(result)四項的縮寫。STAR法則是一種常常被面試官使用的工具。一般常說的開放性的問題，就是設立一個場景怎樣解決問題基本用的是這種工具。
案例1：
以下是我們組發生的一個真實例子，具體操作和調研是由我兩個同事實施的。
情境：
核心交易目前在進行代碼重構，數據模型的重構是其中重要的一個環節。一天我們同事在進行DDL(Data Defination Lauguage)的變更，由於兩個欄位比較相近，但是其中一個是原有欄位不可為空，另外一個是新增欄位，允許為空，結果空欄位被賦值給了非空欄位，DDL執行導致大量異常。DDL變更回滾後日誌恢復正常。
任務：
從java程式到連接mysql資料庫用到了atlas、mybatis、資料庫驅動到達mysql數據。而欄位的映射是mybatis這樣的ORM(Object Ralational Mapping)框架來處理的，我們的任務就是分析mybatis的源碼和配置，找到問題的根源和以後要註意的事項。
行動：
下載mybatis源碼進行調試、分析。當前生產環境中，Mybatis版本是3.2.8.
在使用mybatis時，有時可以不定義resultMap，直接在<select>語句上指定resultType。此時涉及到Mybatis的結果集自動映射。Mybatis的自動映射。Mybatis的自動映射預設開啟。分析源碼理解mybatis結果自動映射原理：
1. mybatis自動映射預處理流程：
2.自動映射流程(applyAutomaticMappings方法)
就是說applyAutomaticMappings要用到兩個配置參數：mapUnderscoreToCamelCase和callSettersOnNulls。
mapUnderscoreToCamelCase:是否開啟駝峰命名。開啟後會對大小寫、下劃線均不敏感。
callSettersOnNulls:是否在該欄位值為null時將結果同時反射set賦值方法進行賦值。
3. 自動駝峰命名規則測試實驗
| 實體屬性 | 欄位名 | 是否自動駝峰命名 | 是否可以賦值 |
|---|---|---|---|
| deviceId | device_id | true | 賦值給deviceId |
| deviceId | device_id | false | 沒有賦值給deviceId |
|
traceno traceNo |
traceno | true | 賦值給traceNo |
|
traceno traceNo |
trace_no | false | 都沒有進行賦值 |
|
traceno traceNo |
trace_no | true | 賦值給traceNo |
結論：
在映射時會先把沒有在resultMap中定義欄位映射的欄位按照名稱相同的方式自動映射到返回類型的對應屬性上。自動映射會忽略下劃線和大小寫。
Mybatis settings配置項說明應該仔細研讀。
欄位定義各個欄位之間的區分要儘可能的大，嚴禁使用只有大小寫和下劃線不同的兩個欄位。
我們現在在做分享會和讀書會，我的想法是這些學習活動要儘量貼近項目，做有深度的學習。代碼是隨便找個人培訓一下就可以寫的，但是寫出代碼的效率和可維護性等代碼質量的要求決定了大公司對初級程式員要求的門檻。而對所有技術研究的深度決定了突發問題的解決能力，對後續的建設提出的指導和建議。
案例2：
《逆流而上》里介紹的一個案例。
情境：
在某次項目發佈階段（資料庫使用了分庫分表），因為業務需要新增表欄位，從SQL的代碼邏輯來看，使用了select *，新增欄位應該是相容的，但在做線上資料庫DDL操作後，立即出現了日誌錯誤數飆升報警。當回滾還未執行，日誌錯誤就已經自動恢復。
任務：
從問題的現象來看，這個問題只有在變更過程中才出現，不太像是結果集映射問題，如果是映射問題，不執行回滾時無法自動恢復的。DBA反饋，可能是TDDL(Taobao Dustributed Data Layer分散式數據訪問引擎)層對Select * 的解析邏輯引起DDL變更的不相容。我們的任務就是確認問題發生的真正原因和對以後的指導意義。
行動（分析過程）：
1. TDDL在執行的時候，碰到select *,會從資料庫表中解決出對應的全部欄位：取第一個庫的第一個表進行解析，解析之後，會緩存結果。替換*，然後在吧解析後的SQL語句交到目標資料庫執行。
2. 在第一個庫變更後，TDDL拿到最新的欄位列表，後續一段時間內的查詢，都直接用帶有新增欄位的SQL語句提交到資料庫執行；由於有部分資料庫還沒執行變更，沒有新的欄位，導致資料庫執行出錯，無法查詢數據。
結論：
對於此問題是分庫分表中，持久層框架無對select *的相容邏輯導致。
但是使用select *的弊端不限於此，比如select * 查詢非必需欄位，會造成資源浪費甚至影響伺服器性能；增加SQL的解析成本；表結構變更可能會引起欄位映射問題；不會使用覆蓋索引，不利於查詢的性能優化等。
《阿裡巴巴編程規約》中對於ORM規範，有明確一條強制規約：在表查詢中，一律不要使用*作為查詢的欄位列表，需要哪些欄位必須明確寫明。
很多人問過我學習方法的問題，我覺得把這些基本規約和軍規仔細研讀，在平時的工作中多總結實踐，也可以算作一個初級或者中級程式員的亮點了。技術追求體現在解決不了的問題追究到底，瞭解不了的問題研究到底。項目中問題不是天天有，但是這些理論怎樣和實際結合確是天天要面對的問題。
跑題時間：
周末，男神在看電視，我照例在旁邊墊子上一邊做瑜伽一邊陪看電視。看的是一部很老的電影《葉問前傳》。看完之後我就跟男神分享心得：“你看葉問看起來正直厚道的一個人，做起事情來很講究方法。想搞定女友，人家先搞定女友他爹。最後女友捨身救葉問，也得到了他爹實際上的支持。”
女孩子和男孩子真的是來自兩個星球。我看一個片子通常會想很多。但是我說出來的必定和實際發生的事情有一定的聯繫。但是男孩子通常是看不出來的。比如我跟男神說的上面的心得。是因為前一天晚上我倆聊天，他說看到一個姑娘比我還要超凡脫俗。
我說你真要和她在一起，知道了她每月要買多少化妝品你就不這麼想了。女孩子多半人前人後不一樣。
男神說如果在外面見到我，可能沒有那麼喜歡我。我在外面看起來滑頭滑腦的。
我心想自己在外人看來基本上算是老年痴呆，但是職業習慣，見什麼人說什麼話。不然男神不愛吱聲，我又不說話，我倆在別人看來簡直一對怪胎。我也不點破，只對男神說：“你用詞不當，這個詞應該是‘古靈精怪’”。
後來他說想找個小尼姑當小老婆。看樣子他還是不太認同，覺得還是應該自己是一根木頭，外面看起來就應該是一根木頭，也不顧及別人跟你這根木頭打交道到底會不會尷尬。
所以我會有機會就旁敲側擊一下：做人要遵從本心，做事要靈活。
