# 聚合操作分析 (继续...)

+ 全表扫描 10,000,000 变为 1,200,000
+ 2.8 秒降低到 0.8 秒
+ 问题：并发增加后，CPU 负载增高

------------------------------------------------------------
加了索引后，执行计划中，扫表方式就变成了IndexRangeScan，并且只需要扫描索引大概 1,200,000（基于统计信息估算）记录，执行时间从上面全表扫描的 2.8 秒降低到了0.8 秒左右，比较明显的提升了查询的速度。

到这一步，这个 SQL 算是优化完成了么？可能不是的，如果这个 SQL 在线上存在并发调用的场景的话，还是很大可能把数据库打出性能问题的，因为就算走索引，也是扫描了大概 1,200,000 记录，并发上来后需要扫描的数据量就会非常大，大概率 CPU 会成为瓶颈，那怎么解决高并发下的性能问题呢？这里分两种情况：加了索引后，执行计划中，扫表方式就变成了IndexRangeScan，并且只需要扫描索引大概 1,200,000（基于统计信息估算）记录，执行时间从上面全表扫描的 2.8 秒降低到了0.8 秒左右，比较明显的提升了查询的速度。

到这一步，这个 SQL 算是优化完成了么？可能不是的，如果这个 SQL 在线上存在并发调用的场景的话，还是很大可能把数据库打出性能问题的，因为就算走索引，也是扫描了大概 1,200,000 记录，并发上来后需要扫描的数据量就会非常大，大概率 CPU 会成为瓶颈，那怎么解决高并发下的性能问题呢？这里分两种情况：