业务case-测试联合索引字段顺序

业务case-关联列隐式转换测试（字符集）

业务case-缺失索引和索引列选择测试

业务case-测试模糊匹配-前后模糊

单表等值简单查询-简单等值条件查询，单列索引和避免重复索引

单表等值简单查询-索引长度不合理

单表，范围查询-BETWEEN...AND...范围列可以加索引

单表，范围查询->=、<= 列加索引

单表，简单分组、排序查询-给分组/排序列加索引，以消除文件排序

单表，or 条件-无法通过索引解决性能场景，OR 条件导致索引失效

单表，多条件查询-复合索引中列的顺序，要求从左到右等值列在前，范围列在后，等值列按列选择性由高到底排序，并且范围列仅能有一列

单表，多条件 + 排序分组查询-复合索引中列的顺序，要求从左到右等值列在前，范围列或分组/排序列在后，等值列按列选择性由高到底排序，并且范围列仅能有一列

单表，覆盖索引-是否适合创建覆盖索引判断

单表，like-Like 前模糊和前后模糊查询会导致索引失效，后模糊可以走索引

单表，不适合建索引-NOT IN 列索引多数情况不生效

单表，不适合建索引-NOT IN 可以建索引的情况（覆盖索引）

单表，不适合建索引-<> 列索引多数情况不生效

单表， IS NULL 条件-IS NULL列可以使用索引

多表关联的多条件查询，驱动表识别以及复合索引列顺序

多表关联的多条件分组排序查询，驱动表识别以及复合索引列顺序

多表，group by 不同表-关联查询中GROUP BY相同表的多列需要按字段顺序创建复合索引解决临时表和文件排序问题

多表，group by 不同表-关联查询中GROUP BY不同表的列无法解决临时表和文件排序问题

多表，相同表多字段排序-关联表查询ORDER BY 相同表多字段，解决文件排序问题，包括需要将主键加入复合索引的场景

多表，相同表多字段排序-当INNER JOIN时，在数据量较大的驱动表上创建索引（可以转换驱动表与被驱动表，从而减少扫描行数）

表关联，复杂场景-关联查询的复合索引中关联列、条件列和排序/分组列的顺序

关联子查询-子查询索引创建，条件列和查询列在覆盖索引中的顺序

隐式类型转换的查询-隐式类型转换导致索引失效的前提是在索引列上进行转换，默认情况下MySQL的转换规则是将字符串转为数字

隐式类型转换的查询-表字符集不一致，utf8mb4向下兼容utf8，如果驱动表(列)为utf8，被驱动表(列)为utf8mb4，是不存在隐式转换的，反之则需要隐式转换

谓词列带有函数或计算的查询-索引列使用函数，索引列计算导致索引失效

左右关联查询-识别驱动表，在被驱动表的关联列上创建索引

UNION查询-union查询的索引建议，给独立查询分别建索引，但是外层的排序/分组导致的临时表和文件排序问题无法通过索引解决

NULL查询-= NULL 会导致索引失效，IS NULL 不会导致索引失效

ORDER BY ASC DESC 复合排序-ASC DESC混合排序会导致索引失效

恒等条件-恒等条件和无条件若查询列数量在复合索引允许的范围内，可以使用覆盖索引，否则无法使用索引解决性能问题

一个包含多层嵌套子查询的SELECT语句，子查询中存在多余的投影列，这些列在外层查询中没有被使用。

一个包含多层嵌套子查询的SELECT语句，其中外部的WHERE子句条件可以下推到最内层的子查询中。

一个包含多层嵌套子查询的JOIN语句，其中外部的WHERE子句条件可以下推到最内层的子查询中，同时存在可以投影下推的冗余列和可以进行LIKE前缀优化的条件。

一个包含多层嵌套子查询的SELECT语句，子查询中存在多余的投影列，同时内层子查询有ORDER BY和LIMIT，但最外层查询仍可进行投影下推。

一个简单的SELECT语句，其中WHERE子句对字段使用了函数，导致隐式转换。

一个包含COUNT标量子查询的SELECT语句，可以将其改写为IN子查询以利用SEMI JOIN特性。

