3、索引优化
3.1 索引创建的原则 ?
● 必答内容：
好的，我们知道索引确实可以提高查询的效率，但前提是需要针对于数据库表创建合适的索引。创建索引的时候，主要考虑一下几点原则：
1). 针对于数据量较大，且查询比较繁琐的表创建索引。（单表超过10w记录）
2). 针对于经常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
3). 尽量选择为区分度高的列建立索引，如果该字段是唯一的，建立唯一索引，效率更高。（区分度越高，效率越高）。
4). 在varchar类型的字段上，建议指定索引长度（建立前缀索引），没必要对全字段建立索引，根据实际文本区分度决定索引长度就可以。
5). 尽量建立联合索引，而且在联合索引中将区分度高的字段放在前面，减少单列索引。（查询时，联合索引很多时候可以索引覆盖，避免回表，提高效率）
6). 在满足业务需求的前提下，建立适当的索引，索引不宜过多。（索引过多，会增加维护索引的成本，影响增删改的效率）
● 可能会继续发问的问题：
1). 索引的创建只是第一步，要想提高查询效率，还得正确的使用索引，避免索引失效，你知道索引失效的场景吗？ 【参照 3.2】
3.2 简单聊聊索引失效的场景 ?
● 必答内容：
好的，索引失效这个问题，确实是在项目开发中非常常见的一类问题。那我就结合我之前的项目经验来聊一下，之前遇到的一些索引失效的场景：
● 第一类呢，就是在联合索引使用的时候，违反最左前缀法则，比如查询的条件并不是从索引最左边的列开始的。
● 第二类呢，就是范围查询（非等值查询）右侧的列，不能使用索引。
● 第三类呢，就是在索引列上进行运算或函数操作，索引将失效。非常典型的，像我们基于substring这样的函数截取字段值。
● 以及如果在条件匹配时，需要进行隐式类型转换的时候。比如：where gender = 1，而gender是char类型，这种字符串不加引号，虽然查也能查出来，但也会造成索引失效。
● 还有像常见的，以 % 开头的like模糊匹配，索引也会失效。
当然这样的场景很多啊，上面这几个只是比较常见的索引失效的场景，所以在项目开发中，编写SQL时，就要避免这些情况的发生。
● 进阶内容：
而对于索引是否生效，到底走哪个索引，以及具体SQL语句的执行性能到底怎么样。 这个我们可以借助于 explain 来查看sql语句的执行计划 ，具体问题具体分析。
我们可以通过explain执行计划中的 key 来确定此次查询是否使用了索引，以及通过 type 来判定SQL的执行性能，一定要规避 type 为all全表扫描的情况，还有像 extra 的信息也需要关注一下。
● 可能继续发问的问题：
你刚才提到最左前缀法则，那什么是最左前缀法则？
最左前缀法则是针对于联合索引的，指的是 查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃某一列，索引将会部分失效(后面的字段索引失效)。
就比如，我按照 name，profession，age 这个顺序，针对于这三个字段，创建了联合索引。那么此时如何是根据 name 查询是会走联合索引的；根据 name, profession 也是会走索引的；根据 name，profession，age 也会走索引。但是如果根据 profession 或 profession，age 查询是不会走索引的，因为没有从最左边的字段 name 开始查询。
● 帮助理解的图示及说明：
4、SQL性能分析及优化
4.1 如何定位出项目中的慢SQL?
● 必答内容：
这个问题，在项目开发中，是非常常见的。 在我们之前的项目中，用到了链路追踪组件 SkyWalking，通过SkyWalking我们就能够知道，所有请求的调用链路及执行耗时，在显示的报表中，我们就可以看出哪一个接口比较慢，也可以看到这个接口执行过程中，每一个部分的具体耗时，包括SQL的执行具体时间也都可以看到，通过这个就可以定位慢SQL了。
那如果在一些项目中，没有用到这类的监控工具，也可以开启MySQL的慢查询日志，通过MySQL的慢查询日志来定位慢SQL。比如：我们可以在配置文件中配置一下，只要SQL语句的执行耗时超过1秒，我就需要将其记录在慢查询日志中，最终我们只需要通过这份慢查询日志，就能够知道哪些SQL的执行效率比较低。
● 可能继续问道的问题：
而具体执行耗时多长时间才算慢 ，时间一般设置为多长呢？
这个时间，其实没有一个定数，不同性质的项目之间也有差异，所以这个慢查询的界定时间，一般都要根据项目的情况来设置一个经验值，我们之前的项目中，设置的是1秒。
4.2 在项目中如何知道SQL语句的执行性能，以及索引是否生效？
● 必答内容：
这个我们可以借助于MySQL中提供的 explain 关键字，在查询的SQL语句之前，加上explain来查询SQL语句的执行计划。
当然explain查看到的执行计划信息比较多，我们主要关注几个核心指标就可以了。比如：
● 通过 key 、key_len 就能够知道是否命中索引。
● 通过 type 指标，就能知道该SQL的性能怎么样，有没有进一步优化的可能。一定要规避all全表扫描的情况。 type指标性能由好到坏，依次是：NULL > system > const > eq_ref > ref > range > index > all
● 还需要关注一个指标，就是extra额外的信息。 通过这一项，我们就能够知道，有没有回表查询，有没有涉及到file sort排序。
然后，我们就可以针对 explain 查看到的执行计划，针对于SQL进行优化了。
4.3 谈谈你在SQL优化方面的经验？
● 必答内容：
嗯，这个话题就比较大了。 那我们在项目中，优化SQL的查询执行效率，会从多个维度来考虑的。
● 第一个呢，就是表的设计。
○ 比如数据类型的选择，数值类型到底选择 tinyint、int还是bigint，要根据实际需要选择。字符串类型，到底选择char还是varchar，也需要根据具体业务确定。（char定长字符串，效率高；varchar变长字符串，效率略低）
○ 还需要考虑主键的设计，主键在设计时，尽量考虑递增顺序插入的主键，比如：自增主键 或 雪花算法生成的主键。（这样可以规避页分裂、页合并现象的产生）
● 第二个呢，就是索引的创建。
○ 针对于数据量较大，且查询比较繁琐的表创建索引。（单表超过10w记录）
○ 针对于经常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
○ 尽量选择为区分度高的列建立索引，如果该字段是唯一的，建立唯一索引，效率更高。（区分度越高，效率越高）。
○ 在varchar类型的字段上，建议指定索引长度（建立前缀索引），没必要对全字段建立索引，根据实际文本区分度决定索引长度就可以。
○ 尽量建立联合索引，而且在联合索引中将区分度高的字段放在前面，减少单列索引。（查询时，联合索引很多时候可以索引覆盖，避免回表，提高效率）
○ 在满足业务需求的前提下，建立适当的索引，索引不宜过多。（索引过多，会增加维护索引的成本，影响增删改的效率）
● 第三个呢，就是索引的使用。
○ 编写DQL时，在满足业务需要的情况下，要尽量避免索引失效的情况。 【索引失效的情况，见 3.2】
○ 尽量使用索引覆盖，避免回表查询，提高性能。
○ 那这些情况呢，都可以通过 explain 关键字来查看SQL语句的执行计划。
● 进阶回答：
○ 那如果从数据库层面来讲，也可以基于读写分离的模式，来降低单台服务库的访问压力，从而提高效率。
○ 当然，如果数据量过大，也可以考虑对目前项目中的数据库进行分库分表处理
