优化所需知识点(必须掌握)
索引篇
explain命令
重点:这是后续分析是否使用索引以及使用是否恰当的工具
作用:查看sql的执行计划,可以看sql语句是否使用了索引,索引的使用情况,以及sql的性能。
使用方法:explain+查询语句,例如:explain select * from test
字段解释(只讲需要用到的)
字段 | 含义 | |
id | 一条sql语句表的执行顺序(id相同从上到下顺序执行。id不同,值越大越先执行) | |
type | 表示连接类型,性能有好到差连接类型为 null,system,const,eq_ref,ref,range,index,all | |
possible_key | 可能应用在这张表上的索引(一个或多个) | |
key | 实际使用的索引,如果为null,则没有使用索引 | |
Extra | 字段 | 含义 |
Using index |
性能好,不需要回表查询 | |
Using where |
性能好,不需要回表查询 | |
Using index condition |
需要回表查询 | |
Using temporary |
在查询过程中使用了临时表 | |
Using filesort |
使用了额外的排序操作来满足 ORDER BY 子句 |
索引使用原则
重点:这决定了你创建哪些索引可以提升性能
- 针对数据量大并且查询比较频繁的表建立索引
- 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引。
- 尽量选择区分度高的列(例如身份证)作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高。
- 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引。
- 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间, 避免回表,提高查询效率
- 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价也就越大,会影响增删改的效率。
- 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它。
索引失效场景
重点:创建了索引但是失效了得不偿失
- 联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效(解决方案:使用>=、<=)
- 不要在索引列上进行运算操作, 索引将失效
- 字符串类型字段使用时,不加引号,索引将失效
- 如果仅仅是尾部模糊匹配,索引不会失效。如果是头部模糊匹配,索引失效。
- 用or分割开的条件, 如果or前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会 被用到。
优化实战
代码展示
SELECT
DISTINCT
u.id AS id,
uicm.code,
mbi.trueName AS name,
FLOOR(DATEDIFF(CURDATE(), mbi.birthday) / 365.25) AS age,
mbi.education,
mbi.height,
CASE
WHEN mbi.marriage IN (2, 11, 12, 13) THEN '离异'
WHEN mbi.marriage = 3 THEN '丧偶'
ELSE ''
END AS marriage,
mbi.hometownCode,
mbi.workCity,
mbi.occupation,
u.sex,
u.gmt_create AS time,
C