一个包含HAVING子句的SELECT语句，其中HAVING条件不依赖聚合函数，可以下推到WHERE子句。

一个包含多层嵌套子查询的SELECT语句，最内层的GROUP BY子句是不必要的，可以被消除。

一个包含非关联子查询的SELECT语句，可以将子查询转换为关联子查询。

一个包含多个ROW_NUMBER()窗口函数和过滤条件的SELECT语句

一个包含UNION的SELECT语句，其中WHERE子句包含LIKE前缀匹配，可以改写为范围查询。

一个包含UNION的SELECT语句，外部查询包含LIMIT子句，可以下推到UNION的各个分支中。

一个包含IN子查询的SELECT语句，子查询明确只返回一行，因此可以转换为标量子查询。

一个包含嵌套子查询的COUNT语句，其中外部的WHERE子句条件可以下推到内层的子查询中，并且子查询中存在可以投影下推的冗余列。

一个简单的LEFT JOIN查询，明确引用了主表中的列，可能存在可消除的外连接。

一个包含LEFT JOIN的SELECT语句，连接条件为不等值连接，难以进行外连接消除。

一个包含LEFT JOIN的SELECT语句，连接条件为不等值连接，难以进行外连接消除，且使用了表别名。

一个包含INNER JOIN和DISTINCT的SELECT语句，可能存在不必要的DISTINCT，且包含排序操作。

一个简单的LEFT JOIN查询，可能存在可消除的外连接，且未引用被连接表中的任何列。

本次改写的核心技术是将score_model_factor表的JOIN转换为EXISTS子查询。原SQL中,虽然JOIN了score_model_factor表,但SELECT子句中并未使用该表的任何列(仅用于过滤),这正是JOIN转EXISTS优化的典型场景。改写后,通过EXISTS(SELECT 1 FROM score_model_factor f WHERE f.model_factor_id = t.model_factor_id)实现了相同的语义:只有当SCORE_RATING_RECORD_DETAIL.model_factor_id在score_model_factor表中存在时,该行才被保留。EXISTS的优势在于:(1)利用主键索引快速验证;(2)找到第一条匹配记录即返回TRUE,无需扫描所有匹配行;(3)不需要传递score_model_factor的列数据,减少内存和网络开销。

此次改写主要采用了谓词下推技术，试图通过提前过滤减少数据量。同时移除了内层不必要的ORDER BY操作（因为最外层使用ROWNUM限制结果集），理论上可以节省排序成本。还优化了日期比较条件，使其更加精确。然而，由于过滤条件位置调整不当，导致了SQL语义发生变化。

此次改写将子查询内部的'LEFT JOIN mrtrecordinfo B ON A.ID = B.ID'改为'INNER JOIN'。改写的理论基础是：由于外层查询使用了WHERE A.ID IN (SELECT bid FROM ...)条件，而bid来源于B.ID，这意味着只有B.ID存在的记录才会被选中。因此LEFT JOIN产生的NULL行在后续过滤中会被完全排除，使用INNER JOIN语义上等价且理论上可减少NULL处理开销。然而实际测试显示，Oracle优化器在处理原始LEFT JOIN时已经识别出这种模式并进行了等价优化，导致手动改写未产生实质性能提升。

这是一种经典的UNION ALL消除优化技术。当UNION ALL的多个分支查询相同的表，且仅在SELECT列表的计算逻辑或WHERE条件的常量值上有差异时，可以通过CASE表达式将不同的计算逻辑统一到一个SELECT语句中。改写的核心是将'metric_name IN (集合1) 返回round(VALUE,2)'和'metric_name IN (集合2) 返回round(VALUE*10,2)'两个分支，合并为'metric_name IN (集合1+集合2) 返回CASE WHEN...END'。这样WHERE条件从两次分别过滤变为一次过滤更大的集合，SELECT列表使用CASE根据metric_name动态选择计算方式。这种改写在保证逻辑等价的前提下，显著减少了I/O操作。

