㈠ ibatis動態sql配置啟動時提示：The content of elements must consist of well-formed character data...
把下面這個表達式反過來寫就可以了。
如圖：
㈡ 真正的Mybatis動態sql —MyBatis Dynamic SQL
這個庫是一個用於生成動態SQL語句的框架。可以將它看作是一個類型安全的sQL模板庫，它提供了對MyBatis3和Spring JDBC模板的額外支持。該庫將生成供MyBatis或Spring使用的格式化的fuL LETE INET、SELECT和UPDATE語句。最常見的用例是生成可以直接由MyBatis使用的語句和一組數學參數。該庫還將生成與Spring JDBC模板兼容的語句和參數對象。該庫通過實現一個類似SQL的DSL來工作，該DSL創建一個對象，該對象包含完整的SQL語句和該語句所需的任何參數。
https://github.com/mybatis/mybatis-dynamic-sql
https://mybatis.org/mybatis-dynamic-sql/docs/introction.html
org.mybatis.dynamic.sql.SqlTable 表定義包括表的實際名稱(包括適當的模式)。如果需要，可以在選擇語句中應用表別名。你的Table應該繼承SqlTable 類。
org. mybatiss .dynamic.sql. sqlcolumn 用於定義在庫中使用的列。應該使用SqlTable中的構建器方法創建SqlColumns。列定義包括:
我們建議使用以下使用模式以提供最大的靈活性。這個模式允許您以「限定」或「非限定」的方式使用表和列名，這看起來像自然的SQL。例如，在下面的列中，一個列可以被稱為 firstName 或 user.firstName 。
該庫將創建用作 MyBatis mapper 輸入的類。這些類包括生成的SQL，以及與生成的SQL匹配的參數集。這兩者都是MyBatis所要求的。這些對象應該是 MyBatis mapper 方法的唯一參數。
（注意： MyBatis Dynamic SQL 不需要XML文件就能工作的很好，但並不意味著不支持XML，畢竟 **MyBatis **最初被設計為是一個 XML 驅動的框架。當你使用關聯查詢，需要復雜的映射，那麼使用XML 與 MyBatis Dynamic SQL 結合起來或者是更好選擇，你的XML或許只需要包含一些）
㈢ 安裝sqlserver2008需要net framework 3.5
1、首先，需要下載.net framework3.5的安裝包。直接網路搜索，選擇干凈的網站下載到本地電腦。
㈣ LINQ比一般的SQL語句效率更高嗎
Linq是一個范圍比較大的概念，它其中不單單只有linq to sql，還有相應的linq to xml等等。所以拿linq 與SQL語句相比，沒有可比性的。
但如果拿linq to sql相比的話，與SQL還是有很大的可比性的。一般情況下，你必須要明白你所指的效率是哪一方面？是資料庫執行效率？還是整體成品軟體運行效率？還是開發效率？
開發效率上linq to sql顯然要比SQL的效率要高很多，我們使用linq to sql 可以很容易實現編程，其中的代碼量也大大減少。所以如果從開發方面linq to sql的效率是毫無疑問要高於直接的SQL與資料庫連接。
如果從編方譯考慮，這個一般情況下，linq to sql是引入的新的技術，效率肯定是不如SQL的。好在這個編譯的部分不需要開發人員或是任何用戶的參與，所以即是效率差一點，對軟體來說沒有任何的影響。
最後一部分你可以比較感興趣，誰對資料庫的連接更快，執行效率更好？答案是linq to sql而不是直接的語句。一般我們使用直接的語句要求的是即是的執行，但事實上很多時間我們根本不需要那麼多，linq to sql其實說明了就是會自動生成與表結構同樣的一些對象。而這些對象在聯系資料庫時也是直接編譯好的語句，直接聯系時，兩者效率是相同的。
但是，如果我們對數據進行處理時，你就會發現，linq to sql的效率為什麼會更高了！因為他在讀取時不但會讀取當前表來填充生成的對象，同時還是延時讀其相關表，為你使用有關系的表提供了極大的方便。那麼你的相關表的讀取效率要快了！
但不管怎麼樣，他們都是在站立在了ado.net的基礎之上的，只不過有些自動生成了，根本不需要你再去做而已。唯一效果比較差的是，linq to sql讀出的數據在系統中被轉化了，同時它效率雖然變差一些，但是卻帶來了另一個好處，就是我們常說的SQL注入問題不再出現，你所輸入的任何東西都會變成了字元串了。
其實ADO.net的方案中我們使用了datareader方案的效高是比較高的，但是對於更新卻是極差的。而使用數據適配器的方案效率較底一些，更對於數據的更新是相當好的，而對於linq to sql其實它是使用數據緩存方案，也就是說linq to sql其實將資料庫中的數據緩存到了對象中，如果對象發生了更改，有必須過行返饋時，它是可以進行反饋的，而是這種反饋是可控制的，事務性的。從各方面給我們帶來了好處。
我們可以在更新了很多內容之後再去提交更改，那麼這種效率論從理解上還是效率上都優化你的原來的語句的！所以linq to sql並非在性能上的降低，而是一種提高。
嚴格說來，linq to sql並不是節省了代碼，相反它增加了很多代碼，便幸運的是，這些代碼都是由linq to sql框架自動生成的。若是換作人工，容易出錯的。但在使用時，由於框架完成了大部分的代碼，我們再使用linq to sql加上lambad表達式或查詢表達式，我們的代碼就變得極少且極簡潔了！而如果使用lambad表達式或查詢表達式時，它的效率顯然不如直接SQL來的直接。讀取效率會變得差一些的！
這是因為lambda表達式或查詢表達式是一個動態編譯的效果，而不是直接編譯好的，他要對語句進行編譯與優化以何證效率，但性能上因為多了一重處理，效率沒有SQL來的直接。但一般情況下，使用linq to sql配合查詢表達式或lambad表達式時，效率雖然稍差，但是帶來的卻是代碼的簡潔與易理解性，如果不配合查詢表達式與lambad表達式，linq to sql的優劣還不利用體現。所以關非linq to sql的效率差，而是我們使用了查詢表達式的動態編譯導致了效率較差。就linq to sql本身上來就，效率並不差的！
㈤ SpringBoot 中的 Mybatis 列印 執行過的SQL語句
在SpringBoot 中使用基於 Mybatis 框架，開發過程中，想看 Mybatis 生成的 sql語句 情況，做下配置即可。
非常簡單，如果使用的是application.yml文件，加入如下配置：
注意上面的 com.example.demo. 是個包名，指向你的mapper的包即可。