MySQL：索引设计

prtyaa 2023-12-28 15:48:12  49242

分类专栏：资讯

基数少的字段没必要加索引，例如姓名，没法二分查找。

设计一个字段的索引，假如这个字段的值就是0,1比如年龄，只有这么两个值，有十几万数据都是0,1 基数只有2，一个0，一个1.那么针对上面说的这种字段建立索引的话，那就还不如全表扫描了，因为索引树里就仅仅包含0和1两种值，根本没法进行快速的二分查找，也根本就没有太大的意义了，所以这种时候，选用这种基数很低的字段放索引里意义就不大了。

其次是针对数据类型小的字段建立索引，tinyint，varchar(255)的前几个字段建立索引。

比如说什么tinyint之类的，因为他的字段类型比较小，说明这个字段自己本身的值占用磁盘空间小，此时在搜索的时候性能也会比较好一点。不过当然了，这个所谓的字段类型小一点的列，也不是绝对的，很多时候就是要针对varchar(255)这种字段建立索引，哪怕多占用一些磁盘空间，那也得去设计这样的索引，比较关键的其实还是尽量别把基数太低的字段包含在索引里，因为意义不是太大。当然了，万一要是真的有那种varchar(255)的字段，可能里面的值太大了，觉得都放索引树里太占据磁盘空间了，此时仔细考虑了一下，发现完全可以换一种策略，也就是仅仅针对这个 varchar(255)字段的前20个字符建立索引，就是说，对这个字段里的每个值的前20个字符放在索引树里而已。但是这种取前几个字符设计索引的，没办法order by group by。因为此时name因为在索引树里仅仅包含了前20个字符，所以这个排序是没法用上索引了。

另外就是对于那种比较长的字符串类型的列，可以设计前缀索引，仅仅包含部分字符到索引树里去， where查询还是可以用的，但是order by和group by就用不上了。

索引不要设计的太多，因为insert的时候，需要动很多的B+树，性能不太好，会页分裂页合并之类的。因此一般设计索引别太多，建议两三个联合索引就应该覆盖掉整个表的全部查询了。否则索引太多必然导致增删改数据的时候性能很差，因为要更新多个索引树。

另外很关键一点，建议主键一定是自增的，别用UUID之类的，因为主键自增，起码聚簇索引不会频繁的分裂，主键值都是有序的，就会自然的新增一个页而已，但是如果用的是UUID，那么也会导致聚簇索引频繁的页分裂。因为主键自增的话，索引是有顺序的，b+树是有顺序的，索引之所以能提高查询速度就是因为，索引是有顺序的。

索引设计的一般原则：

一上来有表，肯定不知道按照什么进行查询，但是开发了mybatis，mapper都写了的话，就会知道根据什么进行查询了。这时就可以进行索引的设计了。

1、索引设计原则：

针对SQL语句里的where条件、order by条件以及 group by条件去设计索引。此时可以设计一个或者两三个联合索引，每一个联合索引都尽量去包含上where、order by、 group by里的字段，接着你就要仔细审查每个SQL语句，是不是每个where、order by、group by后面跟的字段顺序，都是某个联合索引的最左侧字段开始的部分字段？

比如有一个联合索引是INDEX(a,b,c)，此时一看发现有三个SQL，包含了where a=? and b=?， order by a,b，group by a这些部分，此时where、order by、group by后续跟的字段都是联合索引的最左侧开始的部分字段，这就可以了，说明这3个SQL语句都会用上索引了。

所以综上：设计的索引最好是让各个where、order by和group by后面跟的字段都是联合索引的最左侧开始的部分字段，这样他们都能用上索引。

2、尽量不要让查询语句里的字段搞什么函数，或者是搞个计算。

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=31725

赞同 0

评论 0 条

MySQL：索引设计

基数少的字段没必要加索引，例如姓名，没法二分查找。

其次是针对数据类型小的字段建立索引，tinyint，varchar(255)的前几个字段建立索引。

另外就是对于那种比较长的字符串类型的列，可以设计前缀索引，仅仅包含部分字符到索引树里去， where查询还是可以用的 ，但是order by和group by就用不上了。

索引设计的一般原则：

相关文章

关注我们

另外就是对于那种比较长的字符串类型的列，可以设计前缀索引，仅仅包含部分字符到索引树里去， where查询还是可以用的，但是order by和group by就用不上了。