在LEFT JOIN场景中，当WHERE子句包含对右表（被LEFT JOIN的表）的条件时，这些条件实际上会将LEFT JOIN转化为INNER JOIN的效果（因为NULL行会被WHERE过滤掉）。但如果将这些条件移到ON子句中，就能：1）保持真正的LEFT JOIN语义；2）在连接阶段就减少需要处理的数据；3）让优化器有更多优化空间。本次改写正是基于这一原理，将对表B的tenant_id和bo_name过滤从WHERE移到ON子句。同时清理了冗余的'A.tenant_id = 1065587309019136'重复条件（改写前WHERE子句中出现了多次）

本次改写采用了CTE常量提取模式，将时间计算逻辑（fun_addmonth、to_char等）从连接条件中提取到CTE中，理论上可以避免在循环中重复计算这些函数。同时将COALESCE改写为显式OR条件，希望优化器能更好地理解谓词逻辑。然而，这种改写忽略了LIMIT 1对执行计划的影响：在只需要返回1行的场景下，原SQL的"惰性计算"策略更优，因为常量函数只会被调用极少次数。CTE的物化成本和额外的扫描开销在这种场景下无法被节省的计算成本所抵消。

该改写试图用经典的'MAX+自连接'模式替代窗口函数来获取每个分组的最新记录。理论上，当窗口函数需要处理大量数据时，GROUP BY聚合可能更高效。然而，本次改写犯了两个严重错误：1) 在CTE定义和子查询中使用了SELECT指定列而非SELECT *，导致结果集缺少字段；2) 没有充分验证结果集的完整性。正确的改写应该保持与原SQL完全相同的输出列，只改变获取数据的方法。

本次改写主要做了两方面优化：1) 消除了子查询中计算但从未使用的first_tran_date字段，减少了一次min()聚合操作；2) 将onhold_accounts这个内联视图展开，直接在主查询中JOIN audit_header和audit_detail表，并将过滤条件移到WHERE子句中。这种改写理论上可以给优化器更多的优化空间，但由于原SQL结构已经较为优化，实际收益有限。

改写试图通过三个方向优化：1）谓词优化：将SUBSTR函数改为LIKE谓词以便索引扫描；将HAVING COUNT(DECODE())改为简单的WHERE过滤；2）投影裁剪：对于COUNT(*)查询，将SELECT所有列改为SELECT 1，减少数据传输；3）数据预过滤：在连接前通过内联视图过滤数据。理论上这些都是常见的优化技术，但在本案例中，HAVING到WHERE的转换导致优化器基数估算失准，反而产生了更差的执行计划。

此改写的核心是将原SQL中针对nortran表的7个独立子查询(n1-n7)和1个去重子查询(z)通过CTE的GROUP BY + MAX + CASE WHEN技术合并。原SQL中每个子查询都有WHERE条件过滤不同的nortran_aufd_code，改写后通过CASE WHEN在单次扫描中同时提取所有需要的字段值，然后用MAX聚合选择每个transaction的值。这种行列转换技术将EAV(Entity-Attribute-Value)模型的多行数据透视为宽表的单行数据。同时，将nobtran的过滤条件前置，减少JOIN时的数据量。这种改写方式在OLAP场景中常用于优化维度属性的多次JOIN。

本次改写是一个纯语法层面的变更，仅将派生表（子查询）的别名从't'改为't2'，并相应更新外层SELECT语句中的列引用（t.age→t2.age等）。这种改写不改变SQL的语义、执行逻辑或数据访问路径，对数据库优化器来说两个查询完全等价。从性能优化角度看，这不是一个有效的改写方案，因为它不涉及任何能够提升性能的技术手段，如索引利用、连接顺序调整、谓词下推、子查询展开等。

本次改写采用了经典的查询优化技术组合：

1. **谓词下推（Predicate Pushdown）**：将out_date的过滤条件从最外层WHERE子句移到tmep_ip CTE内部。这样可以尽早过滤数据，减少CTE物化的数据量，虽然在本例中优化器已经将过滤推到了Parallel Seq Scan阶段，但显式下推使逻辑更清晰，且在某些复杂场景下能帮助优化器更好地生成执行计划。

2. **投影裁剪（Column Pruning）**：在diagnosis_ranked子查询中，移除了不再需要的diagnosis_type_name字段。该字段仅用于窗口函数的排序，在rn=1筛选后就没有实际意义了，因此在WindowAgg之后立即裁剪，避免传递到上层的GroupAggregate和Materialize节点。

