下载文档原格式
db2数据库优化方案随着企业数据量的不断增加，数据库的性能优化变得越来越重要。
在众多数据库中，DB2是一款功能强大的关系型数据库管理系统。
本文将为您介绍一些针对DB2数据库的优化方案，以提高数据库的性能和效率。
一、合理设计数据库结构良好的数据库设计是优化数据库性能的基础。
以下是一些设计数据库结构的准则：1. 使用适当的数据类型：根据数据的特性选择适当的数据类型，减小存储空间的占用，提高查询和更新速度。
2. 设计有效的主键和外键：将主键和外键应用到表的关键字段上，以确保数据的完整性和一致性，并加速查询操作。
二、合理设置数据库参数通过调整数据库参数，可以改善DB2的性能表现。
以下是一些常用的数据库参数设置建议：1. 缓冲池设置：调整缓冲池的大小，使得主要用于查询的表和索引可以被缓存，减少磁盘I/O操作。
2. 日志设置：根据业务需求设置日志的大小和数量，以平衡事务处理的性能和数据恢复的能力。
3. 并发设置：根据并发操作的需求和服务器硬件性能合理设置并发连接数和锁定策略，以提高系统的并发处理能力。
三、优化查询语句优化查询语句可以提高DB2数据库的性能和响应时间。
以下是一些优化查询语句的建议：1. 使用索引：根据查询的字段和条件创建适当的索引，加快查询速度。
2. 正确使用JOIN操作：避免使用不必要的JOIN操作，优化表之间的关联关系，减少查询的复杂性。
3. 避免全表扫描：尽量避免使用SELECT *的方式查询数据，只选择需要的字段，减少数据库的负载。
四、定期维护数据库定期维护数据库可以确保数据库的正常运行和优化性能。
以下是一些数据库维护的建议：1. 优化表和索引：根据数据库的使用情况定期重新组织表和索引，保持数据的连续性和最佳性能。
2. 清理无用数据：定期删除或归档不再使用的数据，减少数据库的存储空间占用。
3. 备份和恢复策略：制定完备的数据库备份和恢复策略，以防止数据丢失和灾难恢复。
五、硬件优化优化数据库的硬件环境可以提高系统的性能和可靠性。
内存配置优化a) 缓冲池（Buffer Pool）增加缓冲池大小以减少磁盘I/O：sql代码：ALTER BUFFERPOOL IBMDEFAULTBP SIZE 250000为不同的表空间创建专用缓冲池：sql代码：CREATE BUFFERPOOL BP_USERDATA SIZE 100000 PAGESIZE 32K b) 排序堆（Sort Heap）调整SORTHEAP参数：sql代码：UPDATE DB CFG FOR database_name USING SORTHEAP 1024 c) 包缓存（Package Cache）增加PCKCACHESz参数：sql代码：UPDATE DB CFG FOR database_name USING PCKCACHESz 640 I/O 优化a) 预读（Prefetch）调整PREFETCHSIZE参数：sql代码：UPDATE DB CFG FOR database_name USING PREFETCHSIZE 32 b) 异步I/O启用DFTDBHEAP参数：sql代码：UPDATE DB CFG FOR database_name USING DFTDBHEAP AUTOMATIC日志配置a) 日志缓冲区增加LOGBUFSZ参数：sql代码：UPDATE DB CFG FOR database_name USING LOGBUFSZ 1024 b) 日志文件大小调整LOGFILSIZ参数：sql代码：UPDATE DB CFG FOR database_name USING LOGFILSIZ 16384 锁管理a) 最大锁数增加MAXLOCKS参数：sql代码：UPDATE DB CFG FOR database_name USING MAXLOCKS 20 b) 锁列表大小调整LOCKLIST参数：sql代码：UPDATE DB CFG FOR database_name USING LOCKLIST 8192 并发控制a) 最大应用程序数增加MAXAPPLS参数：sql代码：UPDATE DB CFG FOR database_name USING MAXAPPLS 400 b) 代理数调整NUM_POOLAGENTS参数：sql代码：UPDATE DBM CFG USING NUM_POOLAGENTS 100统计信息收集a) 自动统计信息收集启用AUTO_RUNSTATS：sql代码：UPDATE DB CFG FOR database_name USING AUTO_RUNSTATS ON b) 统计信息采样调整统计信息采样率：sql代码：UPDATE DB CFG FOR database_name USING AUTO_SAMPLING YES 查询优化器a) 优化级别设置OPTLEVEL参数：sql代码：UPDATE DB CFG FOR database_name USING OPTLEVEL 5表空间管理a) 自动存储启用自动存储：sql代码：CREATE TABLESPACE ts_name MANAGED BY AUTOMATIC STORAGE b) 表空间扩展设置自动扩展：sql代码：ALTER TABLESPACE ts_name AUTORESIZE YES索引优化a) 索引重组定期重组索引：sql代码：REORG INDEXES ALL FOR TABLE table_name分区表对大表使用分区：sql代码：CREATE TABLE table_name (...) PARTITION BY RANGE(column_name) (...)压缩启用表压缩：sql代码：ALTER TABLE table_name COMPRESS YES并行度调整INTRA_PARALLEL参数：sql代码：UPDATE DB CFG FOR database_name USING INTRA_PARALLEL YES 监控和诊断a) 启用活动监控：sql代码：UPDATE DBM CFG USING DFT_MON_BUFPOOL ONUPDATE DBM CFG USING DFT_MON_LOCK ONUPDATE DBM CFG USING DFT_MON_SORT ONUPDATE DBM CFG USING DFT_MON_STMT ONb) 使用db2top工具实时监控性能c) 定期检查db2diag.log文件。
DB2数据库优化策略当涉及到DB2数据库优化时，具体的案例取决于数据库的具体情况和性能问题。
请注意，这些只是一些常见的DB2优化案例和步骤。
具体的优化策略取决于您的特定情况和需求。
在进行任何优化之前，建议先进行充分的需求分析和性能测试，以确保所选的优化策略能够真正解决您的问题并带来显著的性能提升。
一．索引优化：识别慢查询：首先，通过慢查询日志或性能监控工具识别慢查询。
分析查询：查看查询的执行计划，确定是否可以利用索引加速查询。
创建或优化索引：如果发现缺少必要的索引，创建索引；如果存在冗余或低效的索引，则进行优化或删除。
二．查询优化：重写复杂查询：将复杂的联接和子查询重写为更高效的查询方式，例如使用JOIN替代子查询。
使用合适的函数：避免在查询中使用复杂的函数，这可能会影响索引的使用和查询性能。
三．数据库设计优化：规范化：确保数据库表结构经过规范化，以减少数据冗余和潜在的更新、插入和删除异常。
反规范化：在适当的情况下，通过反规范化来提高查询性能，减少数据检索的复杂性。
四．硬件和配置优化：增加内存：提高数据库缓冲池的大小，以便数据库可以缓存更多的数据和索引。
使用更快的存储：选择高性能的硬盘或使用SSD来提高I/O性能。
调整数据库配置参数：根据数据库的工作负载和硬件资源，调整数据库的配置参数，如缓冲池大小、线程数等。
五．监控和调优：定期监控数据库性能：使用性能监控工具定期检查数据库的性能指标，如CPU利用率、磁盘I/O、查询响应时间等。
调整优化策略：根据监控结果，定期评估和调整优化策略，以保持数据库的最佳性能。
六．并发和负载管理：资源争用管理：分析并解决多个用户或应用程序之间的资源争用问题，确保数据库资源得到合理分配。
分区：使用分区技术将大型表和索引分成较小的、更易于管理的片段，以提高管理和查询性能。
七．定期维护：数据库维护：定期进行数据库维护，如重建索引、清理旧数据、更新统计信息等，以保持数据库性能和效率。
DB2之SQL优化浅析DB2是IBM公司开发的关系型数据库管理系统，被广泛应用于企业级应用系统。
在进行大规模数据操作时，如何优化SQL语句是提高数据库性能的关键。
下面是DB2中SQL优化的一些浅析。
1.使用索引：索引是数据库中提高查询效率的重要手段。
在DB2中，可以通过创建适当的索引来提高SQL查询的性能。
一般来说，选择性高的列（即数据有很强的唯一性）更适合作为索引列。
同时，对于查询频繁的列也应该考虑创建索引。
2.避免全表扫描：在编写SQL语句时，应该尽量避免全表扫描，因为全表扫描会消耗大量的系统资源，导致查询效率低下。
可以通过优化查询条件、使用索引、分区表等方式来避免全表扫描。
3.避免过多的连接操作：在编写SQL语句时，应尽量避免过多的连接操作，因为连接操作会消耗大量的CPU和内存资源。
可以通过合理设计表结构、使用子查询等方式来减少连接操作。
4.合理使用绑定变量：绑定变量是一种优化SQL查询的技术。
当执行一条SQL语句时，DB2会将绑定变量的值传递给查询引擎，查询引擎会使用这些值来生成执行计划。
通过使用绑定变量，可以减少SQL执行计划的重新生成，提高查询性能。
5.避免使用SELECT*：在查询数据时，应尽量避免使用SELECT*，因为SELECT*会返回所有列的数据，增加了网络传输的开销，并且可能会返回一些不需要的数据。
应该明确指定需要查询的列，尽量减少返回的数据量。
6.使用批量操作：在进行大规模数据插入、更新、删除等操作时，应该尽量使用批量操作，而不是逐条操作。
通过批量操作，可以减少与数据库的交互次数，提高操作性能。
7.优化查询计划：在DB2中，查询引擎会根据查询语句生成查询计划，执行查询操作。
查询计划的选择对查询性能有重要影响。
可以通过使用HINT语句、分析查询计划等方式来优化查询计划，提高查询性能。
8.定期收集统计信息：DB2中的统计信息用来描述表中数据的分布情况，是优化查询性能的重要依据。
DB2数据库性能优化
一、建立索引
（1）添加新索引
在DB2中，可以使用CREATEINDEX命令来建立索引。
通过添加索引来提高SQL语句的执行效率。
建议在经常使用的字段上建立索引，例如，WHERE子句中的字段，GROUPBY子句中的字段，ORDERBY子句中的字段或者连接条件中的字段。
（2）更新索引
如果表中的数据经常发生变化，则建议定期更新索引。
DB2有一项特殊的REORG操作，可以重新建立表中的索引，以提高查询效率。
（3）复合索引
在DB2中，可以使用复合索引来建立索引，以便提高查询效率。
复合索引可以使用多个字段，比普通索引更有效地提高查询速度。
二、查询优化
（1）使用合适的连接方式
（2）使用合适的排序方式
（3）使用子查询
（4）尽量少使用通配符
（5）尽量少使用函数
（6）查询中使用表别名
（7）使用EXISTS和NOTEXISTS
（8）使用适当的索引
三、周期性维护
（1）定期检查磁盘空间
（2）定期检查表和索引
（3）定期更新统计信息
（4）定期重新排序和重新组织表
（5）定期检查死锁
四、构造良好的数据模型
（1）正确定义数据字段
（2）使用算法优化数据存储
（3）及时删除无用的数据
（4）构造适当的表结构
五、其他
（1）设置合理的日志文件。
DB2之SQL优化浅析SQL优化是DB2数据库性能调优的重要环节，它能有效提升数据库查询效率，提高系统的响应速度。
本文将对DB2中的SQL优化进行浅析。
1.索引优化索引是加快数据库查询速度的关键因素之一、在进行SQL优化时，首先要考虑的是是否有适当的索引。
索引可以加快查询的速度，但过多的索引会降低插入和更新的性能。
因此，需要根据具体的业务需求和数据访问模式来选择适当的索引。
可以使用DB2的Explain工具对SQL查询语句进行分析，提供最佳的索引策略。
2.谓词下推谓词下推是指将过滤条件尽早地应用到表中，减少待处理的数据量。
在编写SQL语句时，应尽量将过滤条件写在WHERE子句中，并使用AND、OR等运算符将多个条件连接起来，避免使用临时表或视图进行数据过滤。
此外，还可以使用DB2的统计信息来了解表的数据分布情况，从而更好地选择合适的过滤条件。
3.使用合适的连接方式在对多个表进行关联查询时，应选择合适的连接方式。
DB2提供了多种连接方式，如INNERJOIN、LEFTJOIN、RIGHTJOIN等。
根据具体的业务需求和数据分布情况，选择合适的连接方式可以显著提高查询性能。
此外，还可以使用子查询或临时表来优化多表关联查询。
4.避免全表扫描全表扫描是指对整个表进行遍历，需要较长的时间和大量的系统资源。
在进行SQL优化时，应尽量避免全表扫描。
可以通过合理的索引设计和谓词下推来避免全表扫描，从而提高查询性能。
5.优化聚合和排序操作聚合操作（如SUM、COUNT、AVG等）和排序操作是常见的数据库查询操作，其效率对系统性能影响较大。
为了优化这些操作，可以使用合适的聚合函数和排序字段，避免不必要的数据计算和排序操作。
另外，还可以使用分区表或分区索引来加快聚合和排序操作的速度。
6.优化SQL语句的执行计划DB2会根据查询语句自动生成执行计划，选择最佳的查询策略。
为了优化执行计划，可以使用DB2的Explain工具来分析查询语句，了解执行计划的选择和执行代价。
序言SQL 语言是一种强大而且灵活的语言，在使用 SQL 语言来执行某个关系查询的时候，用户可以写出很多不同的 SQL 语句来获取相同的结果。
也就是说，语法(syntactical) 不同的 SQL 语句，有可能在语义 (semantical) 上是完全相同的。
但是尽管这些 SQL 语句最后都能返回同样的查询结果，它们在 DB2 中执行所需要的时间却有可能差别很大。
这是为什么？众所周知，DB2 数据库具有强大的功能，可以自动地把用户输入的 SQL 语句改写为多个语义相同的形式并从中选取一个耗时最少的语句来执行。
但是 DB2 并不能够永远对所有的 SQL 语句都成功的改写来取得最优的执行方案。
其中一个方面的原因就是数据库应用程序的开发人员在写 SQL 语句的时候有一些习惯性的“小问题”，而正是这些小问题带来了 SQL 语句运行时性能上的大问题。
正如平时所说“条条大路通罗马”，但是并非所有通往罗马的路都是坦途，我们应该找到那条最有效的道路。
回页首编写高效 SQL 语句的一些最佳实践这里我们将介绍在编写 SQL 语句时可能影响 DB2 查询性能的一些常见问题，并给出相应的编写高效 SQL 语句的最佳实践（best-practices）。
避免不恰当的使用“SELECT *”像“SELECT *”这样的写法在用户使用中可能很常见，它表示把满足查询条件的每一条记录（Row）的所有列都返回。
但是有时候这种用法很可能导致数据库查询时候的性能问题。
假定 Sale 是一个包括 25 个列（column）的表，那么下面这条查询语句就有可能在执行时性能较差，其中一部分原因就是在 SELECT 中使用了"*".SELECT *FROM Sales WHERE YEAR(Date) > 2004 AND Amount > 1000如果 SQL 语句使用了“SELECT *”，DB2 就需要把表的所有列都从外部存储介质上（如磁带或者硬盘）复制到 DB2 的内存中来进行处理并且返回给用户，这显然会增加 I/O 和 CPU 的开销。
db2锁超时解决方案DB2是一种流行的关系型数据库管理系统，但在使用过程中，可能会遇到锁超时的问题。
锁超时是指当一个事务请求获取资源的锁时，如果等待的时间超过了设定的阈值，系统会自动放弃获取锁的请求，以避免长时间的阻塞。
本文将介绍一些常见的DB2锁超时解决方案。
1. 优化SQL语句：锁超时通常是由于事务对数据库资源的锁定时间过长导致的。
因此，首先要考虑优化SQL语句，减少事务对资源的锁定时间。
可以通过以下几个方面来优化SQL语句：- 确保只锁定必要的数据行，尽量避免对整个表进行锁定。
- 合理使用索引，以提高查询效率，减少锁定时间。
- 在事务中尽早释放不再需要的资源锁定，避免长时间占用。
2. 调整锁超时参数：DB2提供了一些参数用于调整锁超时的行为。
可以通过调整这些参数来解决锁超时问题。
常用的参数包括：- LOCKTIMEOUT：该参数指定了事务在等待锁的时间超过设定值后，是否放弃锁定请求。
可以通过增加该参数的值来延长锁超时时间。
- DEADLOCK_TIMEOUT：该参数指定了在发生死锁时，系统等待的时间。
可以通过增加该参数的值来延长等待时间，以便系统有更多的时间解决死锁问题。
- LOCKLIST：该参数指定了数据库管理系统为锁定分配的内存量。
可以通过增加该参数的值来提高系统处理锁定的能力。
3. 使用乐观锁机制：乐观锁是一种乐观的思想，即默认认为事务之间不会发生冲突，只有在提交事务时才会检查是否发生了冲突。
使用乐观锁机制可以减少锁超时的概率，提高并发性能。
常用的乐观锁实现方式包括版本控制和时间戳控制。
4. 分析锁超时日志：DB2提供了日志记录锁超时的功能，通过分析这些日志可以了解导致锁超时的原因。
可以通过查看日志中的锁超时事件、事务和资源信息，找出导致锁超时的具体原因，从而有针对性地解决问题。
5. 适当调整事务隔离级别：事务隔离级别可以控制事务对资源的锁定程度。
不同的隔离级别对锁超时的概率有影响。
DB2 Sql优化与锁本次差旅性能测试，80%性能的提升在于Sql和索引的修改。
总结有以下几点：1）不高效的sql（不合理的sql）2）不合理的索引（如何建立合理的索引）3）避免死锁和大量锁等待下面针对这3个方面总结下要点。
1.编写高效的S QL注意要点1.1 表连接表连接有两个要点：1）表连接顺序2）连接条件Sql_stmt_1:Select * from A left join B on A.id=B.id join C on B.id = C.C_id where A.con=‟ ‟ and B.c on=‟ ‟一般情况下，DB2会根据各表的JOIN顺序自顶向下处理，即从Sql来看，就是自左向右解析,先A、B做连接操作，之后会产生结果集，将会写入内存，如果内存不够，会写入临时表空间，之后会用结果集和C做连接操作。
如果sql中只有两表连接，那么其前后顺序没什么关系，优化器会自己去评估。
而如果sql中存在超过2个表连接时，那么表连接就会有顺序之分。
那么，原则是：如果sql中存在表A、B、C三表连接，则首先应保证最先连接的两表具有较小的子集。
在进行表连接时，需要提供连接字段（即On语法后的等价谓词，on A.id=B.id）。
此时，我们需要保证，连接字段存在索引。
这样当结果集小时，会走NestJoin（速度快，因为会利用到索引），当结果集大时，会走Hash join。
此外，在对A、B表进行连接时，优化器需要判断采用何种连接类型，这时会先执行where 字句后的条件。
也就是说，如果where字句能过滤很多的条件，那么表连接的结果集就会很小，cost自然会降低，所以适当为where字句的查询字段建立索引，能够得到更好的性能。
原则是：在进行表连接时，为连接字段和查询过滤字段（where 字句后的条件）建立索引，会得到很好的性能提升。
在本次测试中，发现有的sql会在表连接时，为其指定多个连接条件，形如：SELECT B.APPROVE_STATUS, count ( * ) AS NUMFROM BIZ.WF_TASK CLEFT JOINBIZ.REI_FORM BON C.RECEIPT_NO = B.REI_FORM_IDWHERE C.TASK_STATUS ='01'AND C.HANDLE_ID ='1234560000102'AND (C.RECEIPT_TYPE ='02'OR C.RECEIPT_TYPE ='03')GROUP BY B.APPROVE_STATUSWITH UR执行cost：如果sql写成（增加一个表连接字段）：SELECT B.APPROVE_STATUS, count ( * ) AS NUMFROM BIZ.WF_TASK CLEFT JOINBIZ.REI_FORM BON C.RECEIPT_NO = B.REI_FORM_IDAND (C.RECEIPT_TYPE ='02'OR C.RECEIPT_TYPE ='03')WHERE C.TASK_STATUS ='01'AND C.HANDLE_ID ='1234560000102'GROUP BY B.APPROVE_STATUSWITH UR对比结果，我们可以看到，当连接条件存在多个时，cost会高很多，因为多做了一次表连接。
如果是小表，看不出差别，如果是大表关联，则结果很明显。
原则是：当进行表连接时，请确保连接条件只有一个，尤其是大表连接。
1.2 合理使用Not in 和Not Exists虽然Not in 和Not exits 可以实现相同的功能，但是两者本身的实现方式不同：Not In：是自内向外操作，即先得到子查询结果，然后执行外层查询。
包含not in 子句的执行顺序是：首先取外部一个查询结果与内部子集比较，不管是否存在，它都要遍历整个子集，往往无法利用到索引，因而是由内向外过程。
所以，当内部查询子集很大时，就会具有较高的查询代价。
Not Exists：恰恰相反，是外向内操作。
即先执行外部查询结果，然后再执行内部操作，是集合操作。
包含not exists子句的执行顺序是：首先取外部一个查询结果与内部子集比较，若存在即刻返回，而不需要便利整个子集，如果存在索引，就会使用索引，因而是个自外而内的过程。
所以，当内部子集很大时，相对来说，性能要优于Not in。
因而，总的来说，Not exits在整体性能上要由于Not in。
原则是：当子查询结果集较大时，Not exists 较 Not in 具有较高的性能提升；当子查询结果集较小时（个数或者百数以内），两者相差不多，一般来说，此时Not in 会教优于Not exists。
就好像表数据小时，全表扫描总是要由于索引扫描；当子查询具有一定的复杂度时（即sql关联关系较多，如子查询句中包含多个表查询），由于内部查询的复杂度，会导致Not exists 查询具有较大的复杂度，降低性能。
此时可以考虑采用Not in。
IN与Exists两者相差不多，这里不做比较，思路形同。
1.3 改写OR和不等于（！=||<>）我们在编写sql时，通常都会按照程序逻辑去写，此时，当我们遇到如下场景：我要查询企业员工表（employee）中的员工状态为实习(type=‟01‟)或者兼职的所有员工(type=‟08‟)，假设状态共有10种此时，我们立马会写如下Sql：Select * from employee A where A.type=‟01‟ or A.type=‟08‟或者select * from employee where type in (…01‟…08‟)我们假设，在type列上存在索引。
而此Sql含有or运算，对于优化器来说，因为无法运用到一个范围，所以无法利用索引扫描。
而通常此种情况需要遍历所有记录或者所有索引。
这样会明显提高查询cost。
我们希望是通过索引的方式，毕竟该表是个大表，如果出现大表扫描，多系统性能有很大的影响。
那么可以采取用UNION改写OR子句，如下：Select * from employee A where A.type=‟01‟unionSelect * from employee A where A.type=‟02改写成上述sql，优化器会分别执行两个查询子集，然后union合并。
这样就可以利用到索引（type=‘01’）。
当然Union包含去除重复元素的功能，即相当于distinct，这样就会有排序存在，如果业务场景允许，可以考虑使用union all，它和union不同的是，它无需排序去重，只需要两个子集合并即刻。
效率要高于union。
原则是：当存在大表链接且连接条件较多，并且连接条件包含Or子句时，建议使用Union/Union all来替换。
对于不等与来说也是类似，不等于在逻辑上其实是类似于Not 的概念。
如，对如下sql:Sql_stmt_2:Select * from employee where type !=‟01‟所以我们可以有如下改写方式：1)将<>改写为Not in操作，即Select * from employee where type not in (…01‟)2)select * from employee where type>‟01‟ and type<‟01‟3)将<>改写为大于和小于的结合Select * from employee where type >‟01‟ unionSelect * from employee where type <‟01‟(当然如果你知道一个大于已经足够，那么完全可以省略掉小于的操作，这就是分析sql的业务场景)显然，对于1）的改法，它适用与Not in 子集中有多个值的情况；对于2）改法，要要由于1），因为它可以利用到Type列上的索引。
原则是：当存在大表链接且连接条件较多，并且连接条件包含不等于（<>||!=）子句时，建议使用Union/Union all 联合大于小于操作来替换。
1.4 缩小结果集来提高查询效率DB2优化器其实本身会自动根据where 字句后的条件来缩小结果集，形如简单的Select * from A,B where A.id=B.id and A.type=3 and b.type =4DB2会自动改写该Sql，先根据Where字句后的谓词条件，将结果集缩小，然后再进行表连接。
但是有时候，DB2无法自动做这事。
这时候可以先用Sql缩小结果集来达到效果。
将查询结果作为子查询，主要是为了减少扫描的数据量，以及利用索引进行数据检索。
尤其是针对大表来说。
它的特点就是，在进行查询之前，先用子查询将结果集过滤到最小，并且通常这时候的过滤谓词是存在索引的。
假设如下情况：索引：biz.xx_test on biz.rei_busi_apply(start_date)biz.prmary_key on inst1.history(busi_apply_id)查询：select a.apply_user_name from biz.rei_busi_apply a,biz.rei_busi_apply_detail b where a.busi_apply_id = b.busi_apply_id and a.start_date > current timestamp - 30 days or b.seq >2;上面的查询用于查询一个月前的出差单或者出差地大于2个的单据。
由于存在Or条件，且Or 字段SEQ 不存在索引，即使start_date上存在索引，也无法利用索引。
那么办法就是，想办法构造一个子查询，让它属于一个部分，先执行。
那么改写成如下方式，可以奏效：with tmp as ( select a.busi_apply_id from biz.rei_busi_apply a where a.start_date > current timestamp - 100 days) select a.apply_user_name from biz.rei_busi_apply a,biz.rei_busi_apply_detail b where a.busi_apply_id in ( select busi_apply_id from tmp) and b.seq >2;这样改写以后，子查询结果tmp就会走索引biz.xx_test，并且会过滤掉表rei_busi_apply 一定的结果。
