背景
最近要上线一个新业务,因为涉及到存储数据,所以就需要建多一张mysql数据表,但是把建表语句提交上去之后,就被退回来了,大佬说的几句话确实值得深思
因为后续会有后台来查询这个数据表的数据,一开始我的想法是
1、哪些字段用于搜索查询的就加普通索引
2、连表查询中用于 on 的字段就加普通索引
修改建议
前提
其实我们很多数据表里都会有个关于状态的字段,这个字段可能出现的值其实并不多,一般都是 开 和 关两种状态,如果给这种字段加上普通索引,效果并不大,因为如果数据表里是1000条数据,这个索引只能帮你限定查询500条,查询量还是很大
修改建议
1、类似这种 可能出现的值是有限个的字段,最好和其他常用查询字段一起建立一个联合索引
2、因为联合索引是遵循最左原则,所以这个联合索引的字段排列有点讲究,最好是将想要用于查询的字段放前面,接下来是其他常用索引字段
3、这个索引的建立也要和业务使用相贴合,比如查询订单详情业务的,一般来说订单号,时间,订单状态,账号这些都是常用搜索项,是需要加索引的
而像订单状态这种,可以和上面说的常用搜索项相结合做一个联合索引
4、用于连表查的字段,以及在业务中经常用于单个查的字段,就直接加上普通索引,创建索引的时候也是建议先把这种单个字段的普通索引先给建好,再考虑联合索引
总结
对于 可能的值是有限个的字段,要善于和其他常用搜索项的字段相结合做联合索引
建表的索引以及表字段几乎是整个数据表最核心的东西了,而且对业务的影响也是相当深远的,虽然简单粗暴的将需要用于查询和连表的字段都加上索引也能提高搜索速度,不过给运维审核的大佬或者自己的大佬看到的话,未免会觉得你不够水平