3. **聚合维度优化**：diagnosis_end的GROUP BY从4个字段减少到3个字段。因为diagnosis_type_name在窗口函数排序后已被隐含使用（通过rn=1保证了每组只保留优先级最高的记录），在最终聚合时不需要再作为分组键。这减少了哈希表的键空间和比较开销。

4. **逻辑等价性保证**：虽然进行了多处优化，但查询的核心逻辑保持不变：
   - 诊断类型的优先级排序规则完全一致
   - ROW_NUMBER()窗口函数的分区和排序逻辑相同
   - MAX聚合对diagnosis_flag分组的处理逻辑相同
   - 最终JOIN关联条件和结果集完全一致

这次改写的核心思想是消除WHERE子句中的LEFT函数调用，因为函数作用于列会阻止索引使用。改写策略是将前缀匹配逻辑展开为21个具体的等值比较条件（对应字符串'745070056000500070090'的每个前缀）。每个条件形式为：(code_length = N AND CODE = 'prefix')。理论上，这种改写可以让优化器使用索引，因为CODE列现在是等值比较而非函数参数。然而实际效果适得其反，原因是：1) 条件数量过多（21个OR）导致评估开销增加；2) 每个条件仍需调用CHAR_LENGTH函数验证长度；3) MySQL对多OR条件的索引使用优化有限，最终仍选择全表扫描。

核心技术是将非Sargable条件(索引列上的函数)改写为Sargable条件(可利用索引的条件)。对日期列使用函数会导致索引失效，改用范围查询可以充分利用索引。同时修正了数据类型不匹配问题(Flag字段定义为CHAR但与整数比较)，并清理了冗余条件。这种改写在保证结果一致性的前提下，通过技术手段显著降低了查询开销

这是一个典型的消除无用计算的优化案例。当外层查询只是COUNT(*)时，内层子查询中计算的所有列值（包括通过子查询计算的auditJobIdcounts）都不会影响最终结果。COUNT(*)只关心有多少行满足WHERE条件，而不关心这些行的具体内容。因此可以直接将内层子查询展开，删除所有不必要的列选择和子查询计算，只保留WHERE条件。这种改写消除了189504次依赖子查询执行、临时表物化和34个列的数据读取，大幅提升性能。

这种改写技术通过将OR条件拆分为多个UNION子查询，理论上可以让每个子查询更充分地利用索引。在某些数据库版本或特定场景下，当OR条件导致优化器无法有效使用索引时，这种改写可能带来性能提升。但在本案例中，MySQL的index_merge优化已经能够很好地处理OR条件，反而是UNION引入的额外开销导致性能下降

问题概述：查询通过 CTE a1 对 FEE_LIST_D 做了大量的聚合（多个 LISTAGG、SUM、MIN 等），并在 a2 中使用 `a1.*` 再做计算和过滤后与 SETL_D_MERGED 连接。实际最终 SELECT 只使用了 a1 中的一部分列（例如 b_fee、min_amt 等列并未被外层查询引用），但由于使用了 `a1.*` 导致这些不必要的列在聚合阶段就被计算/传递，增加了 CPU、内存与 I/O 开销，同时阻止了投影下推优化。建议通过投影下推（在 a1 中仅输出外层实际需要的列，避免 a1.*）来减少中间数据量与聚合成本；同时可考虑在 a1 中下推过滤谓词并为连接列建索引以进一步降低成本。

