六、常见的MySQL业务问题处理

1、如何对数据进行分页显示

  • 日常工作中,除了写出相关需求的sql之外呢,还需要保证sql高效运行,如何知道执行效率?可以通过获取sql的执行计划。在sql语句前加 explain。

  • 执行计划能告诉我们什么?

    • sql是如何使用索引。

    • 联接查询的执行顺序。

    • 查询扫描的数据行数。

  • 执行计划中的内容详解


    • 执行结果如下:


    • 从sql中可以看出来,我们查询是以product_info表为基础查询的,但是mysql优化器不是按照我们写的顺序执行的,它的执行顺序是 b --->a ---> c。

    • 执行结果


  • 执行结果


2、优化评论分页查询


- 通过对该sql执行计划的分析,可以看到:possible_keys, key,key_len都为NULL ,表示在 product_comment表中是没有索引的。可以为其添加联合索引,根据建立索引的规范,我们需要首先计算这两列的数据在表中的区分度。如何计算区分度呢?

  • 区分度越接近1越好,创建索引的时候就应该放在左侧的位置,这里两个都是1。就不用替换原始sql语句 audit_status 和 product_id的位置了。

  • 创建索引

  • 执行结果:


可以看出来,添加索引之后,筛选的行数由两行变为一行。

  • 上边这种表数据量比较大,sql查询效率就很慢。那么怎么优化sql?

3、 如何删除重复数据

  • 需求:删除评论表中对同一商品的重复评论,只保留最早的一条。

  • 步骤一: 查看是否存在对于一订单同一商品的重复评论。


  • 步骤二: 备份product_comment表。


  • 步骤三: 删除同一订单的重复评论。


4、如何进行分区间的统计

  • 需求: 统计消费总金额大于 1000元,800 到1000元的,500到800元的,以及500元以下的人数。



    执行结果:


5、如何捕获有问题的SQL

  • 如何找到需要优化的SQL 。启动mysql慢查日志。

    • set global slow_query_log_file = /sql_log/slow_log.log;
    • set global log_queries_not_using_indexes = on;
    • set global long_query_time = 0.001; 抓取执行超过多少时间的sql( 秒).
    • set global low_query_log = on;
  • 慢查日志记录内容


  • 如何分析慢查日志


