【再回首:数据库篇】SQL语句的优化
PS:https://editor.csdn.net/md/?articleId=106350805 为本人CSDN博客，为了方便，我直接搬到博客园中。
在实际生产工作中，每日的数据流水很大时，优质SQL语句与劣质的SQL语句天差地别。优质的SQL语句在日常生活中，能提高查询、操作数据库的效率，而劣质的SQL语句，轻则查询效率低，重则数据库宕机。
在日常开发中，不能拿到项目就开始编写程序，应该先观察表结构，查看内部联系，查看是否有索引，如果没有应当适当添加索引，在确定思路后，开始开发，这样可以提高适用性，减少开发程序的错误率和运行性能问题。
错误事例如下：
select a.empno, b.deptno
from remotedb@onhdrb:empno a , statistics@onhdrb:tjywbm b
where a.deptno=b.ywbm;
错误事例如下：
select processtype, ds_process.ds_process_id, ds_process.createperson,
ds_process.startdatetime, dsb_apply.dsb_apply_id, ds_activity.executeorg,
ds_activity.step
from ds_activity, ds_process, dsb_apply
where ds_process.ds_process_id=dsb_apply.ds_process_id and
ds_process.processtype=3 and ds_process.nextactivitytype=2 and
ds_process.createperson=3394 and
ds_activity.ds_activity_id=ds_process.ds_activity_id order by
dsb_apply.dsb_apply_id desc
上面的事例如若在数据量巨大的时候很有可能，让服务器宕机，关联过多且查询量大时，查询效率极其低。
两表均超过5000条以上记录的关联表查询要填定<<关联SQL语句编写审批表>>，经审批同意才能按审批同意的语句使用（关联字段也需建立在索引基础上）。当Where 子句中包含多个表联立时，应把返回行数最少的排在最后。
提交事务原则上应在后台程序进行，严格禁止C/S结构、B/S结构类系统在前台处理程序中提交离散性、等待性事务。由于长事务容易造成数据库死锁，所以事务开始与事务结束之间，应集中编写,一次性提交，且禁止有select语句存在。(但可以有开发工具本身的不引起数据库操作的函数和语句，也可有PB自身的自动提交功能)。
多用户并发抢号机制建议采用“共享-抢占-重试”的方式进行，不建议采用“抢点-锁定-解锁”的方式进行。
原则上不建议采用向源表采用正向“抽取“数据的方式，而应采取通过一次扫描源表向多个目的表”推送“填写数据的方式来开发统计、汇总类程序，可有效提高运行效率
所以尽量减少order by,group by,distinct等排序操作；如必须使用排序操作，排序应建立在有索引的列上.同时不建议使用关联查询的多字段排序。
SELECT语句中应写出要选择的全部列名，增强语句可读性，避免不必要的选择；SELECT * 增加了对所有字段的依赖，当表增加了字段后，有可能发生错误；此外还可能增加了数据的流量，查询了一些实际不需要的字段；
因为大小写结合需要 输入大写字母速度慢。（相同的SQL语句是在SQL缓冲区中读取，SQL分析器不用对SQL语句重新分析产生执行计划，系统响应时间大大减少）。