1，统一SQL语句的写法
对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 所以封装成复用方法，用标准模板来控制。
select*from dual
select*From dual
其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划
2，不要把SQL语句写得太复杂
我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
比如 Select语句的结果作为子集
简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表 也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
3，必须采用绑定变量
select*from orderheader where changetime >‘2010-10-20 00:00:01‘
select*from orderheader where changetime >‘2010-09-22 00:00:01‘
select*from orderheader where changetime >‘2010-09-22 00:00:01‘
以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。如果采用绑定变量
select*from orderheader where changetime >@chgtime
4，使用like进行模糊查询时应注意
有的时候会需要进行一些模糊查询比如
select*from contact where username like ‘%yue%’
关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%，
5，联表查询
(1) 连接字段尽量选择聚集索引所在的字段
(2) 仔细考虑where条件，尽量减小A、B表的结果集
获取下载地址 springmvc+mybatis+spring 整合 bootstrap html5
6，索引，
看sql 的性能，主要看执行计划，还有cpu成本，io成本等。这里就以一个简单的表为例。
首先，创建一个简单的表，一般会先建个主键，系统自动以主键建聚集索引。
判断是否需要优化sql的一个简单规则是：看执行计划中的操作是seek(搜索)还是scan（扫描）
是scan的话就要索引。
使用场景：
当一个系统查询比较频繁，而新建，修改等操作比较少时，可以创建覆盖索引，将查询字段和where子句里的字段全部包含在内，这样查询的速度会比以前快很多，同时也带来弊端，就是新建或修改等操作时，比没有索引或没有建立覆盖索引时的要慢。读写数据库分离也能解决问题
经常对Creator_Id字段查询，就做个索引。
对表Article的Creator_Id字段建索引
CREATE INDEX Ix_article_creatorid ON Article(Creator_Id)
set statistics io 和 set statistics，这是性能调优时查看相关cpu占用时间，IO资源数据的两个比较重要的命令
记得Order by 语句加索引
7，读写分离
当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性
主从分离，对数据库层面就是数据同步或者是数据复制；从应用层讲就是请求的分离：增删改请求主库，查询请求从库
8，尽量不用select * from …..
,而要写字段名 select field1,field2,…这条没什么好说的，主要是按需查询，不要返回不必要的列和行。
9 任何对列的操作都将导致表扫描，
它包括数据库函数、计算表达式等，查询时要尽可能将操作移至等号右边
10 In 、or子句常会使索引失效
显而易见的，IN,OR扩大的查询范围。
11通常情况下，连接比子查询效率要高
必然的，需要子查询时，也是用临时表暂存中间结果