6、各个执行计划参数的意义

  • 1、id列数字越大越先执行,如果说数字一样大,那么就从上往下依次执行,id列为null的就表是这是一个结果集,不需要使用它来进行查询。

  • 2、select_type列常见的有:

    • simple:表示不需要union操作或者不包含子查询的简单select查询。有连接查询时,外层的查询为simple,且只有一个
    • primary:一个需要union操作或者含有子查询的select,位于最外层的单位查询的select_type即为primary。且只有一个
    • union:union连接的两个select查询,第一个查询是dervied派生表,除了第一个表外,第二个以后的表select_type都是union
    • dependent union:与union一样,出现在union 或union all语句中,但是这个查询要受到外部查询的影响
    • union result:包含union的结果集,在union和union all语句中,因为它不需要参与查询,所以id字段为null
    • subquery:除了from字句中包含的子查询外,其他地方出现的子查询都可能是subquery
    • dependent subquery:与dependent union类似,表示这个subquery的查询要受到外部表查询的影响
    • derived:from字句中出现的子查询,也叫做派生表,其他数据库中可能叫做内联视图或嵌套select
  • 3、table

    • 显示的查询表名,如果查询使用了别名,那么这里显示的是别名,如果不涉及对数据表的操作,那么这显示为null,如果显示为尖括号括起来的<derived N>就表示这个是临时表,后边的N就是执行计划中的id,表示结果来自于这个查询产生。如果是尖括号括起来的<union M,N>,与<derived N>类似,也是一个临时表,表示这个结果来自于union查询的id为M,N的结果集。
  • 4、type

    • 依次从好到差:system,const,eq_ref,ref,fulltext,ref_or_null,unique_subquery,index_subquery,range,index_merge,index,ALL,除了all之外,其他的type都可以使用到索引,除了index_merge之外,其他的type只可以用到一个索引
    • system:表中只有一行数据或者是空表,且只能用于myisam和memory表。如果是Innodb引擎表,type列在这个情况通常都是all或者index
    • const:使用唯一索引或者主键,返回记录一定是1行记录的等值where条件时,通常type是const。其他数据库也叫做唯一索引扫描
    • eq_ref:出现在要连接过个表的查询计划中,驱动表只返回一行数据,且这行数据是第二个表的主键或者唯一索引,且必须为not null,唯一索引和主键是多列时,只有所有的列都用作比较时才会出现eq_ref
    • ref:不像eq_ref那样要求连接顺序,也没有主键和唯一索引的要求,只要使用相等条件检索时就可能出现,常见与辅助索引的等值查找。或者多列主键、唯一索引中,使用第一个列之外的列作为等值查找也会出现,总之,返回数据不唯一的等值查找就可能出现。
    • fulltext:全文索引检索,要注意,全文索引的优先级很高,若全文索引和普通索引同时存在时,mysql不管代价,优先选择使用全文索引
    • ref_or_null:与ref方法类似,只是增加了null值的比较。实际用的不多。
    • unique_subquery:用于where中的in形式子查询,子查询返回不重复值唯一值
    • index_subquery:用于in形式子查询使用到了辅助索引或者in常数列表,子查询可能返回重复值,可以使用索引将子查询去重。
    • range:索引范围扫描,常见于使用>,<,is null,between ,in ,like等运算符的查询中。
    • index_merge:表示查询使用了两个以上的索引,最后取交集或者并集,常见and ,or的条件使用了不同的索引,官方排序这个在ref_or_null之后,但是实际上由于要读取所个索引,性能可能大部分时间都不如range
    • index:索引全表扫描,把索引从头到尾扫一遍,常见于使用索引列就可以处理不需要读取数据文件的查询、可以使用索引排序或者分组的查询。
    • all:这个就是全表扫描数据文件,然后再在server层进行过滤返回符合要求的记录。
  • 5、possible_keys

    • 查询可能使用到的索引都会在这里列出来
  • 6、key

    • 查询真正使用到的索引,select_type为index_merge时,这里可能出现两个以上的索引,其他的select_type这里只会出现一个。
  • 7、key_len

    • 用于处理查询的索引长度,如果是单列索引,那就整个索引长度算进去,如果是多列索引,那么查询不一定都能使用到所有的列,具体使用到了多少个列的索引,这里就会计算进去,没有使用到的列,这里不会计算进去。留意下这个列的值,算一下你的多列索引总长度就知道有没有使用到所有的列了。要注意,mysql的ICP特性使用到的索引不会计入其中。另外,key_len只计算where条件用到的索引长度,而排序和分组就算用到了索引,也不会计算到key_len中。
  • 8、ref

    • 如果是使用的常数等值查询,这里会显示const,如果是连接查询,被驱动表的执行计划这里会显示驱动表的关联字段,如果是条件使用了表达式或者函数,或者条件列发生了内部隐式转换,这里可能显示为func
  • 9、rows
    这里是执行计划中估算的扫描行数,不是精确值

  • 10、extra
    这个列可以显示的信息非常多,有几十种,常用的有

    • distinct:在select部分使用了distinc关键字

    • no tables used:不带from字句的查询或者From dual查询

    • 使用not in()形式子查询或not exists运算符的连接查询,这种叫做反连接。即,一般连接查询是先查询内表,再查询外表,反连接就是先查询外表,再查询内表。

    • using filesort:排序时无法使用到索引时,就会出现这个。常见于order by和group by语句中

    • using index:查询时不需要回表查询,直接通过索引就可以获取查询的数据。

    • using join buffer(block nested loop),using join buffer(batched key accss):5.6.x之后的版本优化关联查询的BNL,BKA特性。主要是减少内表的循环数量以及比较顺序地扫描查询。

    • using sort_union,using_union,using intersect,using sort_intersection:
      using intersect:表示使用and的各个索引的条件时,该信息表示是从处理结果获取交集
      using union:表示使用or连接各个使用索引的条件时,该信息表示从处理结果获取并集
      using sort_union和using sort_intersection:与前面两个对应的类似,只是他们是出现在用and和or查询信息量大时,先查询主键,然后进行排序合并后,才能读取记录并返回。

    • using temporary:表示使用了临时表存储中间结果。临时表可以是内存临时表和磁盘临时表,执行计划中看不出来,需要查看status变量,used_tmp_table,used_tmp_disk_table才能看出来。

    • using where:表示存储引擎返回的记录并不是所有的都满足查询条件,需要在server层进行过滤。查询条件中分为限制条件和检查条件,5.6之前,存储引擎只能根据限制条件扫描数据并返回,然后server层根据检查条件进行过滤再返回真正符合查询的数据。5.6.x之后支持ICP特性,可以把检查条件也下推到存储引擎层,不符合检查条件和限制条件的数据,直接不读取,这样就大大减少了存储引擎扫描的记录数量。extra列显示using index condition

    • firstmatch(tb_name):5.6.x开始引入的优化子查询的新特性之一,常见于where字句含有in()类型的子查询。如果内表的数据量比较大,就可能出现这个

    • loosescan(m..n):5.6.x之后引入的优化子查询的新特性之一,在in()类型的子查询中,子查询返回的可能有重复记录时,就可能出现这个

    • 除了这些之外,还有很多查询数据字典库,执行计划过程中就发现不可能存在结果的一些提示信息

  • 11、filtered

    • 使用explain extended时会出现这个列,5.7之后的版本默认就有这个字段,不需要使用explain extended了。这个字段表示存储引擎返回的数据在server层过滤后,剩下多少满足查询的记录数量的比例,注意是百分比,不是具体记录数。

微信扫码关注java技术栈,获取Java面试题和架构师相关题目和视频。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,117评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,328评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,839评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,007评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,384评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,629评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,880评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,593评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,313评论 1 243
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,575评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,066评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,392评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,052评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,082评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,844评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,662评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,575评论 2 270

推荐阅读更多精彩内容