各大神请进，跪求困扰很久很深奥的关于索引是否使用到的有关问题
各大神请进，跪求困扰很久很深奥的关于索引是否使用到的问题
我有这样一张表person,id是INT主键(聚集索引)，然后是first_name和last_name，其中first_name我做了非聚集索引。
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
------解决方案--------------------
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
这里原因是系统认为聚集索引扫描速度快过非聚集索引查找，可能的具体原因有两个，1、数据量太小。2、first_name='1'的重复记录太多。
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
id的索引就是聚集索引，这没什么问题
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
一般来说，非聚集索引效率不如聚集索引，而且你这里聚集索引字段是int型，非聚集索引字段是字符串，效率差别更大，选择聚集索引是必然的
------解决方案--------------------
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
这里原因是系统认为聚集索引扫描速度快过非聚集索引查找，可能的具体原因有两个，1、数据量太小。2、first_name='1'的重复记录太多。
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
id的索引就是聚集索引，这没什么问题
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
一般来说，非聚集索引效率不如聚集索引，而且你这里聚集索引字段是int型，非聚集索引字段是字符串，效率差别更大，选择聚集索引是必然的
------解决方案--------------------
sql认为认为走聚集索引比走你建的非聚集索引效率要高，所以选择了聚集索引！
这种情况想最快，可以在first_name和last_name上建一个联合索引！
这样肯定走这个联合索引！
------解决方案--------------------
sql认为认为走聚集索引比走你建的非聚集索引效率要高，所以选择了聚集索引！
这种情况想最快，可以在first_name和last_name上建一个联合索引！
这样肯定走这个联合索引！
------解决方案--------------------
字段id和first_name上是分开建立的索引，
所以在使用AND进行两个条件查询时，
由于在分别建立的两个索引的叶节点上都不能直接确定所要查询的条件值是否满足。
而由于聚集索引的叶节点就是数据页。所以扫描聚集索引可以直接确定记录是否满足条件。
这解释了你的第一种情况
另外，where=聚集索引列 当然就进行聚集索引查找，这个最快
有一些情况是优化器直接优化的方案，
如果你的数据量很大的时候，它走的路线就又不一样了，你可以试一下
我有这样一张表person,id是INT主键(聚集索引)，然后是first_name和last_name，其中first_name我做了非聚集索引。
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
------解决方案--------------------
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
这里原因是系统认为聚集索引扫描速度快过非聚集索引查找，可能的具体原因有两个，1、数据量太小。2、first_name='1'的重复记录太多。
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
id的索引就是聚集索引，这没什么问题
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
一般来说，非聚集索引效率不如聚集索引，而且你这里聚集索引字段是int型，非聚集索引字段是字符串，效率差别更大，选择聚集索引是必然的
------解决方案--------------------
然后第一个查询SELECT 1 FROM person WHERE first_name='1' AND last_name='2'
执行计划显示聚集索引扫描，可是我first_name有索引啊，为什么不是先查first_name的索引，再在结果中查last_name='2'的行呢？
这里原因是系统认为聚集索引扫描速度快过非聚集索引查找，可能的具体原因有两个，1、数据量太小。2、first_name='1'的重复记录太多。
第二个查询SELECT 1 FROM person WHERE id=1 AND last_name='2'
执行计划显示聚集索引查找。可是那个last_name='2'上没有索引，为啥只有个聚集索引查找，难道不是先查id的索引，然后再其中扫描last_name='2'
id的索引就是聚集索引，这没什么问题
第三个SELECT 1 FROM person WHERE id=1 AND first_name='2'
执行计划显示还是聚集索引查找,可是那个first_name='2'上有索引,难道不是先查id的索引，然后再索引查找first_name='2'
一般来说，非聚集索引效率不如聚集索引，而且你这里聚集索引字段是int型，非聚集索引字段是字符串，效率差别更大，选择聚集索引是必然的
------解决方案--------------------
sql认为认为走聚集索引比走你建的非聚集索引效率要高，所以选择了聚集索引！
这种情况想最快，可以在first_name和last_name上建一个联合索引！
这样肯定走这个联合索引！
------解决方案--------------------
sql认为认为走聚集索引比走你建的非聚集索引效率要高，所以选择了聚集索引！
这种情况想最快，可以在first_name和last_name上建一个联合索引！
这样肯定走这个联合索引！
------解决方案--------------------
字段id和first_name上是分开建立的索引，
所以在使用AND进行两个条件查询时，
由于在分别建立的两个索引的叶节点上都不能直接确定所要查询的条件值是否满足。
而由于聚集索引的叶节点就是数据页。所以扫描聚集索引可以直接确定记录是否满足条件。
这解释了你的第一种情况
另外，where=聚集索引列 当然就进行聚集索引查找，这个最快
有一些情况是优化器直接优化的方案，
如果你的数据量很大的时候，它走的路线就又不一样了，你可以试一下