优化介绍
平时sql优化都是建立索引，防止索引失效。当关联表多，数据量大的时候，所有的索引都没有失效的时候，依然查询很慢时，我们需要做别的优化。 索引不失效也会有查询慢的时候，经过百度查阅发现当索引查询量低于总数据量10%时候，索引才会提升查询效果，否则依然会走全表扫描。
业务描述
昨天在公司sql加一个条件，本来查询需要五分钟，结果习惯性的在后面加了一张表和一个关联条件，导致查询了67分钟。使用plsql的f5查询执行计划，发现所有索引都没有失效。于是查询那五张表数据量，A表50多万条，B表五万多条。C表100多万条，D表30多万条。本人新加进去的E表140多万条。下面代码演示本人两部分代码。
代码演示
原本sql代码结果
select A.* from A
left join B on a.id = b.id
left join C on c.id = a.coumterId
left join D on d.id = a.shopId
上面人家公司原本的代码，运行五分钟。 本人第一反应代码
select A.*, E.bookId from A
left join B on A.id = B.id
left join C on C.id = A.coumterId
left join D on D.id = A.shopId
left join E on E.id = A.resultId
结果导致了查询响应时间十几倍上升,运行时间是67分钟。性能优化不要考虑小编里面的*号，这只是演示代码。而且小编测试了一下，select *,在小编的这个业务里面没有影响性能，当把所有列名都列出来，还慢了10几秒。小编觉得应该是列名不多的原因吧。 优化后的代码
select em.*, E.bookId from (
select A.* from A
left join B on A.id = B.id
left join C on C.id = A.coumterId
left join D on D.id = A.shopId) em
left join E on E.id = em.resultId
这样优化后运行时间3分钟左右，运行了五次，最慢的是4分钟17秒，最快两分钟44秒。 理由是小表带动大表可以提升查询性能，既然人家写的查询性能快，而且它是筛选好的结果。那就以它的结果为表带动大表去查询。按一开始小编的写法，是所有表全表关联查询。数据量很大导致关联查询很慢。当以某一个环节作为媒介，它数据量就会减少很少。这时候小表驱动大表进行查询，性能就会提高。这也体现了java中并发里面的并行的思想分而治之。
其他
自己建立了一个技术群，大家愿意主动学习和分享，愿意一块实现一些有意思的技术，进行理论和实践的交流。这里面有前端和后段，不是单一的一种，方便大家沟通前后端兼容问题
