# Suboptimal Sql Statement Execution (Continue...)

```
mysql> select count(*)
    -> from tods.bus_jijin_trade_record a, tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and a.id >=  177045000  
    -> and a.updated_at > date_sub(now(), interval 48 hour) ;
+----------+
| count(*) |
+----------+
|      712 |
+----------+
1 row in set (1.69 sec)
```
------------------------------------------------------------
```
mysql> select count(*)
    -> from tods.bus_jijin_trade_record a, tods.bus_jijin_info b 
    -> where a.fund_code=b.fund_code and a.type in ('PURCHASE','APPLY')  
    -> and a.status='CANCEL_SUCCESS' and a.pay_confirm_status = 1 
    -> and a.cancel_app_no is not null and a.id >=  177045000  
    -> and a.updated_at > date_sub(now(), interval 48 hour) ;
+----------+
| count(*) |
+----------+
|      712 |
+----------+
1 row in set (1.69 sec)
```

At this point, the execution time changes to 1.69s. If the execution plan does not change, it should be due to the increase in cache hit rate.
It can be seen that the poor execution efficiency of the SQL is due to inaccurate statistics, and the correct execution plan is obtained after collecting the statistics.
Judging from the final 712 row records, creating a composite index can significantly reduce the amount of data scanned and further improve performance. In cases where the performance is already meeting the business requirements, there is an additional cost for composite indexes to be tried later.