位置: 编程技术 - 正文
MySQL在关联复杂情况下所能做出的一些优化(mysql关联语句)
编辑：rootadmin推荐整理分享MySQL在关联复杂情况下所能做出的一些优化(mysql关联语句)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:mysql关联查询使用什么关键字,mysql关联语句,mysql关联关系,mysql数据库之间关联,mysql关联语句,mysql关联关系,mysql关联关系,mysql表关联有几种,内容如对您有帮助，希望把文章链接给更多的朋友！
昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：
第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；
第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在；
第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引；
第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想；
SQL:执行时间：
这条SQL查询实际只返回了一行数据，但却执行耗费了ms，查看执行计划：
可以看到执行计划中有两处比较显眼的性能瓶颈：
由于d是left join的表，所以驱动表不会选择d表，我们在来看看a,b,c三表的大小：
由于b表的数据量大于其他的两表，同时b表上基本没有查询过滤条件，所以驱动表选择B的可能排除；
优化器实际选择了a表作为驱动表，而为什么不是c表作为驱动表？我们来分析一下：
第一阶段：a表作为驱动表a?>b?>c?>d:(1):a.jg_id=b.jg_id—>(b索引:PRIMARY KEY (`JG_ID`,`YH_ID`) )
(2):b.yh_id=c.yh_id—>(c索引:PRIMARY KEY (`YH_ID`))
(3):c.yh_id=d.yh_id—>(d索引:PRIMARY KEY (`JS_DM`,`YH_ID`))由于d表上没有yh_id的索引，索引在d表上添加索引：
执行计划：
执行时间：
在d表上添加索引后，d表的扫描行数下降到行（最开始为： ）
第二阶段：c表作为驱动表
d^|c?>b?>a由于在c表上有yh_dm过滤性很高的筛选条件，所以我们在yh_dm上创建一个索引：
添加索引：
查看执行计划：
执行时间：
在c表上添加索引后，索引还是没有走上，执行计划还是以a表作为驱动表，所以我们这里来分析一下为什么还是以a表作为驱动表？
1):c.yh_id=b.yh_id—>( PRIMARY KEY (`JG_ID`,`YH_ID`) )
a.如果以c表为驱动表，则c表与b表在关联的时候，由于在b表没有yh_id字段的索引，由于b表的数据量很大，所以优化器认为这里如果以c表作为驱动表，则会与b表产生较大的关联（这里可以使用straight_join强制使用c表作为驱动表）；b.如果以a表为驱动表，则a表与b表在关联的时候，由于在b表上有jg_id字段的索引，所以优化器认为以a作为驱动表的代价是小于以c作为驱动板的代价；所以我们如果要以C表为驱动表，只需要在b上添加yh_id的索引：
2):b.jg_id=a.jg_id—>( PRIMARY KEY (`JG_ID`) )
3):c.yh_id=d.yh_id—>( KEY `ind_yh_id` (`YH_ID`) )执行计划：
执行时间：
可以看到执行计划中的rows已经大大降低，执行时间也由原来的ms降低到0 ms级别；
对MySQL子查询的简单改写优化 使用过oracle或者其他关系数据库的DBA或者开发人员都有这样的经验，在子查询上都认为数据库已经做过优化，能够很好的选择驱动表执行，然后在把该
分析MySQL中优化distinct的技巧 有这样的一个需求：selectcount(distinctnick)fromuser_access_xx_xx;这条sql用于统计用户访问的uv，由于单表的数据量在G以上，即使在user_access_xx_xx上加上nick的索
通过实例认识MySQL中前缀索引的用法 今天在测试环境中加一个索引时候发现一警告root@test::altertablearticledropindexind_article_url;QueryOK,rowsaffected(.sec)Records:Duplicates:0Warnings:0root@test
标签: mysql关联语句
本文链接地址:https://www.jiuchutong.com/biancheng/347327.html 转载请保留说明！
