采用Batch操作虽然不会大量减少数据库服务器的物理I/O，但是会大幅减少客户端与服务端的交互次数，从而降低多次发起的网络延时开销，以及数据库的CPU开销。
　　In List
　　进行数据扫描时，有时会遇到这样的情况：到手多个ID，需要查询与这些ID相关的记录。有两种方式实现：单条提交或者批量提交。
　　单条处理是采用一个ID发一个请求的方式传送给数据库：
　　for: var in ids[] do begin
　　SELECT * FROM table_name WHERE id=:var;
　　end;
　　这种方法会增加与服务器的交互次数，显然和减少交互次数的思想背道而驰，固然是不推荐的。建议用ID InList的方式批量提交，可以把多次交互压缩在一次访问中完成，加速查询：
　　SELECT * FROM table_name
　　WHERE id IN ids[];
　　使用存储过程
　　Inceptor支持存储过程，合理的利用存储过程有助于提高系统性能。存储过程是由SQL语句组成的完成特定功能的代码块。每个代码块在创建时都需要命名，用户通过访问对应名称调用它们。存储过程中的代码都是已经编译过的，所以调用的时候可以跳过编译阶段直接执行，而且由于其直接存储在数据库中，可以避免SQL语句的重复传输。
　　总体而言使用存储过程有以下两方面的好处：
　　减少编译次数提高了执行效率。
　　在网络交互中代替了大量的SQL语句，使用者只需传递一些必要参数，帮助减少网络通信量，提升通信效率。
　　4. 减少数据库服务器
　　CPU运算SQL中会包含各种各样的操作和计算要求CPU参与运算，其中有一些计算并非必须，可以人为避免。例如，进行对比运算时，对于不匹配的类型，系统要对操作数进行类型转换，导致加重CPU负担。所以，对于数字和日期类型，建议用户在执行计算前先进行类型转换，使各操作数的类型匹配，或者建表时尽可能的把字段规划成相同的数据类型。
　　另外，对于SQL中的逻辑运算符，Inceptor通常对普通比较运算符(如等于、不等)有较好的表现，但是对于服务器CPU需求量很高的操作，需要用户保持警惕。如LIKE操作，该模糊查询对CPU的要求一般较高，特别是检查的记录有上万条及以上时，系统表现比较糟糕。建议用户根据业务语义尽量用In-List实现LIKE，在In-List中包含LIKE所有可能的匹配选项。
　　【例3】如下所示模糊查询语句：
　　SELECT * FROM table_name
　　WHERE column_name LIKE ‘%abc%’;
　　若已知该列字段值仅有三种取值‘cabc’、‘abce’、‘cabe’，上面的语句可以等价为这样的表达方式：
　　SELECT * FROM table_name
　　WHERE column_name IN (‘cabc’， ‘abce’， ‘cabe’);
　　【例4】如果In-List数据可用一条SELECT语句查询得到，好让一张中间小表作为In列表内部数据，然后采用内外查询关联的方式进行检索：
　　SELECT * FROM table_name
　　WHERE column_name IN (
　　SELECT col_name FROM tbl WHERE gender = ‘f’
　　);
　　总结本文分享了四种在Hadoop平台中常用的SQL优化思路，实际上每种思路在具体应用时都可以引申出很多不同的方法，介绍这些思路的目的在于为用户在选择SQL优化手段时提供一些明确方向。
　　后大致总结一下这些优化思路的适用场合：
　　1、在过滤扫描阶段考虑如何减少数据访问;
　　2、构造SELECT子句时应思考应该如何减少返回数据;
　　3、当执行涉及向服务器发起交互请求的操作时，应当选择减少交互次数的合适方法;
　　4、必要时进行人工处理以减少不必要的CPU计算。
　　5、如果用户能够考虑并兼顾这四个方面，相信由此构造的SQL语句会在Hadoop平台中有更好的执行性能。