Sql优化思路阶段性心得:
这段时间的优化做了好几个案例，其实有很多的类似点，都是好几张大表的相互连接，然后执行长达好几个小时，甚至都跑不出来。
自己差不多的思路就是Parallel full table scan + Hash join/nested loop配合hint来去调，这种方法差不多都能在10mins以内跑出来。毕竟说简单点，这种方法的核心就是拿物理资源去换取时间资源。所以调完后的很多大表也都是parallel full table scan.在执行计划里面也能看得到这样的consitent read或者物理读的指标都比较高。
还是有一些地方需要以后再去优化的时候思考的
- 能不能找到过滤性强的条件，从而leading几张表的连接顺序，先把小的结果集给找出来作为驱动表。多表关联时，表的查取顺序也有一定的关系。所以这一点自己以后还需要更耐心的去找一找，去思考！
- Sql语句里面的一些连接条件是必要的吗，说实话，看到sql那么一大串头都大了，根本不想理会那么多的逻辑，但是以后还是可以更细致的思考，可能第一次发现了，后续的基于sql的改写这些都能顺手。所以关注连接条件，和这些连接列上的索引情况对于大表的连接也非常的有帮助。
3.优化这种东西并不是说一定不能有全表扫描，一定要走索引这样的条条框框。至少目前很多的parallel table full scan也挺有效率的，所以自己应该理性的分析。
4.以后想到再补~~~~
未完待续~~~~~~~~~~~~~~~~~~~~~~~~