问题概述：该查询在 HRM_FLOOR.C_BASE_STATION_T(B) 上有多重等值过滤（BU_ID、HAC_ID、KEY_STATION_ID 列和 MFG_PROCESS_ID、DEL_FLAG），并且在主表 P 上按 WORK_DATE 与 DEL_FLAG 进行筛选，同时包含一个关联的 EXISTS 子查询来确认员工在对应站点的有效执照记录。潜在性能问题包括：1) 如果用于比较的列与字面量类型不匹配（例如 WORK_DATE 字段若为 VARCHAR 则与 DATE 常量比较会发生隐式类型转换），会导致索引失效；2) 缺少覆盖这些谓词和关联列的复合索引，会使得优化器采用全表扫描或大量回表，增加 I/O；3) EXISTS 子查询使用逗号分隔的老式连接写法（F, H）且为相关子查询，会导致对每一行执行索引查找/范围扫描，若 H/F 没有在 (EMP_NO, LICENSE_ID) 与 (LICENSE_ID, STATION_ID) 上建立合适索引，会产生大量随机 I/O。建议：确认 WORK_DATE/相关列数据类型与谓词匹配以避免隐式转换；为 B 表建立复合索引覆盖 (BU_ID, HAC_ID, KEY_STATION_ID, MFG_PROCESS_ID, DEL_FLAG) 或拆分为多个选择性索引；为 P 表建立 (WORK_DATE, DEL_FLAG, STATION_ID, EMP_NO) 索引以支持主谓词和后续关联；为 R_KEY_STATION_MAN_T 与 R_KEY_STATION_LICENSE_T 分别建立针对 (EMP_NO, LICENSE_ID, LOSE_FLAG, DEL_FLAG) 与 (LICENSE_ID, STATION_ID, DEL_FLAG) 的索引；将 EXISTS 子查询改写为显式 JOIN 或至少使用关联索引以减少对每行的重复查找。同时建议将高选择性谓词（如 P.DEL_FLAG=0、B.DEL_FLAG=0、B.BU_ID 等）尽量作为最先评估的过滤条件，降低后续关联数据量。

问题概述：原始查询包含一个全表聚合 + 窗口函数的 CTE（rank_general），多个 LEFT JOIN 与一个 CROSS JOIN(me 子查询)，以及对 otr.otr_consulta 的行级展开 (CROSS APPLY (VALUES ...)) 再做 GROUP BY。性能瓶颈可能来自几处：
1) rank_general 需要对 flashdeventas.vetas_y_formas_de_pago 做 GROUP BY 并按 SUM 排序再计算 ROW_NUMBER，若无合适索引/预聚合会导致全表扫描与昂贵的排序；
2) me 使用常量筛选但被 CROSS JOIN 到主查，若 me 返回多行会乘扩大外层行数；即使 me 仅返回一行，保留未被外层使用的列会造成不必要的数据传递（可用投影下推移除 proveedor 与 estilo）；
3) otr 子查询对 otr.otr_consulta 做了 VALUES 展开后 GROUP BY，若不把高选择性谓词（c.tienda = 3064）下推，会扫描大量无关行并产生大规模聚合中间结果；
4) 多个 LEFT JOIN（例如 ranking_tda_jerarquia、control_asignacion_matrices）若缺乏覆盖索引，会引发大量回表和随机 I/O。

建议（与实习生给出的规则一致）：
- 进行投影下推：在 me 子查询中移除未被外层用到的列（如 proveedor、estilo），减少中间结果宽度；
- 进行谓词下推：把高选择性条件 c.tienda = 3064 下推至 otr 的扫描/聚合子查询（即 WHERE oc.id_tienda = 3064），显著降低 otr 聚合量；
- 检查并建立必要索引：例如 otr.otr_consulta 上应有 (id_tienda, id_departamento, id_subdepartamento, id_clase, id_subclase, tipo_articulo) 的复合索引或至少 id_tienda 的索引；catalogos.maestro_estilos 可在 (proveedor, estilo) 建索引；catalogos.ranking_tda_jerarquia 在 (id_tienda, departamento, subdepartamento, clase, subclase) 上建索引；clusters.tienda_atributos 在 (centro_comercial, clima, tienda) 建复合/前缀索引；catalogos.tiendas 在 TIENDA 列建主键/索引。 
- 对 rank_general 的全表排序开销敏感时，考虑离线物化/周期维护排名表或限制计算范围（若业务允许）。

在满足语义前提下（确保移除的列确实不被外层引用，且 c.tienda 为强选择性过滤），方式1 的投影与谓词下推是低风险且立即见效的改进；方式2（更激进的提前过滤/LEFT→INNER 等）若要采用需严格验证不会改变结果。

