mysql之字符串字段添加索引

字符串创建索引方式：

1、直接创建完整索引，比较占用空间。

2、创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引。

3、倒序存储，在创建前缀索引，用于绕过字符串本身前缀的却分度不够的问题。

4、创建hash字段索引，查询性能稳定，有额外的存储和计算消耗。

倒序存储和hash字段索引都不支持范围查询。倒序存储的字段上创建的所有是按照倒序字符串的方式排序的。hash字段的方式也只能支持等值查询。

mysql>alter table SUser add index index1(email):包含了每个记录的整个字符串

或

mysql>alter table SUser add index index2(email(6)):-对于每个记录只取前6个字节

全字段索引 *** 作流程

使用的是 index1（即 email 整个字符串的索引结构），执行顺序是这样的：

1、从 index1 索引树找到满足索引值是’ zhangssxyz@xxx.com ’的这条记录，取得 ID2 的值；

2、到主键上查到主键值是 ID2 的行，判断 email 的值是正确的，将这行记录加入结果集；

3、取 index1 索引树上刚刚查到的位置的下一条记录，发现已经不满足 email=' zhangssxyz@xxx.com ’的条件了，循环结束。

前缀字段索引 *** 作流程

如果使用的是 index2（即 email(6) 索引结构），执行顺序是这样的：

1、从 index2 索引树找到满足索引值是’zhangs’的记录，找到的第一个是 ID1；

2、到主键上查到主键值是 ID1 的行，判断出 email 的值不是’ zhangssxyz@xxx.com ’，这行记录丢弃；

3、取 index2 上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出 ID2，再到 ID 索引上取整行然后判断，这次值对了，将这行记录加入结果集；

4、重复上一步，直到在 idxe2 上取到的值不是’zhangs’时，循环结束。

倒序查询和hash字段的区别

它们的区别，主要体现在以下三个方面：

1、从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。

2、在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。

3、从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。

https://blog.csdn.net/weixin_43935927/article/details/109491334

建立索引，要使用离散度（选择度）更高的字段。

我们先来看一个重要的属性列的 离散度，

count(distinct(column_name)) : count(*) -- 列的全部不同值个数：所有数据行行数

数据行数相同的情况下，分子越大，列的离散度就越高。简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。

当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。

创建一张商户表，因为地址字段比较长，在地址字段上建立前缀索引

create table shop(address varchar(120) not null)

alter table shop add key(address(12))  // 截取12个字符作为前缀索引是最优的吗？

问题是，截取多少呢？截取得多了，达不到节省索引存储空间的目的，截取得少了，重复内容太多，字段的散列度（选择性）会降低。怎么计算不同的长度的选择性呢？

先看一下字段在全部数据中的选择度计算公式：

select count(distinct address) / count(*) from shop

select count(distinct left(address, n)) / count(*) as subn from shop

count(distinct left(address,n)) / count(*) 的结果是会随着 n 的变大而变大。举个例子，现在有两个address（东大街长兴小区，东大街福乐小区），那么 distinct(address，2) <distinct(address，3）

==>所以，截取的长度越长就会越接近字段在全部数据中的选择度

==>所以，我们要权衡索引大小和查询速度。

举个例子，通过不同长度去计算，与全表的选择性对比：

    SELECT  COUNT(DISTINCT(address))/COUNT(*) sub,            -- 字段在全部数据中的选择度

    COUNT(DISTINCT(LEFT(address,5)))/COUNT(*) sub5,  -- 截取前5个字符的选择度

    COUNT(DISTINCT(LEFT(address,7)))/COUNT(*) sub7, 

    COUNT(DISTINCT(LEFT(address,9)))/COUNT(*) sub9,

    COUNT(DISTINCT(LEFT(address,10)))/COUNT(*) sub10,  -- 截取前10个字符的选择度

    COUNT(DISTINCT(LEFT(address,11)))/COUNT(*) sub11,

    COUNT(DISTINCT(LEFT(address,12)))/COUNT(*) sub12,

    COUNT(DISTINCT(LEFT(address,13)))/COUNT(*) sub13,

    COUNT(DISTINCT(LEFT(address,15)))/COUNT(*) sub15

FROM shop

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| sub    | sub5  | sub7  | sub9  | sub10  | sub11  | sub12  | sub13  | sub15  |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| 0.9993 | 0.0225 | 0.4663 | 0.8618 | 0.9734 | 0.9914 | 0.9943 | 0.9943 | 0.9958 |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

可以看到在截取 11 个字段时 sub11(0.9993) 就已经很接近字段在全部数据中的选择度 sub(0.9958)了，而且长度也相较后面更短一些， 综合考虑比较合适。

ALTER TABLE shop ADD KEY (address(11))

1.索引的个数不要过多（浪费空间，更新变慢）

2.在用于 where 判断 order 排序和 join 的（on）字段上创建索引

3.区分度低的字段，例如性别，不要建索引（离散度太低，导致扫描行数过多）

4.更新频繁的值，不要作为主键或者索引（页分裂）

5.不建议用无序的值作为索引，例如身份z、UUID（在索引比较时需要转为ASCII，并且插入时可能造成页分裂）

6.若在多个字段都要创建索引的情况下，联合索引优于单值索引

7.联合索引把散列性高（区分度高）的值放在前面

默认是这里C:\Program Files\MySQL\MySQL Server 5.5\datamysql的数据库文件不像sqlserver，数据库后缀什么样，自己去看 （数据文件：. myd 索引文件：. MYI 表定义文件：. frm）

---