SQL SERVER 在数据库的里面一直是以“绵羊”的身份出现，不如 ORACLE 的尊贵，也不如POSTGRESQL 的 犀利， 更没有MYSQL 的人气。但很多人的第一个开蒙的数据库就是SQL SERVER。SQL SERVER 的使用的面积是很广的，但这么好脾气的数据库，你若 cross the line, 那就休怪他 给你“趴窝”。
我们来看看下面的一个例子然后在讲讲，是怎么得罪了这个“小绵羊”
首先这个表，的表结构我们就不去关心了，主要的就是id 是主键
那我们的上面那个图的查询计划是很正常的，走主键。
到底是为什么一个简简单单的主键查询会搞成全表扫描，问题的关键就是
Implicit conversion in SQL Server
（表没有什么特别，就是用char作为主键）
下面我们就好好说说，这个隐士转换的问题, 首先明确的一个问题，隐士转换存在两个地方
1 给定的值没有类型， 你要SQL SERVER 给你猜， 然后猜错了
2 给定了类型，但不对，不是你对应表的字段类型，属于 X唇不对X嘴的情况
这两种情况最后的结果，继续用上面的例子，就是好好的 = 变成了 > < 的操作
而反观正常的方式
当然问题已经说的很清楚了，解决也很简单，如果要在挖一下，SQL SERVER 的隐士转换也是有顺序的，下面就是顺序，1 用户定义，你的定义是第一位的，然后就开始以此类推的进行 “猜猜看” 的好戏了。
下面是一张表，这张表可以将类型（或者猜猜看），FROM TO 地来一个明确的表格化SHOW。
当然如果现在出现一个声音说，他们写的程序我怎么知道有没有隐士转换，或者一大堆的存储过程，我怎么知道隐士转换，那有没有方法揪出这些“害人精”。当然有办法，直接打开你的 extent event 的 plan_affecting_convert ，就能打开照妖镜，将他们一个个的抓出来。
另外有些爱“深究”的同学提出，为什么我在 SHOWPLAN_TEXT 的时候会发现一个
原因很简单，因为从NVARCHAR 要转变成 CHAR VARCHAR ，是有可能有损耗的，为了保证这样的转换的损耗不会影响到查询的准确性，则他会将转换后最小，和最大的损失范围，作为查询的对象，而不再是你的 = ， 所以如上图会变成两个量，然后 range 的查询，而你的表设计的主键又比较“nerd” 的情况下，就会让这个 RANGE 从你的表的主键的第一行，到最后一行 “滑落”。
