性能测试实战，sql增加索引，tps大幅度提升

基于提供的SQL执行计划信息和表结构，以下是针对性能优化的详细建议，并解释单个索引与联合索引的核心区别：

---

### **一、当前SQL性能问题分析**
#### 1. **执行计划关键问题**
```plaintext
Table_Rows: 504,080
Physical_Range_Rows: 504,196  # 实际扫描行数≈总行数
Logical_Range_Rows: 504,080
Index_Back_Rows: 0
Output_Rows: 0
Available_Index: IDX_USC_PUT_LOAN_DEAL_MANG_1
Pruned_Index: IDX_USC_PUT_LOAN_DEAL_MANG_1  # 索引被剪枝（未使用）
```
**问题诊断**：
- **全表扫描**：物理扫描行数(504,196)接近表总行数(504,080)，说明**未有效利用索引**
- **索引失效**：优化器选择忽略可用索引`IDX_USC_PUT_LOAN_DEAL_MANG_1`，可能因索引设计不匹配查询条件
- **零结果输出**：`Output_Rows=0` 表明查询可能被过滤条件全部拦截或存在逻辑错误

#### 2. **高频问题SQL**（`1.jpg`）
```sql
-- 全表扫描SQL
SELECT COUNT(*) FROM USC_PUT_IOAN_DEAL_MANG;

-- 条件查询SQL
SELECT OPDT_LOSER_NAME, UPDT_ORGN, ... 
FROM USC_PUT_IOAN_DEAL_MANG 
WHERE ACCL_SERUM = ? AND STATUS = ?;
```
**性能瓶颈**：
- `COUNT(*)` **缺乏索引覆盖**，50万+行全表扫描消耗巨大I/O
- 条件查询字段 `ACCL_SERUM` 和 `STATUS` **未建立合适索引**

---

### **二、性能优化详细方案**
#### 1. **索引策略优化**
| **索引类型**       | **推荐方案**                                                                 | **预期收益**       |
|--------------------|-----------------------------------------------------------------------------|-------------------|
| **覆盖索引**