隱式轉換導致索引失效.這一點應當引起重視.也是開發中經常會犯的錯誤. 由於表的字段tu_mdn定義為varchar2(20),但在查詢時把該字段作為number型別以where條件傳給mysql,這樣會導致索引失效. 錯誤的例子：select * from test where tu_mdn=13333333333; 正確的例子：select * from test where tu_mdn='13333333333';
看一下下面的案例，這個案例是開發過程中經常犯的乙個錯誤，這種索引在大表的查詢中是很致命的，直接能把資料庫拖死：
mysql> show create table shipping\g;
*************************** 1. row ***************************
table: shipping
create table: create table `shipping` (
`id` int(11) unsigned not null auto_increment,
`shipping_no` int(11) not null,
primary key (`id`),
unique key `shipping_no` (`shipping_no`)
) engine=innodb default charset=latin1
1 row in set (0.00 sec)
mysql> explain select shipping_no from `shipping` where `shipping_no` in (62487941,62653594,62952180,63556576,63684186,99097538006,100433005006,100433006006);
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | shipping | range | shipping_no | shipping_no | 4 | null | 6 | using where |
1 row in set (0.00 sec)
mysql> explain select shipping_no from `shipping` where (`shipping_no` in ('62487941','62653594','62952180','63556576','63684186','99097538006','100433005006','100433006006'));
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | shipping | all | shipping_no | null | null | null | 12803696 | using where |
1 row in set (0.00 sec)
很蛋疼的東西，希望開發者在開發的時候注意字段不要越界，最主要的是不要使用**轉換，有些是轉換不了的，dba的同行們注意這種**轉換帶來的危害，一定要給開發者提供規範。
MySQL中的隱式轉換造成的索引失效
在mysql查詢中，當查詢條件左右兩側型別不匹配的時候會發生隱式轉換，可能導致查詢無法使用索引。官方的隱試轉換說明 兩個引數至少有乙個是 null 時，比較的結果也是 null，例外是使用 對兩個 null 做比較時會返回 1，這兩種情況都不需要做型別轉換 兩個引數都是字串，會按照字串來比較，不做型...
mysql 隱式轉換 mysql中的隱式轉換
在mysql查詢中，當查詢條件左右兩側型別不匹配的時候會發生隱式轉換，可能導致查詢無法使用索引。下面分析兩種隱式轉換的情況 看表結構 phone為 int型別,name為 varchar 兩種情況都可以用到索引,這次等號右側是 2 注意帶單引號喲，左側的索引欄位是int型別，因此也會發生隱式轉換，但...
mysql隱式轉換
定義 當操作符與不同型別的運算元一起使用時，會發生型別轉換以使運算元相容。則會發生轉換隱式 舉乙個常見例子 1 我們先建立乙個表，有關手機號查詢 create table user id int 11 not null primary keyauto increment phone varchar ...