• mysql inner join连接查询性能优化
  • 建民 发表于 2017/2/24 11:07:00 | 分类标签: mysql优化 查询优化 join优化
  •  有天发现一个带inner join的sql 执行速度虽然不是很慢(0.1-0.2),但是没有达到理想速度。两个表关联,且关联的字段都是主键,查询的字段是唯一索引。

    sql如下: 

    SELECT
    p_item_token.*,
    p_item.product_type
    FROM
    p_item_token
    INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
    WHERE
    p_item_token.token ='db87a780427d4d02ba2bd49fac8xxx';

    其中表  p_item_token  中  itemid 是主键, token 是唯一索引。 p_item 中itemid 是主键

    按照理想速度,应该在0.03s左右正常。但实际为0.2左右,慢了不少。

    直接 EXPLAIN 看计划

    1 EXPLAIN
    2 SELECT
    3     p_item_token.*,
    4     p_item.product_type
    5 FROM
    6     p_item_token
    7 INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
    8 WHERE
    9     p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';

    结果:

    注意看上面大红框。p_item表中就是2w条数据,那这个就是全表扫描了。

    不正常啊。

    加个show warning 看看。

     1 EXPLAIN
     2 SELECT
     3     p_item_token.*,
     4     p_item.product_type
     5 FROM
     6     p_item_token
     7 INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
     8 WHERE
     9     p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';
    10 
    11 SHOW WARNINGS;

    结果2里面显示code=1003.后面有个sql语句。这个语句就是mysql把我们输入的sql语句,按照规则改写之后执行的最终语句。

     1 /* select#1 */
     2 SELECT
     3     '0000eb612d78407a91a9b3854ffffffff' AS `itemid`,        /*注:直接按主键把值查出来了*/
     4     'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,        
     5     '2016-12-16 10:46:53' AS `create_time`,                
     6     '' AS `ftoken`,                                        
     7     `p_db`.`p_item`.`product_type` AS `product_type`    
     8 FROM
     9     `p_db`.`p_item_token`
    10 JOIN `p_db`.`p_item`
    11 WHERE
    12     (
    13         (
    14             CONVERT (
    15                 `p_db`.`p_item`.`itemid` USING utf8mb4
    16             ) = '0000eb612d78407a91a9b3854fffffff'
    17         )
    18     )

    奇怪啊。Where中怎么有个 CONVERT  ?我们知道,如果where条件中,等式的左边,也就是要查询的字段上有函数的话,就会导致慢。(我的理解:慢因为索引用不到了。索引的值是原始值,这个条件中用的却是处理后的值。)

    注意看这函数,意思是把 itemid 这一列的编码转换成 utf8mb4 .也就是说,这一列的编码不是 utf8mb4 !

    打开表,把两个表中itemid这一列的编码都改成utf8。再次运行解释。

    从解释结果来看已经没有问题了。

    再看下结果2中的语句:

     1 /* select#1 */
     2 SELECT
     3     '0000eb612d78407a91a9b3854fffffff' AS `itemid`,
     4     'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,
     5     '2016-12-16 10:46:53' AS `create_time`,
     6     '' AS `ftoken`,
     7     'cxx' AS `product_type`
     8 FROM
     9     `toy_item_plat`.`p_item_token`
    10 JOIN `toy_item_plat`.`p_item`
    11 WHERE
    12     1

    这 select 中全是常量了。速度能不快吗?

    执行结果0.036s。符合预期

    经验总结:

    explain 可以查看执行计划是否符合预期,如果有出现rows较大的情况,则说明出现了全表扫描,将来会是性能瓶颈

    show warning的结果,则能看到优化器处理后的语句。如果与原始语句有出入,仔细对比研究能够发现实际问题。

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:建民
  • 加入时间:2013/7/12 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