这是我参与 8 月更文挑战的第 11天，活动详情查看： 8月更文挑战
今天说说mysql的单表查询优化，我们循序渐进，先说这个，我们都知道mysql的查询优化器，我们的语句经过解析后会提交给查询优化器来进行优化，最终会生成一个执行流程（执行计划），我们常说的优化此时就已经做完了，在sql中我们可以通过explain来查看执行计划，里面的属性可以参考之前的文章MySQL调优？里面详细罗列了；
里面的一些逻辑上面的文章已经说过了，这里只是再深入细致一下，我们通常会给表添加主键，如果没加，mysql会隐式为我们创建一个主键列，为了业务的需要，我们可能会为某个字段添加唯一性约束，比如我们存储身份信息，会有一个主键ID（可能是UUID或者雪花的ID），但我们希望插入进来的数据**（身份证）保持唯一性，就可以设置unique index**；在查询时我们可以为身份证设置二级索引，或者区域+岁数构成一个联合二级索引，
为什么我要设置这样的索引呢，单表查询sql过于简单，我这里就不占篇幅了，如果我们用Memory存储引擎，因为它默认是hash索引，所有在我们查询的时候会进行全表遍历找到匹配的数据，个人认为Memory存储引擎在某些场景下最大的问题就是不支持范围查询，因为hash的快是我们代码里公认的，下面我们说说innodb在我上面的设计中的运用，如果我们单按ID查，很好，查出来的就是我们要的，但某些场景会不支持查ID的，此时为了效率，二级索引登场，比如身份信息，我们可以根据身份证号来进行查询，这样也是通过索引，效率很快，但是由于B+树的特性，我们需要回表，这部分无法避免，但由于依然走索引，所以问题不大，可是如果我们只是查有无此人，并不需要回表，那也是非常棒的，当然这得看产品大姐的意思；
如果我们想查询某个地区的某个年龄的人，或者某个年龄段的人，依然可以通过聚合索引的方式来快速实现我们的需求，当然涉及到聚合索引的话，我们的开发人员得了解表结构，别乱了顺序，或者盲目的修改查询条件的顺序或范围，这样会导致好好的sql索引干等着，而需求却要全表查询，会被打的；
总之，唯一性索引我觉得必不可少，某些表是应该加上的，二级索引可以方便我们的查询效率，也应该适当加点，但不可过多，正所谓欲速则不达嘛；二级索引过多在我们进行数据调整过后，mysql后台要维护的索引结构会耗费大量资源和时间，间接会影响执行效率，所以还有个注意点就是索引的字段尽量不要调整，频繁调整的不要做索引字段，岂不美哉，
规范开发，领导会夸你是个精神小伙；
最后赋上我之前的图片（如果你没点我上面的链接的话），这是我之前画的，这是记录数据到磁盘的一个过程，觉得还是很有必要来回看看的；