问题概述：此查询包含三层嵌套用于实现基于 ROWNUM 的分页（最内层包含大范围的 SELECT + 多个 LEFT JOIN + 多个标量子查询与函数调用；中间一层再包一层并限制 ROWNUM<=10；最外层再按 rn>0 过滤），导致不必要的视图物化与数据传递开销。主要性能隐患还有：1) 大量标量子查询（例如从 RES_SYS.PUB_MFR、RES_SYS.PUB_DIC_EQP_TYPE、RES_SYS.PUB_RME_EQP_MODEL 等按 ID 查询名称）会对每一行触发独立索引/表访问，开销成倍放大；2) 频繁调用的行级函数（RES_ENTITY.SF_GET_DESC_CHINA / SF_GET_STAFF_NAME 等）若未缓存，会导致大量 CPU 时间；3) IN 子查询包含 CONNECT BY 的递归层次查询，若不先将其物化为较小集合，会使主表筛选成本增高；4) 宽表 SELECT *（以及许多未必要的列和文本转换）增加了 I/O 与网络传输量。建议：删除最外层冗余的 `where rn > 0` 并把分页逻辑简化；把 `ROWNUM <= 10` 的限制尽量下推或改为 `FETCH FIRST 10 ROWS` / 使用 FIRST_ROWS 优化；将标量子查询改写为 LEFT JOIN（或事先使用单表缓存/物化视图）以避免每行重复访问；为常用的连接/过滤列（ENT_ENTITY.ENTITY_ID、ENT_ROOM.ENTITY_ID、ENT_ENTITY.STATION_CODE、STA_STATION.STATION_CODE/ STATION_ID、STA_APP_INFO.STATION_ID、STA_BIZ_INFO.STATION_CODE、REG_MANAGE.REGION_ID）建立合适索引；对昂贵的行级函数考虑结果缓存或提前物化；对 CONNECT BY 结果先计算并临时表化以减少重复计算。这样可显著减少全表扫描、嵌套循环和重复的随机 I/O。

该SQL旨在统计四个不同时间窗口内（过去7、13、25、2小时），各行政区划的'zdjs'指标最大值。存在显著的性能问题：1. **冗余列投影**：最内层查询选取了`zdbh`、`zxjs`等后续聚合不需要的字段，增加了不必要的I/O和内存开销。2. **无效排序**：四个作为JOIN源表的子查询（Derived Table）内部均包含`ORDER BY "zdjs" desc`但无`LIMIT`，这种排序在关联操作中是无意义的，且可能触发额外的排序操作。3. **多层嵌套**：存在冗余的子查询层级，导致生成不必要的临时结果集。优化方向包括移除无效排序、裁剪非必要列以及子查询扁平化。

该SQL查询存在显著的性能瓶颈，主要体现为：1. **谓词未下推**：核心过滤条件`CUSTOMER_ID`位于最外层，导致内部巨大的UNION ALL派生表（由四部分组成）必须先全量物化及聚合，无法利用索引提前过滤数据。2. **隐式内连接**：对LEFT JOIN表`t_dgm_send_info`的字段进行了`SEND_STATE='70'`的等值过滤，语义上已变为内连接，但写法可能误导优化器或导致低效的执行路径。3. **冗余的聚合与排序**：外层的`GROUP BY temp.MIXED_NO`在业务逻辑上可能是冗余的（子查询已确保唯一性或JOIN关系未导致膨胀），且`HAVING`子句中包含了本应在WHERE中过滤的非聚合条件，导致了不必要的临时表和排序开销。4. **宽表投影**：派生表输出了大量后续未使用的列，增加了内存和I/O负担。

改写前的SQL在子查询条件（col_pk_varchar）中使用了数值字面量进行范围查询（BETWEEN 192 AND 171），而col_pk_varchar列是VARCHAR类型。MySQL在比较不同类型时可能触发类型隐式转换，导致索引失效（本次场景中未失效但引发了多余扫描）。改写后显式使用字符串字面量（BETWEEN '192' AND '171'），确保类型一致，使优化器能准确评估区间有效性。同时，由于数字192大于171，字符集下同样不成立，优化器能立即识别并跳过该子查询扫描。

该改写方法消除了UNION ALL结构，避免了重复扫描表和创建临时表的开销。核心策略是将两个分支的冲突条件（一个包含特定uuid列表且无视private，另一个排除该列表且要求private=0）用OR组合起来，集成到同一个查询中。同时保持非重复性过滤条件（如全文检索和标签过滤）在最外层执行一次，避免了冗余操作。

