mysql數據庫查找類型不匹配

　　無心中看到10級學長的博客，提到了mysql數據庫類型查找不匹配的問題，博客地址是：盧俊達 。

數據庫中建表中會對每一個屬性進行類型劃分，而後在查找數據庫select時：

MySQL 的文檔 (Type Conversion in Expression Evaluation) 中提到，在作比較時，會按這樣的規則進行必要的類型轉換：

兩個參數至少有一個是 NULL 時，比較的結果也是 NULL，例外是使用 <=> 對兩個 NULL 作比較時會返回 1，這兩種狀況都不須要作類型轉換 兩個參數都是字符串，會按照字符串來比較，不作類型轉換 兩個參數都是整數，按照整數來比較，不作類型轉換 十六進制的值和非數字作比較時，會被當作二進制串，和數字作比較時會按下面的規則處理 有一個參數是 TIMESTAMP 或 DATETIME，而且另一個參數是常量，常量會被轉換爲 timestamp 有一個參數是 decimal 類型，若是另一個參數是 decimal 或者整數，會將整數轉換爲 decimal 後進行比較，若是另一個參數是浮點數，則會把 decimal轉換爲浮點數進行比較 全部其餘狀況下，兩個參數都會被轉換爲浮點數再進行比較

在博客：Xupeng's blog 中有提到，例如在表中存有name的屬性，而且屬性的類型是varchar，在進行數據庫查找時，若是查找name = '11111111',則MySQL會將查詢參數轉換爲肯定的數值30，以後快速的再表中查找與之隊形的數值。若是查找name = 1111111,則要查找的參數會被轉化爲浮點型，而且name字段的值也會被轉換成浮點型，答案是在轉換過程當中，name屬性的不少值，會轉換成相等的數值，好比 '111222', '111222aabb', ' 111222' 和 '11122.2e1'.因此MySQL不能有效的使用索引，就退化爲索引掃描甚至是全表掃描。因此會引發時間上和CPU利用率上的差別。