数据库sql优化总结之1-金沙官网线上百万级数据库

案例分析2:

用between和in的区别

SELECT ex_question_junior.QUESTION_ID
FROM ex_question_junior
WHERE ex_question_junior.QUESTION_TYPE  IN(1,2,3,4)

执行时间为1.082s

SELECT ex_question_junior.QUESTION_ID
FROM ex_question_junior
WHERE ex_question_junior.QUESTION_TYPE between 1 and 4

执行时间为0.924s时间上是相差不多的

案例分析

金沙官网线上 1

项目背景

有三张百万级数据表

知识点表(ex_subject_point)9,316条数据

试题表(ex_question_junior)2,159,519条数据 有45个字段

知识点试题关系表(ex_question_r_knowledge)3,156,155条数据

测试数据库为:mysql (5.7)

 

优化方案

SELECT *
FROM ex_subject_point 
WHERE CREATE_DT >= "2018-05-31"
AND CREATE_DT < "2018-07-01"

 

但是EXPLAIN一下,发现这样还是全表扫描的

金沙官网线上 2

难道是因为日期字段索引没有效果吗?还是因为用了>=和<运算符号?

来验证一下

缩小查询范围,发现索引是有效果的。所以不是日期字段的问题。

金沙官网线上 3

换个字段查询,用>=和<运算符号,索引还是有效果的。但那是什么原因呢?

金沙官网线上 4

后来去网上查找了资料,原因是查询数量是超过表的一部分,mysql30%,oracle 20%(这个数据可能不准确,不是官方说明,仅供参考),导致索引失效。

案例分析:

SELECT ex_question_junior.QUESTION_ID
FROM ex_question_junior 
WHERE ex_question_junior.GRADE_ID=15

执行时间:17.609s (多次执行,在17s左右徘徊)

优化后:给GRADE_ID字段添加索引后

执行时间为:11.377s(多次执行,在11s左右徘徊)

备注:我们一般在什么字段上建索引?

这是一个非常复杂的话题,需要对业务及数据充分分析后再能得出结果。主键及外键通常都要有索引,其它需要建索引的字段应满足以下条件:

  a、字段出现在查询条件中,并且查询条件可以使用索引;

  b、语句执行频率高,一天会有几千次以上;

  c、通过字段条件可筛选的记录集很小,那数据筛选比例是多少才适合?

这个没有固定值,需要根据表数据量来评估,以下是经验公式,可用于快速评估:

小表(记录数小于10000行的表):筛选比例<10%;

大表:(筛选返回记录数)<(表总记录数*单条记录长度)/10000/16

单条记录长度≈字段平均内容长度之和+字段数*2

以下是一些字段是否需要建B-TREE索引的经验分类:

金沙官网线上 5

12.不要写一些没有意义的查询,如需要生成一个空表结构:(一般开发也不会这么无聊啦,在正式的项目上写这种玩意)

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:

create table #t(…)

参考:

https://mp.weixin.qq.com/s?__biz=MzIxMjg4NDU1NA==&mid=2247483684&idx=1&sn=f5abc60e696b2063e43cd9ccb40df101&chksm=97be0c01a0c98517029ff9aa280b398ab5c81fa1fcfe0e746222a3bfe75396d9eea1e249af38&mpshare=1&scene=1&srcid=0606XGHeBS4RBZloVv786wBY#rd

***************************************************************************

作者:小虚竹
欢迎任何形式的转载,但请务必注明出处。
限于本人水平,如果文章和代码有表述不当之处,还请不吝赐教。

 

案例分析

EXPLAIN

SELECT *

FROM ex_subject_point

WHERE ex_subject_point.path like "%/11/%"

金沙官网线上 6

若要提高效率,可以考虑全文检索。lucene了解一下。或者其他可以提供全文索引的nosql数据库,比如tt server或MongoDB

昨天晚上突发奇想,like 模糊全匹配,会导致全表扫描,那模糊后匹配和模糊前匹配也会是全表扫描吗?

今天开电脑,做了下测试。结果如下:

 

like模糊后匹配,不会导致全表扫描

金沙官网线上 7

 

like模糊前匹配,会导致全表扫描

金沙官网线上 8

MY SQL的原理就是这样的,LIKE模糊全匹配会导致索引失效,进行全表扫描;LIKE模糊前匹配也会导致索引失效,进行全表扫描;但是LIKE模糊后匹配,索引就会有效果。

 

还会陆续更新,还有几个小节。

参考:https://mp.weixin.qq.com/s?__biz=MzIxMjg4NDU1NA==&mid=2247483684&idx=1&sn=f5abc60e696b2063e43cd9ccb40df101&chksm=97be0c01a0c98517029ff9aa280b398ab5c81fa1fcfe0e746222a3bfe75396d9eea1e249af38&mpshare=1&scene=1&srcid=0606XGHeBS4RBZloVv786wBY#rd

***************************************************************************

作者:小虚竹
欢迎任何形式的转载,但请务必注明出处。
限于本人水平,如果文章和代码有表述不当之处,还请不吝赐教。

10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

例子请看第8点和第9点。

5.in 和 not in 也要慎用,否则会导致全表扫描

项目背景

有三张百万级数据表

知识点表(ex_subject_point)9,316条数据

试题表(ex_question_junior)2,159,519条数据 有45个字段

知识点试题关系表(ex_question_r_knowledge)3,156,155条数据

测试数据库为:mysql (5.7)

案例分析:

在mysql数据库中where 子句中使用 != 或 <> 操作符,引擎不会放弃使用索引。

EXPLAIN
SELECT ex_question_junior.QUESTION_ID
FROM ex_question_junior 
WHERE ex_question_junior.GRADE_ID !=15

金沙官网线上 9

执行时间是:17.579s

金沙官网线上 10

执行时间是:16.966s

9、应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。

2、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描

select id from t where num is null

最好不要给数据库留NULL,尽可能的使用 NOT NULL填充数据库.

备注、描述、评论之类的可以设置为 NULL,其他的,最好不要使用NULL。

不要以为 NULL 不需要空间,比如:char(100) 型,在字段建立时,空间就固定了, 不管是否插入值(NULL也包含在内),都是占用 100个字符的空间的,如果是varchar这样的变长字段, null 不占用空间。

可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:

select id from t where num = 0

案例分析

复合索引字段:PATH,PARENT_POINT_ID

金沙官网线上 11

调换WHERE子句中的条件顺序。发现还是可以使用索引的

金沙官网线上 12

复合索引只查询第一个字段,是有效果的

金沙官网线上 13

复合索引只查询第二个字段,发现索引没有效果了。

金沙官网线上 14

案例分析

注:在mysql数据库中where 子句中对索引字段使用 in 和 not in操作符,引擎不会放弃使用索引。

金沙官网线上 15

注:在mysql数据库中where 子句中对不是索引字段使用 in 和 not in操作符,会导致全表扫描。

金沙官网线上 16

案例分析

金沙官网线上 17

本文由金沙官网线上发布于数据库,转载请注明出处:数据库sql优化总结之1-金沙官网线上百万级数据库

您可能还会对下面的文章感兴趣: