1、SQL语句调整是优化生产SQL语句的过程，从而以最有效和最高效的方式获取结果。首先是查询里元素的基本安排，因为简单的格式化过程就能够在语句优化中发挥很大作用。
2、数据库调整和SQL语句调整的区别
- 数据库调整是调整实际数据库的过程，其目的是确保数据库的设计能够最好的满足用户对数据库操作的需求；
- SQL语句调整的目的是利用数据库和系统资源、索引，针对数据库的当前状态进行最有效的访问，从而减少对数据库执行查询所需的开销。
3、提高SQL语句可读性
让语句具有良好可读性的基本原则如下：
-
- 每个子句都已新行开头。如select和from不在同一行。
- 当子句里的参数超过一行长度需要换行时，利用制表符（TAB）或者空格形成缩进。
- 以一致的方式使用制表符和空格。
- 当语句使用多个表时，使用表的别名。
- 如果SQL实现里允许使用注释，应该在语句里有节制的使用。
- 如果在select语句里有多个字段，就让每个字段从新行开始。
- 如果from语句里有多个表，就让每个表从新行开始。
- 让where子句里每个条件都已新行开始。
注：虽然提高语句的可读性并不会直接改善其性能，但这样会帮助我们更方便的修改和调整很长和很复杂的语句。
4、from子句里表的顺序
通常把较小的表列在前面，把较大的表放在后面，这样会得到更好的性能（按ANSI标准）。但是具体使用需要查看具体数据库的优化器文档，因为每个具体数据库的优化器对表的执行顺序可能不同。
5、结合条件的次序
在where子句里，来自基表的字段一般放在结合操作的右侧，要被结合的表通常按从小到大的顺序排序。
6、最严格条件
最严格条件通常是SQL查询达到最优性能的关键因素。它就是where子句里返回最少记录的条件。我们应该让SQL优化器优先计算最严格条件，从而减少查询的开销。最严格条件的位置取决于具体数据库优化器的工作方式。
从实践总结的经验来看，最好使用具有索引的字段作为查询里的最严格条件。
7、全表扫描：对于小型表，全表扫描可能会比使用索引具有更好的性能。
8、索引通常会改善查询的性能。
下面列举应该被索引的数据
- 作为主键的字段；
- 作为外键的字段；
- 在结合表里经常使用的字段；
- 经常在查询里作为条件的字段；
- 大部分值是唯一的字段。
9、使用LIKE操作符和通配符
LIKE操作符是个很有用的工具，它能够以灵活的方式为查询设置条件。
假设我们要编写一个查询，从表EMPLYEE_TBL里选择字段EMP_ID,LAST_NAME,FIRST_NAME和STATE，获得姓为Stevens的雇员ID，姓名和所在的州。下面3个例子使用了不同的通配符。
第一个查询：
SELECT EMP_ID,LAST_NAME,FIRST_NAME,STATE
FROM EMPLOYEE_TBL
WHRER LAST_NAME LIKE 'STEVENS' 第二个查询：
SELECT EMP_ID,LAST_NAME,FIRST_NAME,STATE
FROM EMPLOYEE_TBL
WHRER LAST_NAME LIKE '%EVENS%' 第三个查询：
SELECT EMP_ID,LAST_NAME,FIRST_NAME,STATE
FROM EMPLOYEE_TBL
WHRER LAST_NAME LIKE 'ST%' 这些SQL语句并不是必须返回同样的结果。更可能的情况是，查询1利用了索引的优势，返回的记录比其他两个查询少。查询2和查询3没有明确指定要返回的数据，其检索速度要比查询1慢。另外，查询3应该比查询2更快，因为它指定了搜索字符串的开头，因此它能够利用索引。
10、避免使用OR操作符：在SQL语句里用谓词IN替代OR操作符能够提高数据库检索速度。
11、避免使用HAVING子句
HAVING子句很有用，可以减少GROUP BY子句返回的数据，但使用它也是要付出代价的。HAVING子句会让SQL优化器进行额外的工作，也就需要额外的时间。
12、避免大规模的排序操作
数据库是经常需要排序的，排序最主要的问题是会影响SQL语句的响应时间。由于大规模排序操作不是总可以避免的，所以最好把大规模排序在批处理过程里，在数据库使用的非繁忙时间运行，从而避免影响大多数用户进程的性能。
13、使用存储过程
存储过程是经过编译的、以可执行格式永久保存在数据库里的SQL语句。尤其是对经常使用的SQL语句，生成存储过程是非常有必要的。
14、批量加载时关闭索引：批量加载时，索引可能会严重的降低性能。在批加载操作的前后删除并重建索引可以还可以减少索引里的碎片。
15、基于成本的优化
用户可能经常会遇到需要进行SQL语句调整的数据库。这类系统在任何一个时间点上往往都有数千条SQL语句正在执行。要优化进行调整所花费的时间，需要首先确定需要调整的查询类型。这就是我们所关注的，基于成本的优化试图确定什么样的查询造成了系统资源的额外消耗。例如，如果我们用运行时间来作为衡量标准的话，如下两个查询会获得相应的运行时间：
SELECT * FROM CUSTOMER_TBL
WHERE CUST_NAME LIKE '%LE%' 2sec
SELECT * FROM EMPLOYEE_TBL
WHERE LAST_NAME LIKE 'G%' 1sec简单来看，第一个语句似乎就是我们需要进行优化的查询。但是，如果第二个语句每小时执行1000次，而第一个语句每小时执行10次，情况又怎么样呢？结果完全相反。
基于成本的优化根据资源消耗量对SQL语句进行排序。根据查询的衡量方法（如执行时间，读库次数等）以及给定时间段内的执行次数，可以方便的确定资源消耗量：
总计资源消耗 = 衡量方法 X 执行次数
使用这种方法，可以最大程度的获得调整收益。在上面的例子中，如果我们能够将每条语句的执行时间减半，就可以很方便的看出所节省的时间：
statement #1 : 1sec * 10 executions = 10 sec of computational savings
statement #2 : 0.5sec * 1000 executions = 500 sec of computational savings
这样就很容易理解，为什么要把宝贵的时间花在第二条语句上了。这不仅仅优化了数据库，也同时优化了用户的时间。
16、性能工具
很多关系型数据库具有内置的工具用于SQL语句和数据库性能调整。如，Oracle有一个名为EXPLAIN PLAN的工具，可以向用户显示SQL语句的执行计划。还有一个工具是TKPROF，它可以测量SQL语句的实际执行时间。在SQL Server中有一个Query Analyzer，可以向用户提高估计的执行计划或者已经执行查询的统计参数。
PS：1、以上内容基于ANSI标准，不针对具体数据库平台；
2、以上都是以理论进行讨论，实际的工作中，需要考虑很多因素，设计人员的经验等，花费一定的时间，综合考虑的情况下，甚至需要不断的尝试才可能找到适合需要的优化方案。
3、现在的实际开发中，其实对数据库的设计不是那么严格（比如完整性约束等都是缺失的），建议更多的开发人员花点时间完善数据库设计的优化，以改善数据库性能。（现在数据越来越加的重要）