SQL语句及数据库优化

颇为阿娇978

　　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‘
　　以上两句语句，查询优化器认为是不同的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通常情况下，连接比子查询效率要高
　　必然的，需要子查询时，也是用临时表暂存中间结果