先介紹一下《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規范，有明確一條強制規約：在表查詢中，一律不要使用*作為查詢的字段列表，需要哪些字段必須明確寫明。
很多人問過我學習方法的問題，我覺得把這些基本規約和軍規仔細研讀，在平時的工作中多總結實踐，也可以算作一個初級或者中級程序員的亮點了。技術追求體現在解決不了的問題追究到底，了解不了的問題研究到底。項目中問題不是天天有，但是這些理論怎樣和實際結合確是天天要面對的問題。
跑題時間：
周末，男神在看電視，我照例在旁邊墊子上一邊做瑜伽一邊陪看電視。看的是一部很老的電影《葉問前傳》。看完之后我就跟男神分享心得：“你看葉問看起來正直厚道的一個人，做起事情來很講究方法。想搞定女友，人家先搞定女友他爹。最后女友舍身救葉問，也得到了他爹實際上的支持。”
女孩子和男孩子真的是來自兩個星球。我看一個片子通常會想很多。但是我說出來的必定和實際發生的事情有一定的聯系。但是男孩子通常是看不出來的。比如我跟男神說的上面的心得。是因為前一天晚上我倆聊天，他說看到一個姑娘比我還要超凡脫俗。
我說你真要和她在一起，知道了她每月要買多少化妝品你就不這么想了。女孩子多半人前人后不一樣。
男神說如果在外面見到我，可能沒有那么喜歡我。我在外面看起來滑頭滑腦的。
我心想自己在外人看來基本上算是老年痴呆，但是職業習慣，見什么人說什么話。不然男神不愛吱聲，我又不說話，我倆在別人看來簡直一對怪胎。我也不點破，只對男神說：“你用詞不當，這個詞應該是‘古靈精怪’”。
后來他說想找個小尼姑當小老婆。看樣子他還是不太認同，覺得還是應該自己是一根木頭，外面看起來就應該是一根木頭，也不顧及別人跟你這根木頭打交道到底會不會尷尬。
所以我會有機會就旁敲側擊一下：做人要遵從本心，做事要靈活。