Mybatis與SQL Server型別轉換遇到的坑
阿新 • • 發佈：2019-09-01
一. MyBatis SQL語句遇到的效能問題
1. 場景還原
假設我們有一張User表，其中包含userId、userName、gender欄位，其中userId的資料型別為char(20)，此時我們想通過userId獲得這個人的姓名，
這段SQL很簡單： SELECT userName FROM dbo.User (nolock) WHERE userId = '100'
2. 問題描述
上面這段簡單的SQL語句卻隱藏著很一個嚴重的效能問題：當MyBatis生成該語句，並在SQL Server執行時，引數userId的JDBC Type為nvarchar(4000)，但表中userId的資料型別為char(20)，因此必然存在著型別轉換。
在壓力測試場景、或呼叫頻繁的情況下，導致SQL Server CPU嚴重超標，以及服務吞吐量嚴重下降。
二. char、varchar、nvarchar區別
- char：對於英文字母佔1個位元組，對於漢字佔2個位元組，char屬於定長型別資料結構，剩餘空間全部使用空格填補，因此索引效率極高。
- varchar： 多餘空間不會使用空格填補，實際長度為字串長度+1，這個1代表字串的長度。
- nvarchar：所有的字元都佔用2個位元組，無論英文字母，還是漢字。解決了多字符集之間的轉換問題，N代表Unicode。
三. 參考
- https://www.cnblogs.com/lichang1987/archive/2009/03/04/1403166.html