‘壹’ 什么叫sql语句的优化
意思就是要执行的效率高
譬如select * from tabla_name where id=1 可以执行
select * from tabla_name where id in (1) 也可以执行
但是比较来看，=1的比in (1)的效率要高
只是举个简单的例子，实际操作里并不是如此简单
‘贰’ 优化SQL有什么方法
在数据库应用系统中编写可执行的SQL语句可以有多种方式实现，但哪一条是最佳方案却难以确定。为了解决这一问题，有必要对SQL实施优化。简单地说，SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能更好的SQL语句。
优化SQL语句的原因
数据库系统的生命周期可以分成: 设计、开发和成品三个阶段。在设计阶段进行优化的成本最低，收益最大。在成品阶段进行优化的成本最高，收益最小。如果将一个数据库系统比喻成一座楼房，在楼房建好后进行矫正往往成本很高而收效很小（甚至可能根本无法矫正），而在楼房设计、生产阶段控制好每块砖瓦的质量就能达到花费小而见效高的目的。
为了获得最大效益，人们常需要对数据库进行优化。数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升全部加起来只占数据库应用系统性能提升的40%左右，其余60%的系统性能提升全部来自对应用程序的优化。许多优化专家甚至认为对应用程序的优化可以得到80%的系统性能提升。因此可以肯定，通过优化应用程序来对数据库系统进行优化能获得更大的收益。
对应用程序的优化通常可分为两个方面: 源代码的优化和SQL语句的优化。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高(尤其是对正在使用中的系统进行优化) 。另一方面，源代码的优化对数据库系统性能的提升收效有限，因为应用程序对数据库的操作最终要表现为SQL语句对数据库的操作。
对SQL语句进行优化有以下一些直接原因：
1. SQL语句是对数据库(数据) 进行操作的惟一途径，应用程序的执行最终要归结为SQL语句的执行，SQL语句的效率对数据库系统的性能起到了决定性的作用。
2. SQL语句消耗了70%～90%的数据库资源。
3. SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低。
4. SQL语句可以有不同的写法，不同的写法在性能上的差异可能很大。
5. SQL语句易学，难精通。SQL语句的性能往往同实际运行系统的数据库结构、记录数量等有关，不存在普遍适用的规律来提升性能。
传统的优化方法
SQL程序人员在传统上采用手工重写来对SQL语句进行优化。这主要依靠DBA或资深程序员对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较以试图找到性能较佳的SQL语句。这种做法存在着以下不足：
1. 无法找出SQL语句的所有可能写法。很可能花费了大量的时间也无法找到性能较佳的SQL语句。即便找到了某个性能较佳的SQL语句也无法知道是否存在性能更好的写法。
2. 非常依赖于人的经验，经验的多寡往往决定了优化后SQL语句的性能。
3. 非常耗时间。重写-->校验正确性-->比较性能，这一循环过程需要大量的时间。
根据传统的SQL优化工具的功能，人们一般将优化工具分为以下三代产品：
第一代的SQL优化工具是执行计划分析工具。这类工具对输入的SQL语句从数据库提取执行计划，并解释执行计划中关键字的含义。
第二代的SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析来产生是否要增加索引的建议。这类工具存在着致命的缺点——只分析了一条SQL语句就得出增加某个索引的结论，根本不理会(实际上也无法评估到)增加的索引对整体数据库系统性能的影响。
第三代工具是利用人工智能实现自动SQL优化。
人工智能自动SQL优化
随着人工智能技术的发展和在数据库优化领域应用的深入，在20世纪90年代末优化技术取得了突破性的进展，出现了人工智能自动SQL优化。人工智能自动SQL优化的本质就是借助人工智能技术，自动对SQL语句进行重写，找到性能最好的等效SQL语句。LECCO SQL Expert就采用了这种人工智能技术，其SQL Expert支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。其突出特点是自动优化SQL语句。除此以外，还可以以人工智能知识库“反馈式搜索引擎”来重写SQL语句，并找出所有等效的SQL语句及可能的执行计划，通过测试运行为应用程序和数据库自动找到性能最好的SQL语句，提供微秒级的计时; 能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句; 能通过比较源SQL和待选SQL的不同之处，为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能等等。
该工具针对数据库应用的开发和维护阶段提供了数个特别的模块：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块之一“SQL 语法优化器”的工作原理大致如下：输入一条源SQL语句，“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出，产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满，接下来对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句(不同的执行计划意味着不同的执行效率)，最后，对得到的SQL语句进行批量测试，找出性能最好的SQL语句（参见下图）。
图 人工智能自动SQL优化示意图
LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的SQL语句自动优化功能使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮开发人员找到最好性能的写法。
小 结
SQL语句是数据库应用中一个非常关键的部分，它执行性能的高低直接影响着应用程序的运行效率。正因为如此，人们在SQL语句的优化上投入了很大的精力，出现了许多SQL语句优化工具。随着人工智能等相关技术的日益成熟, 肯定还会有更多更好的工具出现，这将会给开发人员提供更多的帮助。
‘叁’ 什么是SQL的查询优化,举例说明
1 使用SET NOCOUNT ON 选项：
缺省地，每次执行SQL语句时，一个消息会从服务端发给客户端以显示SQL语句影响的行数。这些信息对客户端来说很少有用。通过关闭这个缺省值，你能减少在服务端和客户端的网络流量，帮助全面提升服务器和应用程序的性能。为了关闭存储过程级的这个特点，在每个存储过程的开头
包含“SET NOCOUNT ON”语句。
2 正确使用UNION和UNION ALL：
许多人没完全理解UNION和UNION SELECT是怎样工作的，因此，结果浪费了大量不必要的SQLServer资源。当使用UNION时，它相当于在结果集上执行SELECT DISTINCT。换句话说，UNION将联合两个相类似的记录集，然后搜索重复的记录并排除。如果这是你的目的，那么使用UNION是正
确的。但如果你使用UNION联合的两个记录集没有重复记录，那么使用UNION会浪费资源，因为它要寻找重复记录，即使你确定它们不存在。
所以如果你知道你要联合的记录集里没有重复，那么你要使用UNION ALL，而不是UNION。UNION ALL联合记录集，但不搜索重复记录，这样减少SQLServer资源的使用，从而提升性能。
3 尽量不用SELECT * ：
绝大多数情况下，不要用 * 来代替查询返回的字段列表，用 * 的好处是代码量少、就算是表结构或视图的列发生变化，编写的查询SQL语句也不用变，都返回所有的字段。但数据库服务器在解析时，如果碰到 *，则会先分析表的结构，然后把表的所有字段名再罗列出来。这就增加了
分析的时间。
4 慎用SELECT DISTINCT：
DISTINCT子句仅在特定功能的时候使用，即从记录集中排除重复记录的时候。这是因为DISTINCT子句先获取结果集然后去重，这样增加SQLServer有用资源的使用。当然，如果你需要去做，那就只有去做了。
当如果你知道SELECT语句将从不返回重复记录，那么使用DISTINCT语句对SQLServer资源不必要的浪费。
5 少用游标：
任何一种游标都会降低SQLServer性能。有些情况不能避免，大多数情况可以避免。所以如果你的应用程序目前正在使用TSQL游标，看看这些代码是否能够重写以避免它们。如果你需要一行一行的执行操作，考虑下边这些选项中的一个或多个来代替游标的使用：
使用临时表
使用WHILE循环
使用派生表
使用相关子查询
使用CASE语句
使用多个查询
上面每一个都能取代游标并且执行更快。 如果你不能避免使用游标，至少试着提高它们的速度，找出加速游标的方法。
6 选择最有效率的表名顺序：
SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表（基础表driving table）将被最先处理，在FROM子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当SQLSERVER处理多个表时，会运用排序及合并的方式连接它们。首先
，扫描第一个表（FROM子句中最后的那个表)并对记录进行排序；然后扫描第二个表（FROM子句中最后第二个表)；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。
例如: 表 TAB1有 16384 条记录，表 TAB2 有5条记录，选择TAB2作为基础表 (最好的方法)：
select count(*) from TAB1 a, TAB2 b
选择TAB1作为基础表 (不佳的方法)：
select count(*) from TAB2 a, TAB1 b
如果有3个以上的表连接查询，那就需要选择交叉表（intersection table）作为基础表，交叉表是指那个被其他表所引用的表。
7 使用表的别名(Alias)：
当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上，这样可以减少解析的时间并减少那些由Column歧义引起的语法错误。
8 SARG你的WHERE条件：
ARGE来源于"Search Argument"（搜索参数）的首字母拼成的"SARG"，它是指WHERE子句里，列和常量的比较。如果WHERE子句是sargable（可SARG的），这意味着它能利用索引加速查询的完成。如果WHERE子句不是可SARG的，这意味着WHERE子句不能利用索引（或至少部分不能利用），
执行的是全表或索引扫描，这会引起查询的性能下降。
在WHERE子句里不可SARG的搜索条件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'"，通常（但不总是）会阻止查询优化器使用索引执行搜索。另外在列上使用包括函数的表达式、两边都使用相同列的表达式、或和一个列（不是常
量）比较的表达式，都是不可SARG的。
并不是每一个不可SARG的WHERE子句都注定要全表扫描。如果WHERE子句包括两个可SARG和一个不可SARG的子句，那么至少可SARG的子句能使用索引（如果存在的话）帮助快速访问数据。
大多数情况下，如果表上有包括查询里所有SELECT、JOIN、WHERE子句用到的列的覆盖索引，那么覆盖索引能够代替全表扫描去返回查询的数据，即使它有不可SARG的WHERE子句。但记住覆盖索引尤其自身的缺陷，如此经常产生宽索引会增加读磁盘I/O。某些情况下，可以把不可SARG的WHER
E子句重写成可SARG的子句。例如：
WHERE SUBSTRING(firstname,1,1) = 'm'
可以写成：
WHERE firstname like 'm%'
这两个WHERE子句有相同的结果，但第一个是不可SARG的（因为使用了函数）将运行得慢些，而第二个是可SARG的，将运行得快些。
如果你不知道特定的WHERE子句是不是可SARG的，在查询分析器里检查查询执行计划。这样做，你能很快的知道查询是使用了索引还是全表扫描来返回的数据。仔细分析，许多不可SARG的查询能写成可SARG的查询。下面分几点讲解WHERE条件的SARG。
8.1 WHERE子句中的连接顺序
SQLSERVER采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。例如：
(低效)
SELECT * FROM EMP E
WHERE SAL > 50000
AND JOB = ‘MANAGER’
AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
(高效)
SELECT * FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
AND SAL > 50000
AND JOB = ‘MANAGER’
8.2 避免困难的正规表达式：
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：
SELECT * FROM customer WHERE zipcode LIKE "98_ _ _"
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT * FROM customer WHERE zipcode >="98000"，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：
SELECT * FROM customer WHERE zipcode[2，3] >"80"
在where子句中采用了非开始子串，因而这个语句也不会使用索引。
8.3 避免对大型表行数据的顺序存取：
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（
学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT * FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT * FROM orders WHERE customer_num=104 AND order_num>1001
UNION ALL
SELECT * FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
8.4 EXISTS和IN的使用：
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。 在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率。在子查询中，NOT IN子句将执行一个内部的排序和合并。无论在哪种情况下，NOT IN都是最低效的，因为它对子查询中的表执行
了一个全表遍历。为了避免使用NOT IN，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。
8.5 避免在索引列上使用IS NULL和IS NOT NULL：
避免在索引中使用任何可以为空的列，SQLSERVER将无法使用该索引。对于单列索引，如果列包含空值，索引中将不存在此记录；对于复合索引，如果每个列都为空，索引中同样不存在此记录。如果至少有一个列不为空，则记录存在于索引中。
如果唯一性索引建立在表的A列和B列上，并且表中存在一条记录的A,B值为(123,null)，SQLSERVER将不接受下一条具有相同A,B值（123,null）的记录插入。
如果所有的索引列都为空，SQLSERVER将认为整个键值为空，而空不可能等于空，因此你可以插入1000条具有相同键值的记录，当然它们都是空！因为空值不存在于索引列中，所以WHERE子句中对索引列进行空值比较将使SQLSERVER停用该索引。下面的代码将会很低效（索引失效）：
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL
8.6 避免在索引列上使用计算：
WHERE子句中，如果索引列是函数的一部分，优化器将不使用索引而使用全表扫描。 例如下面的语句低效 ：
SELECT … FROM DEPT WHERE SAL * 12 > 25000
而下面的语句将是高效的：
SELECT … FROM DEPT WHERE SAL > 25000/12
请务必注意，查询中不要对索引列进行处理，如：TRIM，substring，convert等等操作。
8.7 用WHERE子句替换HAVING子句：
避免使用HAVING子句，HAVING只会在检索出所有记录之后才对结果集进行过滤，这个处理需要排序、统计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。
9 避免或简化排序：
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
l 索引中不包括一个或几个待排序的列；
l group by或order by子句中列的次序与索引的次序不一样；
l 排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
10 临时表的使用：
临时表有很多特殊的用途，象用来替代游标，不过它们仍能引起性能问题，如果这个问题能消除，SQLServer将执行得更快。在永久表和临时表的数据行相同的条件下，使用临时表没有永久表快。但有时还必须得使用临时表，如先从存储大量数据的永久表中提取符全条件的存放到临时
表，然后在临时表上执行操作。如果是直接在存储大量数据的永久表上执行操作（如：统计、循环等），其性能将大打折扣。所以，使不使用临时表，何时使用临时表，需要具体情况决定。
11 是否使用视图：
视图最大的用途是处理安全相关的问题，而不是一些懒惰的开发人员用来存储经常使用的查询的方法。例如，如果你需要允许用户访问特定SQLServer的数据，那么你也许可以考虑为用户（或组）创建一个视图，然后给用户访问视图而不是基表的权限。另一方面，在应用程序里，从视图选
择数据没有好的理由，相反，绕过视图直接从需要的表里获取数据。原因是许多视图（当然不是全部）返回比SELECT语句所需更多的数据，增加不必要的开销。
例如，假定有一个视图从两个连接表里返回10列。你想要从视图里使用SELECT语句返回其中7列。实际上发生的情况是基于视图的查询先运行，返回数据，然后你的查询针对这些数据运行。既然你仅需要7列，而不是视图返回的10列，更多不必要的数据被返回。浪费SQLServer的资源。
长久以来，大家在争论是查询视图速度快还是直接查询快，本人也不敢轻易下结论，因此作了多次试验，其结果是：基于视图查询，性能确实不会比直接写查询语句快，对于简单的查询，最多是在同一水平上。
当然，上面的测试是在没有为视图创建索引的情况下，SQLServer2000以上可以为视图创建索引，视图索引与表的索引在作用方式上非常相似。与表一样，视图可以有一个集簇索引（clustered index）和多个非集簇索引。创建视图索引后能够提高视图的性能。
如果视图不包含索引，则数据库中不保存视图返回的结果集。有的时候，我们可能要创建涉及大量记录或必须进行复杂计算的视图，比如要进行聚合分组处理或多重连接操作。如果每次引用这些视图的时候让sql server重新生成结果集，数据库开销将非常大。
12 让事务尽可能的短：
保持TSQL事务尽可能的短。这会帮助减少锁（所有类型的锁）的数量，有助于全面提升SQLServer的性能。如果有经验，你也许要将长事务分成更小的事务组。
13 用存储过程代替直接写查询语句：
存储过程为开发人员提供了很多好处，包括：
n 减少网络流量和响应时间，提升应用程序性能。例如，通过网络发送一个存储过程调用，而不是发送500行的TSQL将更快，资源使用更少。当每次执行SQL时，都会执行解析SQL语句、估算索引的利用率、绑定变量、读数据块等等工作。
n 存储过程执行计划能够重用，驻留在SQLServer内存的缓存里，减少服务器开销。
n 客户端执行请求更有效率。例如，如果应用程序需要插入大量的二进制值到一个image数据列而不使用存储过程，它必须转化二进制为字符串（大小会增加一倍），然后发送给SQLServer。当SQLServer接收到后，它必须把字符串值转回二进制格式。大量的浪费开销。存储过程能
消除这个问题通过将应用程序传给SQLServer的二进制格式作为参数，从而减少开销提升性能。
n 存储过程帮助提供代码重用。虽然这些不直接提升应用程序的性能，通过减少代码量和减少调试时间来提升开发人员的效率。
n 存储过程能封装逻辑。你能够改变存储过程代码而不影响客户端（假定你保持参数相同也不移除任何结果集的列）。这节约开发人员的时间。
n 存储过程为你的数据提供更好的安全性。如果你仅使用存储过程，你可以移除直接对表的SELECT、INSERT、UPDATE和DELETE权限从而强迫开发人员使用存储过程访问数据。这会节约DBA的时间。
n 作为首要的常规，所有的TSQL代码都应该通过存储过程调用。
13.1 存储过程名不要以 sp_ 开头：
对这一准则，可能很多人会感觉纳闷，是的，我开始也纳闷过。如果创建的存储过程不是运行在Master数据库里，不要使用以sp_为前缀的名称。这个特别的前缀是为系统存储过程保留的。尽管使用这个前缀不会禁止用户定义的存储过程的运行，但会稍微降低一些执行效率。这是因为
SQLServer在执行以sp_为前缀的任何一个存储过程时缺省地首先试图在Master数据库里寻找，尽管那儿没有，这就浪费了寻找存储过程的时间。如果SQLServer在Master数据库里不能找到存储过程，那么接下来会将存储过程的拥有者作为DBO去解析。如果存储过程在目前的数据库里，那么
它会执行。为了避免不必要的延迟，不要用前缀为sp_命名你的任何一个存储过程。
13.2 存储过程的拥有者要相同：
为了最好的性能，同一个存储过程里调用的所有对象的拥有者都应该相同，DBO更适宜。如果不是那样，即对象名相同而拥有者不同，那么SQLServer必须执行名称判断。当发生这样的情形时，SQLServer不能使用存储过程里在内存里的执行计划，相反，它必须重新编译存储过程，从而
影响性能。当从应用程序里调用存储过程时，使用分隔符名称来调用也是重要的。如：
EXEC dbo.myProcere
代替：
EXEC myProcere
这样做有两个原因，其中一个和性能有关。首先，使用完全有分隔符的名称有助于消除那些和你要运行的存储过程有潜在的混淆，有助于禁止BUG和潜在的问题。但更重要的是，这样做SQLServer能更直接的访问存储过程执行计划，而不是轮流访问，从而加速了存储过程的性能。当然性能
提升很小，但如果你的服务器每小时要运行成千上万或更多的存储过程，这些节约的小段时间加起来就很可观了。
14 完整性使用下的约束和触发器：
数据库里不要执行多余的完整性特点。例如，如果你正使用主键和外键约束来强迫引用完整性，则不要添加触发器来实现相同的功能而增加不必要的开销。同样既使用约束又使用默认值或既使用约束又使用规则也会执行多余的工作。
15 在SQL中捕捉异常：
这一条准则应该不能算是优化方面的，只是编写要求。现在SQLServer2005中，新增了BEGIN TRY…END TRY和 BEGIN CATCH…END CATCH二个成对语句，用于捕捉运行时出现的异常。在Oracle中，可用 BEGIN…EXCEPTION…END 语句捕捉异常。
把SQL代码块中加入捕捉异常的语句内，有二个好处：一是可以在SQL语句内部得到异常并作错误处理，如在错误代码块内返回自定义错误信息、ROLBACK等。这样可减少应用程序捕捉异常带来的资源开销；另外一个好处就是可以防止死锁情况的发生，当出现死锁时，SQLServer2005会抛出
异常，我们就可捕捉到。
下面列出一些索引的概念，有助于设计表结构和编写SQL语句：
按照存储规则来分：
l 聚集索引：该索引中键值的逻辑顺序决定了表中相应行的物理顺序。因此一个表只能包含一个聚集索引，但该索引可以包含多个列（组合索引）。检索效率比普通索引高，但对数据新增/修改/删除的影响比较大。
l 非聚集索引：与聚集索引相对，不影响表中的数据存储顺序，检索效率比聚集索引低，对数据新增/修改/删除的影响很少。
按照维护与管理的角度来分：
l 唯一索引：惟一索引可以确保索引列不包含重复的值，可以用多个列，但是索引可以确保索引列中每个值组合都是唯一的。
l 主键索引：在数据库关系图中为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的。当在查询中使用主键索引时，它还允许快速访问数据。
l 普通索引：由关键字KEY或INDEX定义的索引，唯一任务是加快对数据的访问速度。因此，应该只为那些最经常出现在查询条件或排序条件中的数据列创建索引。只要有可能，就应该选择一个数据最整齐、最紧凑的数据列(如整数类型的数据列)来创建索引。允许有重复的列存在
。
l 复合索引：如果在两上以上的列上创建的索引，则称为复合索引。
‘肆’ sql优化具体指的是什么
定位有问题的语句，检查执行计划，检查执行过程中优化器的统计信息，分析相关表的记录数、索引情况改写SQL语句、使用HINT、调整索引、表分析有些SQL语句不具备优化的可能，需要优化处理方式达到最佳执行计划。但是最佳的执行计划不一定是最佳的执行情况。一切以实际执行的情况为准。
‘伍’ 数据库优化是什么意思
数据库优化的意思 是减少代码的冗余 提高重用性
‘陆’ sql语句优化有什么方法
1 尽可能建立索引，包括条件列，连接列，外键列 等
2 尽可能让where中的列顺序与复合索引的列顺序一致
3 尽可能不要select *，而只列出自己需要的字段列表
4 尽可能减少子查询的层数
5 尽可能在子查询中进行数据筛选 ...
‘柒’ 什么叫做数据库优化
数据库优化，是根据一开始网站数据库设计而进行的优化。开始网站设计的时候，可能考虑的不是很全面。后期网站访问量增加，出现页面数据显示过慢，程序执行效果差等现象。优化数据库从而加速数据读取，页面访问速度加快。
常见的优化：
1.增加索引
2.sql语句优化
3.程序优化
详细的可以网络一下。。。网上例子很多。。
‘捌’ 通常的SQL优化都有什么方式求简单明了描述！！！
sql写多了，至于优化，学习中，只晓得子查询数据量大的话弄个临时表能更快点
‘玖’ 列举sql优化有哪些方式方法 博客园
sql优化的方式有：
1、选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表。
2、WHERE子句中的连接顺序：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。
3、SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 。
4、 减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 。
6、 使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。
7、整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)。
‘拾’ sql优化 具体
指教下啦 我是新手 多多关照
key 0:53:29
对于优化
不知不怪/mg 0:53:57
咋说呀
key 0:54:00