用過mybatis的同學應該都知道mybatis generator(下文簡稱MBG)這個插件，他幫助我們生成用來操作數據庫的mybatis相關代碼，通常包括這三類代碼：java entity、mapper xml、mapper interface.關於mybatis和MBG的基本使用，這裏不多做介紹，本文主要介紹MBG生成mybatis代碼過程中遇到的兩個問題和解決方案。本文將以一張person表作爲例子，進行講解。
1.MBG每次運行時，生成的PersonMappper.xml追加導致項目無法啓動
在項目開發前期，我們經常遇到表結構設計不合理或者因需求變更，導致需要改動表字段的情況。那麼，當我們再次運行插件生成代碼時，新生成xml的內容，會默認追加到PersonMapper.xml文件中。這樣就會導致xml裏有兩個id一樣的sql,當我們啓動項目時，會看到如下的報錯：
網上也有多解決方案，多大是基於繼承PluginAdapter類做一些定製化的開發的方案，這種方案固然可以，但是對於開發人員的編碼能力和質量是很一定考驗的，並且比較耗時，佔用工作量並且有風險的事情我們不做。優雅的我，不喜歡使用這種具有破壞性的方式，堅信MBG官方一定有相應的配置來支持這種需求，功夫不負有心人，在MBG的github 1.3.7版本日誌裏找到了如下說明：https://github.com/mybatis/generator/pull/311。
所以我們只需要升級MBG版本到1.3.7,然後在MBG的配置中，增加如下一行就可以啦：
<plugin type="org.mybatis.generator.plugins.UnmergeableXmlMappersPlugin" />
2.手寫的sql被覆蓋問題
另外一種情況就是，MBG生成的sql語句都是一些基本的簡單數據操作，如：
- insert
- update by primary key
- update by example (using a dynamic where clause)
- delete by primary key
- delete by example (using a dynamic where clause)
- select by primary key
- select by example (using a dynamic where clause)
- count by example
當我們遇到複雜的業務需求或者想自定義sql的時候，MBG就無能爲力了。通常我們會自己在PersonMapper接口類中手動添加一個方法，然後在PersonMapper.xml文件中添加一個對應的sql。正常情況下，這樣做是沒有問題的，可是當我們再次遇到【問題1】中表結構變化時，不得不再次生成PersonMapper.xml。當再次生成之後，新生成的文件內容會覆蓋原有內容，那麼我們手動寫的sql就被覆蓋掉了。解決這個問題的方式：增加一個PersonExtendMapper.xml,裏邊的namespace和PersonMapper.xml保持一致，這樣，我們把需要自定義的sql寫到PersonExtendMapper.xml中就ok啦，這樣既不用擔心自定義方法被覆蓋，又可以隨時生成默認的一些sql。另外，建議大家少寫自定義sql,保持和數據庫的交互都是簡單sql，讓計算上移到應用層，畢竟在微服務時代，增加一個應用服務節點，比拓展數據庫成本要低很多，當然只是建議，主要還是看業務場景。
