SQL语句常用的优化方法
复杂sql优化的方法及思路
复杂sql优化的方法及思路复杂SQL优化的方法及思路在实际的开发中，我们经常会遇到需要处理大量数据的情况，而这些数据往往需要通过SQL语句进行查询、统计、分析等操作。
然而，当数据量变得越来越大时，SQL语句的执行效率也会变得越来越低，这时就需要进行SQL优化来提高查询效率。
下面介绍一些复杂SQL 优化的方法及思路。
1. 索引优化索引是提高SQL查询效率的重要手段之一。
在使用索引时，需要注意以下几点：（1）选择合适的索引类型：根据查询条件的特点选择合适的索引类型，如B-Tree索引、Hash索引、全文索引等。
（2）避免过多的索引：过多的索引会降低SQL语句的执行效率，因为每个索引都需要占用一定的存储空间，并且在更新数据时需要维护索引。
（3）避免使用不必要的索引：有些查询条件并不需要使用索引，因此在编写SQL语句时需要避免使用不必要的索引。
2. SQL语句优化SQL语句的优化是提高查询效率的关键。
在编写SQL语句时，需要注意以下几点：（1）避免使用子查询：子查询会增加SQL语句的复杂度，降低查询效率。
可以使用JOIN语句代替子查询。
（2）避免使用OR操作符：OR操作符会使SQL语句的执行计划变得复杂，降低查询效率。
可以使用UNION操作符代替OR操作符。
（3）避免使用LIKE操作符：LIKE操作符会使SQL语句的执行计划变得复杂，降低查询效率。
可以使用全文索引代替LIKE操作符。
3. 数据库结构优化数据库结构的优化也是提高查询效率的重要手段之一。
在设计数据库结构时，需要注意以下几点：（1）避免使用过多的表：过多的表会增加SQL语句的复杂度，降低查询效率。
可以使用视图代替多个表。
（2）避免使用过多的字段：过多的字段会增加SQL语句的复杂度，降低查询效率。
可以使用分表代替过多的字段。
（3）避免使用过多的关联：过多的关联会增加SQL语句的复杂度，降低查询效率。
可以使用冗余字段代替过多的关联。
复杂SQL优化需要从索引优化、SQL语句优化和数据库结构优化三个方面入手，通过合理的优化手段提高查询效率，从而提高系统的性能和稳定性。
sql优化in和notin语句
sql优化in和notin语句WHY？IN 和 NOT IN 是⽐较常⽤的关键字，为什么要尽量避免呢？1、效率低可以参看我之前遇到的⼀个例⼦（）2、容易出现问题，或查询结果有误（不能更严重的缺点）以 IN 为例。
建两个表：test1 和 test2create table test1 (id1 int)create table test2 (id2 int)insert into test1 (id1) values (1),(2),(3)insert into test2 (id2) values (1),(2)我想要查询，在test2中存在的 test1中的id 。
使⽤IN的⼀般写法是：select id1 from test1where id1 in (select id2 from test2)结果是： OK ⽊有问题！但是如果我⼀时⼿滑，写成了：select id1 from test1where id1 in (select id1 from test2)不⼩⼼把id2写成id1了，会怎么样呢?结果是： EXCUSE ME！为什么不报错？单独查询 select id1 from test2 是⼀定会报错: 消息 207，级别 16，状态 1，第 11 ⾏列名 'id1' ⽆效。
然⽽使⽤了IN的⼦查询就是这么敷衍，直接查出 1 2 3这仅仅是容易出错的情况，⾃⼰不写错还没啥事⼉，下⾯来看⼀下 NOT IN 直接查出错误结果的情况：给test2插⼊⼀个空值：insert into test2 (id2) values (NULL)我想要查询，在test2中不存在的 test1中的id 。
select id1 from test1where id1 not in (select id2 from test2)结果是：空⽩！显然这个结果不是我们想要的。
我们想要3。
为什么会这样呢？原因是：NULL不等于任何⾮空的值啊！如果id2只有1和2，那么3<>1 且 3<>2 所以3输出了，但是 id2包含空值，那么 3也不等于NULL 所以它不会输出。
sql server 语句优化题目
题目：SQL Server 语句优化随着数据量的增加和数据库应用的复杂化，SQL Server 数据库在使用过程中可能会出现性能下降的情况，而对于性能下降的根本原因通常可以追溯到 SQL 语句的性能不佳。
对 SQL Server 数据库中的 SQL 语句进行优化显得尤为重要。
本文将从 SQL 语句的优化方法、常见优化技巧和注意事项等方面展开探讨。
一、SQL 语句优化的方法1. 了解执行计划在进行 SQL 语句优化时，首先需要了解 SQL 语句的执行计划。
执行计划是 SQL Server 生成的一份详细的指导书，用于指导 SQL Server 如何执行查询。
通过查看执行计划，可以清晰地了解 SQL 语句的执行过程，找到执行效率低下的地方并进行相应的优化。
2. 使用索引索引是提高 SQL 查询效率的重要手段之一。
在 SQL 查询过程中，如果涉及到大量的数据表，没有索引的情况下，数据库引擎将对整个数据表进行扫描，导致查询性能低下。
正确使用索引可以大大提高 SQL 查询的效率。
但是，过多的索引也可能会导致性能下降，因此需要根据实际情况进行合理的索引设计和使用。
3. 优化 SQL 语句在编写 SQL 语句时，应尽量避免使用 SELECT *，而是明确指定需要查询的字段，减少不必要的数据传输和计算。
尽量将复杂的逻辑操作放到数据库层面完成，减少数据传输和网络开销，提高查询效率。
二、常见的 SQL 语句优化技巧1. 避免在 WHERE 子句中使用函数在 SQL 查询中，如果在 WHERE 子句中使用了函数，数据库引擎会对每一条记录都进行函数的计算，导致查询性能低下。
应尽量避免在WHERE 子句中使用函数，可以通过其他方法来达到相同的查询效果。
2. 使用 UNION ALL 替代 UNION在 SQL 查询中，如果使用 UNION 进行多个查询结果的合并，数据库引擎会进行重复数据的去重操作，导致性能下降。
而使用 UNION ALL 则可以避免重复数据的去重操作，提高查询效率。
sqlsqerver语句优化方法
sqlsqerver语句优化方法SQL Server是一种关系型数据库管理系统，可以使用SQL语句对数据进行操作和管理。
优化SQL Server语句可以提高查询和操作数据的效率，使得系统更加高效稳定。
下面列举了10个优化SQL Server语句的方法：1. 使用索引：在查询频繁的列上创建索引，可以加快查询速度。
但是要注意不要过度索引，否则会影响插入和更新操作的性能。
2. 避免使用SELECT *：只选择需要的列，避免不必要的数据传输和处理，提高查询效率。
3. 使用JOIN替代子查询：在进行关联查询时，使用JOIN操作比子查询更高效。
尽量避免在WHERE子句中使用子查询。
4. 使用EXISTS替代IN：在查询中使用EXISTS操作比IN操作更高效。
因为EXISTS只需要找到一个匹配的行就停止了，而IN需要对所有的值进行匹配。
5. 使用UNION替代UNION ALL：如果对多个表进行合并查询时，如果不需要去重，则使用UNION ALL操作比UNION操作更高效。
6. 使用TRUNCATE TABLE替代DELETE：如果要删除表中的所有数据，使用TRUNCATE TABLE操作比DELETE操作更高效。
因为TRUNCATE TABLE不会像DELETE一样逐行删除，而是直接删除整个表的数据。
7. 使用分页查询：在需要分页显示查询结果时，使用OFFSET和FETCH NEXT操作代替传统的使用ROW_NUMBER进行分页查询。
这样可以减少查询的数据量，提高效率。
8. 避免使用CURSOR：使用游标(CURSOR)会增加数据库的负载，降低查询效率。
如果可能的话，应该尽量避免使用游标。
9. 使用参数化查询：使用参数化查询可以减少SQL注入的风险，同时也可以提高查询的效率。
因为参数化查询会对SQL语句进行预编译，可以复用执行计划。
10. 定期维护数据库：定期清理过期数据、重建索引、更新统计信息等维护操作可以提高数据库的性能。
sql长语句
sql长语句在数据库开发和管理中，SQL语句是一种用于与数据库交互的编程语言。
在日常的数据库操作中，我们常常会遇到一些较长的SQL语句，这些长语句可能是由于复杂的业务逻辑或者多表关联而导致的。
本文将探讨长SQL语句的特点、使用注意事项以及优化方法。
一、长SQL语句的特点长SQL语句通常具有以下几个特点：1. 复杂性：长SQL语句往往包含多个表的连接、子查询、函数调用等复杂的操作，使得语句的逻辑较为复杂。
2. 冗余性：长SQL语句可能包含大量的冗余代码，例如重复的函数调用、重复的子查询等，这些冗余会导致语句效率降低。
3. 可读性差：由于语句过长，很难一眼看清其逻辑和结构，给后续维护和调试带来困难。
4. 执行时间长：长SQL语句的执行时间通常较长，容易造成数据库性能问题。
二、使用长SQL语句的注意事项在使用长SQL语句进行数据库操作时，需要注意以下几个问题：1. 可维护性：长SQL语句的可读性差，因此在编写时需要注重代码缩进、换行和注释，使其结构更加清晰，方便后续维护和调试。
2. 性能优化：长SQL语句执行时间长，容易影响数据库性能。
可以通过合理设计数据库表结构、创建索引、优化查询语句等手段提升性能。
3. 容错处理：长SQL语句可能会因为表名、字段名写错或者表结构变更而报错。
需要做好异常处理，避免数据库操作失败。
4. SQL注入：长SQL语句容易受到SQL注入攻击。
在构造SQL语句时，需要对输入的参数进行合法性检查和转义，避免潜在的安全风险。
三、优化长SQL语句的方法针对长SQL语句存在的问题，我们可以采用以下几种优化方法：1. 分解长SQL语句：将长SQL语句拆分成多个较短的语句，可以提高可读性和维护性。
例如，将复杂的查询拆分成多个子查询或者使用临时表进行中间结果存储。
2. 使用WITH子句：WITH子句可以在查询中定义临时表，然后在查询中引用这些临时表，提高可读性和可维护性。
3. 减少冗余代码：通过合理设计数据库表结构，减少不必要的冗余字段和冗余数据。
复杂sql优化的方法及思路
复杂sql优化的方法及思路复杂SQL优化的方法及思路SQL是关系型数据库管理系统中最常用的语言，但是在处理复杂查询时，SQL语句往往会变得非常复杂和冗长，导致查询速度缓慢。
为了提高查询效率，我们需要进行SQL优化。
以下是一些复杂SQL优化的方法及思路。
1.索引优化索引是提高数据库查询效率的重要手段之一。
在设计表结构时，应该根据实际情况建立适当的索引。
在查询语句中使用索引可以大大减少数据扫描量，从而提高查询效率。
2.避免使用子查询子查询虽然方便了我们编写复杂的SQL语句，但是在执行过程中会增加额外的开销。
因此，在编写复杂SQL语句时应尽量避免使用子查询。
3.减少JOIN操作JOIN操作也是影响查询效率的一个重要因素。
在设计表结构时应尽量避免使用JOIN操作或者减少JOIN操作次数。
4.合理使用聚合函数聚合函数（如SUM、AVG等）可以对数据进行统计分析，在处理大量数据时非常有用。
但是，在使用聚合函数时要注意不要频繁调用，否则会降低查询效率。
5.使用EXPLAIN命令分析查询语句EXPLAIN命令可以分析查询语句的执行计划，从而找出影响查询效率的因素。
通过分析EXPLAIN结果，可以对SQL语句进行优化。
6.避免使用SELECT *SELECT *会查询所有列，包括不需要的列，增加了数据扫描量，降低了查询效率。
在编写SQL语句时应尽量避免使用SELECT *。
7.合理使用缓存缓存可以减少数据库访问次数，提高查询效率。
在设计系统架构时应考虑缓存的使用。
8.优化表结构表结构的设计也是影响SQL查询效率的一个重要因素。
在设计表结构时应尽量避免冗余数据和过多的列。
以上是一些复杂SQL优化的方法及思路。
通过合理运用这些方法和思路，可以大大提高SQL查询效率，为数据库管理系统提供更好的性能和稳定性。
oracle sql优化常用的15种方法
oracle sql优化常用的15种方法1. 使用合适的索引索引是提高查询性能的重要手段。
在设计表结构时，根据查询需求和数据特点合理地添加索引。
可以通过创建单列索引、复合索引或者位图索引等方式来优化SQL查询。
2. 确保SQL语句逻辑正确SQL语句的逻辑错误可能会导致低效查询。
因此，在编写SQL语句前，需要仔细分析查询条件，确保逻辑正确性。
3. 使用连接替代子查询在一些场景下，使用连接（JOIN）操作可以替代子查询，从而减少查询的复杂度。
连接操作能够将多个数据集合合并为一个结果集，避免多次查询和表的扫描操作。
4. 避免使用通配符查询通配符查询（如LIKE '%value%'）在一些情况下可能导致全表扫描，性能低下。
尽量使用前缀匹配（LIKE 'value%'）或者使用全文索引进行模糊查询。
5. 注意选择合适的数据类型选择合适的数据类型有助于提高SQL查询的效率。
对于整型数据，尽量使用小范围的数据类型，如TINYINT、SMALLINT等。
对于字符串数据，使用CHAR字段而不是VARCHAR，可以避免存储长度不一致带来的性能问题。
6. 优化查询计划查询计划是数据库在执行SQL查询时生成的执行计划。
通过使用EXPLAIN PLAN命令或者查询计划工具，可以分析查询计划，找出性能瓶颈所在，并对其进行优化。
7. 减少磁盘IO磁盘IO是影响查询性能的重要因素之一。
可以通过增加内存缓存区（如SGA）、使用高速磁盘（如SSD）、使用合适的文件系统（如ASM）等方式来减少磁盘IO。
8. 分区表对于大数据量的表，可以考虑使用分区表进行查询优化。
分区表可以将数据按照某个规则分散到不同的存储区域，从而减少查询范围和加速查询。
9. 批量操作尽量使用批量操作而不是逐条操作，可以减少数据库的事务处理开销，提高SQL执行效率。
可以使用INSERT INTO SELECT、UPDATE、DELETE等批量操作语句来实现。
慢sql优化思路
慢sql优化思路慢SQL优化思路是数据库开发者和管理员执行的一系列实践，用于改善从数据库服务器检索数据的性能。
通常情况下，查询的执行时间会比预期的时间更长，这就要求使用正确的慢SQL优化思路来改善查询的性能。
要实现慢SQL优化，必须先确定该查询属于哪种SQL语句，然后再探究原因。
通过探究可以知道，慢SQL有很多原因，如语法错误、不合理的查询条件、不合理的查询顺序、数据量太大、索引不合理等。
对于语法错误，通常可以通过基本的代码检查来修复，比如检查SQL语句中是否有缺少或错误的字符，检查大小写或拼写是否正确；也可以通过工具来检查，比如SQL Server Management Studio。
当查询条件不合理时，可以先诊断出此查询的实际结果，然后根据实际情况进行修改，以达到最佳效果；另外，当查询顺序不合理时，可以根据不同的查询条件来优化查询顺序，从而改善查询的性能。
当数据量太大时，可以将查询条件拆分成多个部分，并分别操作，然后将查询结果组合在一起，以减少查询的负载；此外，可以采取缓存的方式，以减少对数据库的操作，进而提高查询的效率。
对于索引不合理的问题，可以检查SQL语句中是否有使用索引，以及索引是否被使用到；如果没有使用索引，可以添加索引，以提升查询的性能；如果查询使用了索引，但索引没有被使用到，可以检查索引是否被正确地设置，例如索引字段是否正确，索引是否被更新等。
而改善慢SQL的最佳方法就是改进SQL语法，以提高查询的效率。
一般来说，改善SQL语句的方法有三种：第一种是优化语句的结构，包括去除重复的子句、嵌套子句、重新排序子句等；第二种是优化查询条件，比如添加索引、删除不必要的条件等；第三种是优化表结构，比如添加可以提高查询性能的聚集索引，删除不必要的列等。
总之，慢SQL优化思路是一系列实践，用于改善从数据库服务器检索数据的性能。
要实现慢SQL优化，必须先确定该查询属于哪种SQL语句，然后再探究原因，并采取相应的操作，以改善查询的性能。
SQL优化----百万数据查询优化
SQL优化----百万数据查询优化百万数据查询优化1．合理使⽤索引 索引是数据库中重要的数据结构，它的根本⽬的就是为了提⾼查询效率。
现在⼤多数的数据库产品都采⽤IBM最先提出的ISAM索引结构。
索引的使⽤要恰到好处，其使⽤原则如下： ●在经常进⾏连接，但是没有指定为外键的列上建⽴索引，⽽不经常连接的字段则由优化器⾃动⽣成索引。
●在频繁进⾏排序或分组（即进⾏group by或order by操作）的列上建⽴索引。
●在条件表达式中经常⽤到的不同值较多的列上建⽴检索，在不同值少的列上不要建⽴索引。
⽐如在雇员表的“性别”列上只有“男”与“⼥”两个不同值，因此就⽆必要建⽴索引。
如果建⽴索引不但不会提⾼查询效率，反⽽会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建⽴复合索引（compound index）。
●使⽤系统⼯具。
如Informix数据库有⼀个tbcheck⼯具，可以在可疑的索引上进⾏检查。
在⼀些数据库服务器上，索引可能失效或者因为频繁操作⽽使得读取效率降低，如果⼀个使⽤索引的查询不明不⽩地慢下来，可以试着⽤tbcheck⼯具检查索引的完整性，必要时进⾏修复。
另外，当数据库表更新⼤量数据后，删除并重建索引可以提⾼查询速度。
2．避免或简化排序 应当简化或避免对⼤型表进⾏重复的排序。
当能够利⽤索引⾃动以适当的次序产⽣输出时，优化器就避免了排序的步骤。
以下是⼀些影响因素： ●索引中不包括⼀个或⼏个待排序的列； ●group by或order by⼦句中列的次序与索引的次序不⼀样； ●排序的列来⾃不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提⾼是值得的）。
如果排序不可避免，那么应当试图简化它，如缩⼩排序的列的范围等。
3．消除对⼤型表⾏数据的顺序存取 在嵌套查询中，对表的顺序存取对查询效率可能产⽣致命的影响。
⽐如采⽤顺序存取策略，⼀个嵌套3层的查询，如果每层都查询1000⾏，那么这个查询就要查询10亿⾏数据。
sql server 常见优化技巧
sql server 常见优化技巧SQL Server 是一种常用的关系型数据库管理系统，用于存储和管理大量结构化数据。
在使用SQL Server 进行开发和维护数据库时，优化技巧是非常重要的，可以提高数据库的性能和效率。
本文将介绍一些常见的SQL Server 优化技巧，帮助开发人员更好地利用和管理数据库。
1. 索引优化索引是提高 SQL 查询性能的重要手段之一。
在 SQL Server 中，可以使用聚集索引和非聚集索引来优化查询。
聚集索引定义了数据的物理排序顺序，而非聚集索引则提供了对聚集索引或表中数据的快速访问。
为频繁查询的列创建适当的索引，可以显著提高查询性能。
2. 查询优化在编写 SQL 查询语句时，可以采用一些技巧来优化查询性能。
例如，避免使用SELECT * 查询所有列，而是只查询需要的列。
此外，可以使用JOIN 语句来优化多表查询，避免使用子查询和临时表等复杂操作。
3. 分区表当数据库中的表数据量非常大时，可以考虑使用分区表来优化查询性能。
通过将表数据分散存储在不同的分区中，可以减少查询的数据量，提高查询速度。
4. 缓存优化SQL Server 会自动缓存查询的执行计划，以便下次查询时可以直接使用缓存中的执行计划。
可以通过监控缓存的命中率来评估缓存的效果，并使用适当的缓存清除策略来优化缓存性能。
5. 锁定优化在多用户并发访问数据库时，锁定机制是确保数据一致性的重要手段。
但是，过多的锁定操作可能导致性能下降。
可以通过使用合适的锁定级别、合理设置事务隔离级别和减少事务的持续时间等方式来优化锁定性能。
6. 存储过程和触发器优化存储过程和触发器是SQL Server 中常用的数据库对象，可以用于封装和执行复杂的业务逻辑。
在使用存储过程和触发器时，可以遵循一些优化原则，如避免使用动态SQL、减少过多的触发器嵌套等，以提高执行效率。
7. 适当使用数据库维护计划SQL Server 提供了一些数据库维护计划，如备份、索引重建、统计信息更新等。
数据库查询优化-20条必备sql优化技巧
数据库查询优化-20条必备sql优化技巧0、序⾔本⽂我们来谈谈项⽬中常⽤的 20 条 MySQL 优化⽅法，效率⾄少提⾼ 3倍！具体如下：1、使⽤ EXPLAIN 分析 SQL 语句是否合理使⽤ EXPLAIN 判断 SQL 语句是否合理使⽤索引，尽量避免 extra 列出现：Using File Sort、Using Temporary 等。
2、必须被索引重要SQL必须被索引：update、delete 的 where 条件列、order by、group by、distinct 字段、多表 join 字段。
3、联合索引对于联合索引来说，如果存在范围查询，⽐如between、>、<等条件时，会造成后⾯的索引字段失效。
对于联合索引来说，要遵守最左前缀法则：举列来说索引含有字段 id、name、school，可以直接⽤ id 字段，也可以 id、name 这样的顺序，但是 name; school 都⽆法使⽤这个索引。
所以在创建联合索引的时候⼀定要注意索引字段顺序，常⽤的查询字段放在最前⾯。
4、强制索引必要时可以使⽤ force index 来强制查询⾛某个索引: 有的时候MySQL优化器采取它认为合适的索引来检索 SQL 语句，但是可能它所采⽤的索引并不是我们想要的。
这时就可以采⽤ forceindex 来强制优化器使⽤我们制定的索引。
5、⽇期时间类型对于⾮标准的⽇期字段，例如字符串的⽇期字段，进⾏分区裁剪查询时会导致⽆法识辨，依旧⾛全表扫描。
尽管 TIMESTAMEP 存储空间只需要 datetime 的⼀半，然⽽由于类型 TIMESTAMP 存在性能问题，建议你还是尽可能使⽤类型 DATETIME。
（TIMESTAMP ⽇期存储的上限为2038-01-19 03:14:07，业务⽤ TIMESTAMP 存在风险；）6、禁⽌使⽤ SELECT *SELECT 只获取必要的字段，禁⽌使⽤ SELECT *。
sql优化常用面试题
sql优化常用面试题在数据库应用开发中，SQL优化是一个重要的方面，它可以提升数据库的性能和效率。
在面试中，经常会遇到与SQL优化相关的问题。
本文将介绍一些常见的SQL优化面试题，并给出相应的答案。
1. 什么是SQL优化？SQL优化是指对SQL查询语句进行调整和改进，以提高查询的执行效率和查询结果的准确性。
通过合理的索引设计、查询重写、规范化数据模型等手段，可以有效减少查询的执行时间和资源消耗。
2. 如何判断SQL查询语句是否需要优化？需要优化的SQL查询语句通常具有以下特点：- 执行时间过长，超过一定的阈值。
- 占用大量的系统资源，如CPU、内存等。
- 影响其他查询的执行性能。
3. SQL优化的方法有哪些？SQL优化可以采用以下几种方法：- 索引优化：合理设计索引，避免全表扫描，提高查询效率。
- 查询重写：对复杂的查询语句进行优化，使用合适的连接方式、嵌套与连接、子查询等。
- 数据库分区：对大表进行分区存储，提高查询效率。
- 规范化数据模型：遵循数据库设计的规范，减少数据冗余和数据异常。
- 缓存机制：使用缓存技术，减少数据库查询的次数，提高查询效率。
- 分布式数据库：将数据分布在多个节点上，分布式查询，提高查询效率。
4. 如何确定哪个部分影响了查询的性能？可以通过数据库性能监控工具和性能分析工具来确定哪个部分影响了查询的性能。
常用的性能监控工具有MySQL自带的慢查询日志、show processlist命令等。
性能分析工具主要有EXPLAIN语句和性能分析器等。
5. 什么是索引？如何设计索引？索引是一种数据结构，用于加快数据库查询的速度。
索引基于表中的一列或多列创建，可以提供快速的数据查找和排序。
设计索引应注意以下几点：- 选择合适的列作为索引列，通常是经常被查询、排序或者用于连接的列。
- 不要为每个列都创建索引，过多的索引会增加维护成本，降低插入和更新的性能。
- 考虑使用组合索引，将多个列组合在一起创建索引，以满足复杂查询的需求。
SQL里IN的用法以及优化
SQL里IN的用法以及优化在SQL语句中，IN操作符可以在WHERE子句中用来指定一个范围内的值。
它允许我们指定一个值列表，并从中选取匹配这些值的行。
IN操作符可以与等于操作符（=）一起使用，它可以简化SQL语句并提高查询的效率。
IN操作符的使用方法如下：```sqlSELECT * FROM table_name WHERE column_name IN (value1,value2, ...);```在上述语句中，column_name是要比较的列名，value1、value2等是要进行匹配的值。
可以指定任意数量的值，它们之间以逗号分隔。
IN操作符的优化可以从以下几个方面考虑：1.使用索引：通过在列上创建索引，可以加快IN操作符的运行速度。
索引可以帮助数据库引擎快速定位匹配的值，并减少数据的扫描量。
2.使用JOIN语句替代IN操作符：有时候，IN操作符可以通过使用JOIN语句来替代，从而提高查询的效率。
例如，下面的两个查询语句是等价的：```sqlSELECT * FROM table1 WHERE column1 IN (SELECT column2 FROM table2);SELECT * FROM table1 t1 JOIN table2 t2 ON t1.column1 =t2.column2;```使用JOIN语句的好处是可以通过索引快速定位匹配的行，并且可以在连接过程中进行更多的优化。
3.使用EXISTS操作符：对于存在和不存在的查询，使用EXISTS操作符可能比IN操作符更有效。
EXISTS操作符不会返回具体的匹配值，只会返回存在或不存在。
```sqlSELECT * FROM table1 WHERE EXISTS (SELECT * FROM table2 WHERE table1.column1 = table2.column2);```使用EXISTS操作符时，数据库引擎可以在找到匹配的行后立即停止，提高查询的效率。
SQL大量数据查询的优化及非用like不可时的处理方案
SQL⼤量数据查询的优化及⾮⽤like不可时的处理⽅案1.对查询进⾏优化，应尽量避免全表扫描，⾸先应考虑在 where 及 order by 涉及的列上建⽴索引。
2.应尽量避免在 where ⼦句中对字段进⾏ null 值判断，否则将导致引擎放弃使⽤索引⽽进⾏全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=03.应尽量避免在 where ⼦句中使⽤!=或<>操作符，否则将引擎放弃使⽤索引⽽进⾏全表扫描。
4.应尽量避免在 where ⼦句中使⽤ or 来连接条件，否则将导致引擎放弃使⽤索引⽽进⾏全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10union allselect id from t where num=205.in 和 not in 也要慎⽤，否则会导致全表扫描，如：select id from t where num in(1,2,3)对于连续的数值，能⽤ between 就不要⽤ in 了：select id from t where num between 1 and 36.下⾯的查询也将导致全表扫描：select id from t where name like 'abc%'若要提⾼效率，可以考虑全⽂检索。
7.如果在 where ⼦句中使⽤参数，也会导致全表扫描。
因为SQL只有在运⾏时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运⾏时；它必须在编译时进⾏选择。
然⽽，如果在编译时建⽴访问计划，变量的值还是未知的，因⽽⽆法作为索引选择的输⼊项。
如下⾯语句将进⾏全表扫描：select id from t where num=@num可以改为强制查询使⽤索引：select id from t with(index(索引名)) where num=@num8.应尽量避免在 where ⼦句中对字段进⾏表达式操作，这将导致引擎放弃使⽤索引⽽进⾏全表扫描。
SQL语句的优化方法(Hint)
WHERE A.DPT_NO=V.DPT_NO AND A.SAL>V.AVG_SAL;
193. /*+NO_MERGE(TABLE)*/
WHERE DPT_NO='TEC304' AND BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
181. /*+INDEX(TABLE INDEX_NAME)*/
表明对表选择索引的扫描方法.例如:
SELECT /*+INDEX(BSEMPMS SEX_INDEX) USE SEX_INDEX BECAUSE THERE ARE FEWMALE BSEMPMS */ FROM BSEMPMS WHERE
175. /*+FIRST_ROWS*/
表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化.例如:
SELECT /*+FIRST_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='CCBZZP';
197. /*+USE_HASH(TABLE)*/
将指定的表与其他行源通过哈希连接方式连接起来.例如:
SELECT /*+USE_HASH(BSEMPMS,BSDPTMS)*/ * FROM BSEMPMS,BSDPTMS WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
176. /*+CHOOSE*/
SQLSERVER的SQL语句优化方式小结
SQLSERVER的SQL语句优化⽅式⼩结1、SQL SERVER 2005的性能⼯具中有SQL Server Profiler和数据库引擎优化顾问，极好的东东，必须熟练使⽤。
2、查询SQL语句时打开“显⽰估计的执⾏计划”，分析每个步骤的情况3、初级做法，在CPU占⽤率⾼的时候，打开SQL Server Profiler运⾏，将跑下来的数据存到⽂件中，然后打开数据库引擎优化顾问调⽤那个⽂件进⾏分析，由SQL SERVER提供索引优化建议。
采纳它的INDEX索引优化部分。
4、但上⾯的做法经常不会跑出你所需要的，在最近的优化过程中CPU占⽤率极⾼，但根本提不出我需要的优化建议，特别是有些语句是在存储过程中并且多表联⽴。
这时就需要⽤中级做法来定位占⽤CPU⾼的语句。
5、还是运⾏SQL Server Profiler，将运⾏结果保存到某个库的新表中（随便起个名字系统会⾃⼰建）。
让它运⾏⼀段时间，然后可以⽤select top 100 * from test where textdata is not null order by duration desc这个可以选出运⾏时间长的语句，在ORDER BY 中可以替换成CPU、READS，来选出CPU占⽤时间长和读数据过多的语句。
定位出问题的语句之后就可以具体分析了。
有些语句在执⾏计划中很明显可以看出问题所在。
常见的有没有建索引或索引建⽴不合理，会出现table scan或index scan，凡是看到SCAN，就意味着会做全表或全索引扫描，这是带来的必然是读次数过多。
我们期望看到的是seek或键查找。
6、怎么看SQL语句执⾏的计划很有讲究，初学者会过于关注⾥⾯显⽰的开销⽐例，⽽实际上这个有时会误导。
我在实际优化过程中就被发现，⼀个index scan的执⾏项开销只占25%，另⼀个键查找的开销占50%，⽽键查找部分根本没有可优化的，SEEK谓词就是ID=XXX这个建⽴在主键上的查找。
Oracle之SQL语句性能优化（34条优化方法）
Oracle之SQL语句性能优化（34条优化⽅法）好多同学对sql的优化好像是知道的甚少，最近总结了以下34条仅供参考。
（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）整合简单,⽆关联的数据库访问：如果你有⼏个简单的数据库查询语句,你可以把它们整合到⼀个查询中(即使它们之间没有关系)（8）删除重复记录：最⾼效的删除重复记录⽅法 ( 因为使⽤了ROWID)例⼦：DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)FROM EMP X WHERE X.EMP_NO = E.EMP_NO);（9）⽤TRUNCATE替代DELETE：当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) ⽤来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执⾏删除命令之前的状况) ⽽当运⽤TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运⾏后,数据不能被恢复.因此很少的资源被调⽤,执⾏时间也会很短. (译者按: TRUNCATE只在删除全表适⽤,TRUNCATE是DDL不是DML)（10）尽量多使⽤COMMIT：只要有可能,在程序中尽量多使⽤COMMIT, 这样程序的性能得到提⾼,需求也会因为COMMIT所释放的资源⽽减少:COMMIT所释放的资源:a. 回滚段上⽤于恢复数据的信息.b. 被程序语句获得的锁c. redo log buffer 中的空间d. ORACLE为管理上述3种资源中的内部花费（11）⽤Where⼦句替换HAVING⼦句：避免使⽤HAVING⼦句, HAVING 只会在检索出所有记录之后才对结果集进⾏过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE⼦句限制记录的数⽬,那就能减少这⽅⾯的开销. (⾮oracle中)on、where、having这三个都可以加条件的⼦句中，on是最先执⾏，where次之，having最后，因为on是先把不符合条件的记录过滤后才进⾏统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该⽐having快点的，因为它过滤数据后才进⾏sum，在两个表联接时才⽤on的，所以在⼀个表的时候，就剩下where跟having⽐较了。
SQL语句的优化策略
SQL语句的优化：1、如果需要控制查询的记录条数，可以使用dao.query()的方法来实现，不要在sql语句中采取rownum<n的方式；2、数据库索引的建立：目前的系统中很多表没有建立必要的索引，导致查询消耗了很长时间。
随着系统的不断运行，数据量不断加大，效率会越来越低。
请建立必要的数据库索引，并注意：◆避免对索引字段进行计算操作◆避免在索引字段上使用not，<>，!=：对不等于操作符的处理会造成全表扫描，可以用“<” or “>”代替，不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。
不用“<>”或者“!=”操作符。
Where子句中出现IS NULL或者IS NOT NULL时，Oracle会停止使用索引而执行全表扫描。
◆避免在索引列上使用IS NULL和IS NOT NULL◆避免在索引列上出现数据类型转换◆避免在索引字段上使用函数；如果需要，可以建立函数索引◆避免建立索引的列中使用空值。
◆对于有连接的列“||”，最后一个连接列索引会无效。
尽量避免连接，可以分开连接或者使用不作用在列上的函数替代。
3、部分UPDATE、SELECT 语句写得很复杂（经常嵌套多级子查询），可以考虑适当拆成几步进行处理；4、update：同一个表的修改在一个过程里出现好几十次，如：update table1set col1=...where col2=...;update table1set col1=...where col2=.........，象这类脚本其实可以很简单就整合在一个UPDATE语句来完成。
5、在可以使用UNION ALL的语句里，使用了UNION：UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。
一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。
还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用UNION ALL。
SQL数据库怎么进行优化_SQL数据库有什么优化方式
SQL数据库怎么进行优化_SQL数据库有什么优化方式优化SQLServer数据库的一些经验和注意事项，详细介绍了SQL 语句优化的基本原则，包括索引、查询和游标的使用等。
下面由店铺为大家整理的SQL数据库优化方式，希望大家喜欢!SQL数据库优化的方式1. 利用表分区分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。
这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。
对数据量大的时时表可采取此方法。
可按月自动建表分区。
2. 别名的使用别名是大型数据库的应用技巧，就是表名、列名在查询中以一个字母为别名，查询速度要比建连接表快1.5倍。
3. 索引Index的优化设计索引可以大大加快数据库的查询速度。
但是并不是所有的表都需要建立索引，只针对大数据量的表建立索引就好。
缺点：1.创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
2.索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
3.当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引需要维护：为了维护系统性能，索引在创建之后，由于频繁地对数据进行增加、删除、修改等操作使得索引页发生碎块，因此，必须对索引进行维护。
4. 物化视图(索引视图)一般的视图是虚拟的，而物化视图是实实在在的数据区域，是要占据存储空间的，另外系统刷新物化视图也需要耗费一定的资源，但是它却换来了效率和灵活性。
索引视图更适合在OLAP(读取较多，更新较少)的数据库中使用，不适合在OLTP(记录即时的增、删、改、查)的数据库中使用。
物化视图的注意事项：1.对于复杂而高消耗的查询，如果使用频繁，应建成物化视图。
sql优化面试题
sql优化面试题在数据库开发和管理的过程中，SQL优化是一个重要的环节。
无论是在开发业务系统还是进行数据分析，SQL查询的性能优化都能够提高查询速度和系统的响应能力。
以下是一些常见的SQL优化面试题，帮助你更好地理解和应对SQL优化问题。
1. 什么是SQL优化，为什么需要进行SQL优化？SQL优化是指通过调整SQL查询的结构或者使用合理的技术手段，提高SQL查询的效率和性能。
SQL优化的主要目的是减少查询时间和资源消耗，进而提升系统的响应速度和用户体验。
需要进行SQL优化的主要原因有以下几点：- 数据库中的数据量增大，导致查询性能下降；- 数据库设计不合理，导致查询需要进行大量的表连接操作；- 查询语句写法不规范，造成性能浪费；- 数据库索引失效，导致查询效率低下；- 数据库服务器硬件性能限制。
2. SQL查询中常见的性能问题有哪些？在进行SQL优化时，我们需要关注一些常见的性能问题，包括：- 数据库查询语句中避免使用“*”通配符，应该明确指定需要查询的字段；- 避免在WHERE子句中使用函数操作，可以将函数操作移至其他地方，避免对每一条记录都进行函数计算；- 避免在WHERE子句中使用!=或<>操作符，这些操作符无法使用索引，会导致全表扫描；- 避免使用OR操作符，尽量使用UNION操作来替代；- 避免在索引列上使用函数操作，会导致索引失效；- 避免频繁的表连接操作，可以考虑使用子查询或者临时表等方式进行优化。
3. 如何对SQL语句进行优化？SQL查询的优化方法有很多种，根据实际情况选择合适的方法才能发挥最大的优化效果。
以下是一些常见的优化方法：- 添加索引：对查询频繁的列或者经常进行排序和分组的列添加索引，加快查询速度；- 正确使用JOIN：合理选择JOIN语句的类型，尽量减少JOIN操作；- 使用EXPLAIN语句：通过执行EXPLAIN语句来分析SQL查询的执行计划，找出可能存在的性能问题；- 优化WHERE子句：合理利用索引和函数，避免全表扫描和函数计算；- 避免使用子查询：将复杂的子查询优化为JOIN或者其他方式；- 提取重复的子查询：将重复的子查询提取出来，作为一个独立的查询；- 避免大数据量的排序和分组：尽量减少排序和分组操作的数据量，或者对查询结果进行缓存。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
背景：OLTP系统，ORACLE10G
1-1
目录
1 2 3 4 5 6 为什么要调优SQL? 哪些SQL需要调优? 如何获取需要调优的SQL? 如何手工调优SQL? 另外一些调优方法和工具。 11G在执行计划上的一些改进。
1-2
为什么要调优SQL？
通常来讲，要打造高效快捷的应用系统，需要从最初的业务需求 入手，在分析、整理出闭环的业务操作流程后，按照范式的要求，尽 量用简单的数据结构，来实现业务的运行和流转（可以考虑对基础数 据作少量的数据冗余，以减少关联）；同时，根据业务的需求，兼考 虑对历史业务数据的迁移，只保留最近一段时期内的数据，以便让系 统轻装运行。 但是，由于业务的复杂性，设计人员的知识、视野、前瞻性等的 局限，在系统结构设计时，难以考虑周全；并且，由于开发人员的 水平参差不齐，编写的代码也存在缺陷。经统计评估，排除系统结构 设计不善导致的因素外，新的应用系统，有80%的效率问题，是因为 低效的SQL导致，这就需要DBA找出这些低效的SQL，加以优化。
1-13
SQL 语句的调优原则
在一个OLTP系统里，优化SQL语句的原则，就是尽量 减少数据的读取。调优的目的，实际是设法让语句在执行过 程中，尽可能地只读取必要的数据，不读或尽量少读不符合 要求的数据。
1-14
SQL调优中的一些常识
执行计划中涉及的一些概念
* 不论SQL中读取多少个表，在执行过程中，每次都是两个表/结 果集操作，得到新的结果后，再和下一个表/结果集操作，，， 直到结束。 在一个多表关联的执行计划中，必须包括这3要素： * 表/对象/数据集的读取顺序（ join order ）。 * 数据的读取方法（ access path ）。 * 表/数据的关联方法（join method）。 这3个要素是判断执行计划优秀与否的关键。 * 可选择性(Selectivity) ，>=0 and <=1。 * 预估记录数(Cardinality) ，表/视图/操作后的结果集。 * 开销(Cost) ，CBO选择最佳执行计划的标准：越低越好。
* 当前库， 根据V$ST_CALL_ET，找到运行时间 最长的进程，获取SQL_ID，再找出SQL语句和执行计划。
1-7
AWR上要关注的SQL项
1-8
如何手工调优SQL?
A 如何获取语句的执行计划？ B 如何解读执行计划中的执行顺序？ C SQL语句的调优原则。 D 一些调优常识。 E 手工调优的粗略思路。 F 10046事件的使用方法。 G 两个案例。
alter session set events 'immediate trace name treedump level 33632';
1-28
常用的HINT
1 2 3 4 All_rows, First_rows_n – Optimization Goals Leading, Ordered -- Join orders Full, Index, No_index --Access path Use_hash, Use_nl, Use_merge, Use_nl_with_index – Join method Append, Push_pred, Push_subq, Qb_name, Dynamic_sampling(X) , Gather_plan_statistics No_expand, Opt_param(‘optimizer_ind_ex_adj’,10), Cardinality(alias 200), swap_join_inputs(), No_merge, Hash_Aj, Hash_SJ
哈希连接
适用等于条件下，大数据量的关联产生大结果集。
排序合并连接
排序合并连接适用于两个已经按照关联字段排序后的结果集间的关联，尤其对大数据量 需要不全等于（>, >=,<, <=）操作的情况下，效率要比NL好。
笛卡尔连接(Cartesian Joins)
1-21
OPTIMIZER_INDEX_COST_ADJ: （1 to 10000）
1-26
改为 exists后的 cost
1-27
索引
1 2 确保唯一性（唯一性索引）。 加快数据查询。
1 B树索引。 升序，降序，反向。 2 位图索引。 3 位图连接索引。 4 函数索引。 5 应用域索引。 提示： 可dump出 索引的结构，来加强对索引结构的了解，注： 33632 为索引的 Object_id:
1-30
善用分区
到11GR2为止，ORACLE提供的分区类型
分区类型
范围分区 列表分区 哈希分区 引用分区 间隔分区 虚拟列分区 系统分区 完全组合分区 没有分区键，数据被插入时，需要指定存放的分区。 范围，哈希，列表等3种分区的完全二维组合。
特点
常用在业务数据表，适应于时间或可量度数值等可用来分割数据的情况。 常用在地址，编码等较少量固定数值的情况。 按照哈希算法分布存放数据，只能用于等价查询条件，最佳分区数为2的N次幂。 主键在某一分区集，对应的从键也集中存放在某一分区集。
OPTIMIZER_INDEX_CACHING：（0 to 100）
表示数据缓冲区中，缓存着的索引的数量。此值越大，意味着缓冲区中，缓存的 索引块越多，这对于使用索引作嵌套循环的代价越低，此时CBO将更加偏向走 嵌套循环连接，而非哈希或排序连接。
1-22
IN 和 EXISTS适用的场景
在一个带子查询的语句中，通常来讲，若主语句上的约 束条件强(返回记录数少)，则适合使用EXISTS；若是子查询 语句上的约束条件强，则适用 IN。 这一点符合我在“手工调优的粗略思路”章节中，提 到的思路：CBO尽可能从过滤性最强的条件入手。
1-3
例子
1-4
1-5
哪些SQL需要优化？
•
运行时间较长的SQL。
• 逻辑读较高的SQL。
• 物理读较高的SQL。
1-6
从哪里获取需要调优的SQL？
* AWR(ASH,ADDM)， 1 Elapsed Time(含CPU较高者) 2 Buffer Gets 3 Physical Reads
* EM， 性能分析--> SQL Tuning
1-23
例子
O.CUSTOMER_ID=144是最强的过滤条件，在这种 条件下，语句适合用IN写法，但语句使用了Exists
注意执行计划中 的Cost
1-24
改用IN写法后， COST大大降低
1-25
过滤条件e.department_id=80 在主语句上， 此时应用 exist, 但语句用了IN，看看其 cost
1-18
7 若觉得计划中的预估值与手工计算的结果相差太大，可以先对SQL中涉及到 的表作统计，或者，有针对性对约束条件中的字段/索引作统计。在这过程 中，分析数据的分布属性，可考虑建索引，建分区等方法，尽 量让执行计 划只读取必要的数据。 8 在上述各环节的判断过程中，可使用10046事件跟踪部分SQL的执行过程中 的运行效率，判断是否合理。还可使用HINT来改变执行计划中，表/结果集 的读取顺序，关联方法，数据的读取方法等。对比不同执行计划的效率，分 析原因，再调整改进，包括改写成等效的SQL。 9 必要时，可以考虑对不清晰，不符合判断的部分SQL作10053事件分析。 10 对于由多个动态视图组成的复杂的语句，若发觉整个语句效率比拆分执行 的总的耗时要多，可以先单独拆分找出各个视图的最佳执行计划，之后设 法确保整个语句按照拆分时各个模块的执行计划执行。 以上是我分析SQL语句的执行计划时的大致思路，现实中的情况千变万化 ，可能与上面的思路稍有不同，但大体都是这样，都是从最强条件入手，再往 外扩展/关联与上一步有关系对象。实际分析中，没有我上述描述的那么复杂， DBA根据语句的约束条件，对比分析CBO给出的执行计划，大体一眼能找出计 划中的疑点，再加以计算分析比较，即可找出问题的结症。
用来给DBA人为对索引访问的开销作比例设定。缺省值100 ，表示默认情况下， Cbo将按照正常情况下计算出来的索引访问开销和全表扫描的开销来比较。 DBA 调整此值后，CBO将这样计算索引访问的开销：正常情况下计算出来的Cost * Optimizer_index_cost_adj。此值越小，则表示索引的开销越小，Cbo将越倾 向于走索引；超过100，越大，Cbo将越倾向于走全表扫描。
如何快速获取语句所涉及到的表？
1 2 将语句创建成一视图。 通过user_dependencies 视图，查询与此视图相关的表。
1-20
4种关联方式和两个参数
嵌套连接
Nest Loops outer table inner table – 对于从outer table 出来的每一条记录，都要在inner table 里过滤一遍。 适用于小表间返回较少的结果集，并且有好的关联关系。
1-9
如何获取语句的执行计划？
1 直接解析SQL语句. Explain plan for XXX； Select * from table(dbms_xplan.display); 根据SQL_ID查询， select * from table (dbms_xplan.display_cursor('&sql_id',0, 'allstats last')); 还有：'advanced','typical','serial','basic‘. v$session.sql_child_number=0,1,,, 从视图v$sql_plan 中获取。
5
1-29
善用分区
分区，实际上是ORACLE提供的多种视角，让用户根据不同性质的 数据，去分组分割存放数据的方法。 正常情况下，系统设计人员/DBA应该了解清楚各类型分区的特点， 系统设计时，根据业务的运行需求，结合各种分区特性，事先规划设计 好将来业务数据存储方案，并将此思想和系统开发人员充分沟通，以便 开发人员在编写程序时，利用好这些分区属特性，编写出高效SQL。