# Aggregate Operations Analysis (Continued...)

+ A full table scan of 10,000,000 becomes 1,200,000
+ 2.8 seconds down to 0.8 seconds
+ Problem: CPU load increases after increased concurrency

------------------------------------------------------------
After adding the index, in the execution plan, the table scan method becomes IndexRangeScan, and only needs to scan the index about 1,200,000 records (based on statistical estimates). The execution time is reduced from 2.8 seconds of the above full table scan to about 0.8 seconds, which significantly improves the query speed.

At this point, is this SQL optimized? Probably not. If there is a concurrent SQL call scenario online, it is still very likely to cause a performance problem for the database, because even if the index is taken, it scans about 1,200,000 records, and the amount of data that needs to be scanned after concurrency will be very large, and the CPU will become a bottleneck, so how to solve the performance problem of high concurrency? There are two cases: after adding an index, the table scan method becomes IndexRangeScan in the execution plan, and only needs to scan the index about 1,200,000 records (based on statistical estimates). The execution time is reduced from 2.8 seconds of the above full table scan to about 0.8 seconds, which significantly improves the query speed.

At this point, is this SQL optimized? Probably not. If there is a concurrent SQL call scenario online, it is still very likely to cause a performance problem for the database, because even if the index is taken, it scans about 1,200,000 records, and the amount of data that needs to be scanned after concurrency will be very large, and the CPU will become a bottleneck, so how to solve the performance problem of high concurrency? Here are two situations: