在海量数据中创建高效SQL 笔记
参加了郑保卫博士的讲座，收获颇多。 以前总是写一些简单的sql，以为sql只是简单的命令，实际上sql大有可为，sql是体现技术人员能力的重要方面，sql是应用程序不是查询语言！以下简单总结了昨天培训的收获：
1. SQL语句是一种集合语言，而JAVA /c++甚至于PL/SQL是过程化语言，SQL语句按block处理数据，过程化语言按条处理，效率差距可想而知。
2. 扩张性的SQL语句可以做所有的有关数据处理的功能，不要再将SQL语句只当做一个数据库命令，“他是巨人，不是普通人”。
3. 索引非常重要，建立战略性的索引是很困难的，最好建立联合索引，除非是主键，最好不要建立单独索引。索引的建立不是越多越好，也不是越少越好，应该有一个平衡点。因为索引也需要耗费存储空间，在delete/update特别是insert的时候过于臃肿的索引会影响语句的执行效率。
4. 执行计划非常重要，要有执行计划和优化器的概念，对于一个SQL语句，要能够大概判断其执行的路径是什么。
5. 执行速度很大程度上和IO有关，因为CPU的计算速度已经很快了，但I/O是很大的瓶颈。所以正在研究的有“内存数据库”的概念。
6. 重视统计信息的作用，优化器是根据统计信息来进行执行计划的选择和优化的，统计信息可以定时让数据库收集、也可以在大量修改数据后手工执行统计信息的更新。
7. 新的优化器是基于成本的，不是基于规则的。
8. 调整数据库参数能解决10%的性能问题，修改执行计划可以解决30%，建立战略性索引和优化SQL语句可以解决50%的问题，而良好的数据模型和建模可以解决80%的性能问题。
9. 执行计划是非常敏感的，微小的改动可能都会改变执行计划，比如SQL语句中表连接的数据、更新的统计信息、索引的改变等。
10. 离散度的好坏决定索引效果的好坏，一般认为，如果某列数据的离散度低于10%-15%时，索引是有效的。
在SQL语句where查询条件中，有的条件用户驱动查询条件、有的用于过滤查询条件。最理想的方法是将拥有最小数据范围的条件作为查询驱动条件。
11. 组合索引中列的顺序有可能决定查询效率。
12. 索引的使用会受到表的联系方法和联系顺序的影响的。
13. PL/SQL中判断是否存在的替换方案：
原SQL： SELECT COUNT(*) INTO :CNT
FROM ITEM_TAB
WHERE DEPT = ‘101’
AND SEQ > 100;
…………………………………………
IF CNT > 0 ….
改进后：SELECT 1 INTO :CNT FROM DUAL
WHERE EXISTS (SELECT ‘X’
FROM ITEM_TAB
WHERE DEPT = ’101’
AND SEQ > 100 );
……………………………………………
IF CNT > 0 ….
14. 取最大流水号的替代方案
原SQL：SELECT MAX(seq) + 1
FROM order
WHERE deptno = ‘12300’
替代SQL：SELECT /*+ INDEX_DESC(order pk_order) */
NVL(MAX(seq), 0) + 1
FROM order
WHERE deptno = ‘12300’
AND ROWNUM = 1
15. 综合原理和总结
1） 数据处理就是集合运算；
2） 要从流程开发人员转变为数据开发人员，使用复杂的SQL，复杂的执行计划来替代过程化的程序执行，可以有效的降低计算次数，配合战略性索引，可以精简代码，提到性能。
3） SQL并非命令语句，而是应用程序!
