。

MySQL有苦难言#xff1a;你不知道索引吗#xff1f;你写的SQL索引都失效了不知道吗#xff1f;慢查询不懂啊#xff1f;建那么多索…你写的每条SQL都是全表扫描吗如果是那MySQL可太感谢你了每一次SQL执行都是在给MySQL上压力、上对抗。

MySQL有苦难言你不知道索引吗你写的SQL索引都失效了不知道吗慢查询不懂啊建那么多索引干嘛呢。

。

。

文章目录

MySQL的慢查询日志可以记录执行时间超过阈值的SQL查询语句所以我们可以利用该日志查找出哪些SQL语句执行效率差从而对SQL语句进行优化。

SET

long_query_time2;开启完慢查询日志我们找到该日志的位置打开文件即可查询慢查询的SQL。

查询慢查询日志文件位置SHOW

%slow_query_log_file%;打开DESKTOP-ALU4BOC-slow.log文件找到慢查询SQL为select

D:\MySQL\bin\mysqld,

业务开发中涉及数据库的第一步是表设计要优化SQL就要从第一步开始做起。

第一范式数据库表中的每一列都是不可再分的属性属性相近或相同的列应该合并。

第二范式满足第一范式的条件下一个表只能描述一个对象。

如果某些列经常出现数据重复应该把这些列作为另一个表。

第三范式满足第二范式的条件下表中的每一列都只能依赖于主键即直接与主键相关。

我们在业务开发中遇到反第二范式的情况是最多的例如以下订单明细表的设计每一个订单明细都包含了重复的商品名称、商品单位、商品价格这三个字段属于字段冗余存储。

如果表的数据量级很大那造成的冗余存储量是可想而知的而且最要命的问题是如果要修改某一个商品名称那所有的订单明细数据都要修改。

我们可以遵循第三范式把冗余的字段抽出一个新的商品表当要查询订单明细时只需要把两表通过商品id进行连接即可。

面试官遵循第二范式就一定最优

遵循第二范式的表设计不一定是最优的情况还是那句话要根据实际的业务场景权衡利弊。

虽然把冗余数据抽离出去了但却增加了表的数量也意味着查询数据时表之间的join连接操作也会变多。

而join连接的性能是比较低的有可能join操作会成为数据库性能的瓶颈。

2.2

SQL优化除了做好表设计的优化工作还需要对SQL语句进行优化。

而SQL查询语句的优化主要从覆盖索引、避免索引失效、减少不必要的查询三个方面入手。

order

by排序的字段要尽量覆盖索引。

如果使用非索引字段进行排序MySQL会进行额外的文件排序将查询结果根据非索引列在磁盘中再排序一次。

当我们使用explain关键字分析SQL时会发现Extra会出现Using

group

by分组要尽量覆盖索引。

如果使用非索引字段进行分组MySQL只能进行全表扫描后建立临时表才能得出分组结果。

另外我们可以使用explain关键字来分析SQL语句的效率查看SQL语句是否覆盖索引。

关于如何避免索引失效大家可以阅读我出版的《JavaGetOffer》专栏关于【MySQL索引】的文章。

2.3

索引的设计有以下设计原则大家在实际业务开发中应该尽量遵循这些原则可以帮你避开不少坑。

经常进行order

尽量使用数据量小的字段建立索引。

例如对于char(500)和char(10)两个字段类型来说肯定是以后者进行索引匹配的速度更快。

如果需要建立索引的字段值比较长可以使用值的部分前缀来建立索引。

例如varchar类型的name字段我们需要根据前三个字符来建立前缀索引可以使用以下SQL命令ALTER

TABLE

另外大家记住一点索引不是建立越多越好。

合理设计的索引确实能大大提高SQL效率但每建立一个字段索引MySQL就要为该索引多维护一棵B-Tree越多的索引会造成表更新效率变得低下。

以【面试官面试】形式覆盖Java程序员所需掌握的Java核心知识、面试重点本博客收录在我开源的《Java学习指南》中会一直完善下去希望收到大家的

Star

https://github.com/hdgaadd/JavaGetOffer

创作不易不妨点赞、收藏、关注支持一下各位的支持就是我创作的最大动力❤️