MySQL的id关联和索引使用的实际优化案例(mysql关联查询原理)

推荐整理分享MySQL的id关联和索引使用的实际优化案例(mysql关联查询原理)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:mysql关联关系,mysql关联语句,mysql关联查询原理,mysql关联语句,mysql关联查询使用什么关键字,mysql关联语句,mysql关联查询使用什么关键字,mysql关联关系,内容如对您有帮助，希望把文章链接给更多的朋友！

昨晚收到客服MM电话，一用户反馈数据库响应非常慢，手机收到load异常报警，登上主机后发现大量sql执行非常慢，有的执行时间超过了s优化点一：

表结构为：

执行计划：

分析该sql的执行计划，由于tran_id是表的主键，所以查询根据主键降序顺序扫描，这样就可以不用排序，然后在过滤条件price>2.的记录，看上去这个执行计划貌似非常好，如果查询扫描到了满足条件的条记录，就会停止扫描；但是这里有个问题，如果表中有大量的记录是不符合2.的，意味查询就需要扫描非常多的记录，才能找到符合条件的条：

可以看到表中有大量的记录不是2.的，所以这个时候不能在根据主键顺序扫描，在过滤记录；那么是否需要在price建立一个索引：

从上面price的数据分布可以看出，price的分布相对还是比较集中的，如果在price建立索引，mysql也有可能认为由于需要回表的记录过多，同时需要额外的排序，而不选择在price上的索引：

可以看到优化器虽然注意到了我们新加的索引，但是最终还是选择了primary来扫描；所以这个时候我们加上去的索引没有产生效果，数据库负载依然很高，如果强制走price上的索引，效果会这样：

可以看到如果强制走索引，时间已经明显下降了，但是还是有些慢，能不能在快一点？其实我们需要扫描的记录只有条，但查询在取得这条记录的时候需要扫描大量无效的记录

怎么降低这个数据：其实只要改写一下sql就可以，我们先从索引中得到满足条件的个id，在回表进行关联：

可以看到执行时间已经不在秒级别了，和客户电话沟通后，很愿意这样改写sql。

—这里看到是order by tran_id是要额外排序的，索引也可以这样来建立消除排序(tran_id,price)这样可以消除排序，同时可以利用order by desc/asc +limit M,N的优化。

优化点二：

查询为select `session_data`, `session_expires` from `game_session` where session_id='xxx'出现大量等待情况同时该表的insert，也有等待的现象；可以看到这个表结构设计是有些问题的，咨询了客户后，可以改为下面结构：

小结：

MySQL在关联复杂情况下所能做出的一些优化 昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；

对MySQL子查询的简单改写优化 使用过oracle或者其他关系数据库的DBA或者开发人员都有这样的经验，在子查询上都认为数据库已经做过优化，能够很好的选择驱动表执行，然后在把该

分析MySQL中优化distinct的技巧 有这样的一个需求：selectcount(distinctnick)fromuser_access_xx_xx;这条sql用于统计用户访问的uv，由于单表的数据量在G以上，即使在user_access_xx_xx上加上nick的索