Question

mysql varchar索引和int索引性能哪个好

Answer 1

性能相当，mysql中区别性能的是采用哪种索引方式，而不是索引的数据类型。
MySQL的btree索引和hash索引的区别
hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像btree(B-Tree)索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 hash 索引的查询效率要远高于 btree(B-Tree) 索引。

虽然 hash 索引效率高，但是 hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。
（1）hash 索引仅仅能满足=，<=>，IN，IS NULL或者IS NOT NULL查询，不能使用范围查询。
由于 hash 索引比较的是进行 hash 运算之后的 hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 hash 算法处理之后的 hash 值的大小关系，并不能保证和hash运算前完全一样。

（2）hash 索引无法被用来避免数据的排序操作。
由于 hash 索引中存放的是经过 hash 计算之后的 hash 值，而且hash值的大小关系并不一定和 hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；

（3）hash 索引不能利用部分索引键查询。
对于组合索引，hash 索引在计算 hash 值的时候是组合索引键合并后再一起计算 hash 值，而不是单独计算 hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，hash 索引也无法被利用。

（4）hash 索引在任何时候都不能避免表扫描。
前面已经知道，hash 索引是将索引键通过 hash 运算之后，将 hash运算结果的 hash 值和所对应的行指针信息存放于一个 hash 表中，由于不同索引键存在相同 hash 值，所以即使取满足某个 hash 键值的数据的记录条数，也无法从 hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。

（5）hash 索引遇到大量hash值相等的情况后性能并不一定就会比B-Tree索引高。
对于选择性比较低的索引键，如果创建 hash 索引，那么将会存在大量记录指针信息存于同一个 hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下

Answer 2

索引的性能好坏，主要是由建立索引字段的数据的分散程度决定，与字段类型无关。如果是完全相同的数据内容，int理论上性能略好，但是实际差异不可能体现出来。

Answer 3

大部分开发会了解这样的《开发规范》：创建索引要选择区分度高的字段。他们会认为区分度低的字段不适合创建索引或者不适合添加到组合索引里面。但是这样的操作会导致很多慢查。举例来说：

select  * from  tab where a=1 and b=2;

场景 1 

符合 a=1的记录数有 10w 条记录 ，b=2 有 1000 条记录。如果只是创建idx_a(a)，sql 请求通过索引idx_a访问 10w 条件记录，然后还要逐一匹配 10w 条记录中的 status，找到符合 b=2的记录。这个动作会导致慢查。如果创建组合索引idx_ab(a,b)，sql 请求通过索引idx_ab可以直接定位到 1000 条记录，无需额外的过滤。这样减少访问 9900 条记录的时间，提升查询速度。

场景 2 

符合 a=1的有 100 条记录，status=2 有 10 条记录。其实场景 2 因为数据量比较少，直接访问 100 条记录和定位到 10 条记录的时间消耗相差不大，量变不足以引发质变，可以忽略了。

Tips：

• 创建索引的目的是通过索引尽可能找到匹配 where 条件的行，减少不必要的回表，提高查询效率；

• 需要辩证地看待区分度比较低的字段在组合索引中的作用。在组合索引的情况下，我们不能只是单纯地看字段的区分度，而是要看符合条件的记录数是多少。符合条件的记录越少，性能越好。