改写后的SQL直接将原始SQL中的WITH子句直接在句同为一层的查询中，移除了不必要的子查询结构（CTE），这是优化SQL编写方式的常用方法。在PostgreSQL处理用例，对于非递归的CTE，查询优化器通常能够直接优化内部逻辑，故改写可能带来可见提升效果不明显。

此改写技术通过将外层过滤条件下推到子查询内部，减少子查询需要处理的数据规模，尤其对于需要聚合（group by）和窗口计算（row_number）的操作，避免对无效数据进行计算，从而提升整体性能。

通过分析业务逻辑：avg_cust_rate子查询基于vehicle_type, booking_status, payment_method分组，而base表在JOIN时使用相同的字段组合匹配，因此不可能存在base记录在avg_cust_rate中找不到对应分组的情况。同时，WHERE条件要求字段差值的绝对值>=1，强制avg_cust_rate.avg_v必须有值，故LEFT JOIN时保留的NULL记录必然被WHERE过滤。改为INNER JOIN排除了这些无效记录，减少了中间结果集大小。

改写前的SQL对每个分组结果（每个customer_id）执行两个相关子查询，导致对每个成组的customer_id都要额外扫描两次表。改写后将子查询逻辑合并到主查询的聚合函数中，利用主查询的分组直接计算平均值和最大值，避免了N+1查询问题，大幅减少了重复扫描次数。

该SQL用于统计库存车辆数及首次入库数，涉及近20个表的LEFT JOIN。主要性能问题有：1. **投影冗余**：作为连接源的两个子查询（Derived Tables `mo` 和 `purchase`）输出了大量外部查询不需要的列（如`AUDIT_STATUS`、`NEW_HOUSE_ID`、`PURCHASE_ORDER_CODE`等）。这导致中间结果集（临时表）宽度过大，显著增加了内存消耗和I/O开销。2. **子查询效率低**：`mo`子查询内部嵌套了分组聚合和IN子查询，且未有效过滤数据。3. **谓词下推机会**：主表`t_mdm_dlr_car_store`的过滤条件`IS_ENABLE='1'`位于WHERE子句，虽然优化器通常处理，但在复杂宽表连接中，显式下推或精简数据源能获得更稳定的执行计划。

该SQL查询用于筛选特定的索赔记录（claim），逻辑上包含复杂的`OR`条件关联查询和用于去重的关联子查询。存在的主要性能瓶颈：1. **无输出的JOIN操作**：查询对`serie`表进行了两次LEFT JOIN（分别作为`serie`和`exchange_serie`），但在SELECT列表中并未请求这些表的任何字段，仅用于WHERE子句的过滤。这种写法增加了不必要的连接开销。2. **谓词未下推**：WHERE子句中包含跨表的`OR`逻辑 `(A AND B) OR (C AND D)`，这通常阻止优化器有效地利用索引进行过滤，导致优化器可能选择扫描整个`claim`表后再进行过滤，而不是先通过索引定位。3. **昂贵的关联子查询**：为了保留每个`claim_folder_id`下的最新记录，使用了关联子查询 `c.id = (SELECT MAX(...) ...)`，这会导致对每一行结果都执行一次子查询（N+1问题），在数据量大时性能急剧下降。

Seed-OSS-36B-Instruct is a 36-billion parameter open-source large language model developed by ByteDance's Seed Team. It is designed for powerful long-context, reasoning, agent and general capabilities, and versatile developer-friendly features. 

Type	Chat	Organization	ByteDance	Release Date	2025/08/20
Website	https://seed.bytedance.com/zh/blog/seed-oss-open-source-models-release

Indicator Name	Indicator Weight	Evaluation Type	Passed Cases	Failed Cases	Pass Rate
Index Advice	2	hybrid	52	36	59%
Logical Equivalence	3	hybrid	26	24	52%
Optimization Depth	2	subjective	41	53	44%
Syntax Error Detection	3	hybrid	38	12	76%

Seed-OSS-36B-Instruct

Ability Scores

Evaluation Case Report

Evaluation Process