最近在开发一个Online Judge系统，其中有一个“挑战模式”模块，如图所示
由于是第一次使用ECharts做开发，所以完成整个模块的过程也是边写边学了，记录一下问题：
遇到的问题：在最开始进行测试的时候，一共有107个模块作为节点，节点之间还未设置关联关系，但是加载完全的用时达到了2s至3s。
解决的思路：
（1）毫无疑问，ECharts的渲染成为了我第一个怀疑的对象，我认为是渲染的配置没有配置好，所以我通过查阅ECharts的相关文档，修改了一些参数，但是效果并不明显。
（2）我重新设计了一下信息传递的逻辑，分为 从后端获取数据 - 处理数据以符合ECharts需要 - 装载数据进入ECharts中 三个步骤，对每个步骤测试了用时，最后发现是从后端获取数据的用时最长，思维定势认为是渲染慢导致的问题并不存在，ECharts作为大厂的开源作品其实做的很好，不会成为耗时瓶颈（官方文档的demo有超过十万个节点的图例，但没有出现耗时问题）。问题就这么定位出来了，是数据获取出现了问题。
（3）问题定位出来是数据获取的问题，而且我是在本地测试环境下进行前后端通信的，所以网络延迟不考虑，那么只能是在后端里出了问题了。逐一查看数据从数据库进入到mapper层再到service层再到controller层的过程，发现是数据库的查询过于缓慢，分析发现，查询条件过多但是其中有一个where子句的字段没有使用索引。于是添加索引，boom，取数据的耗时从2s的耗时降到了0.2s左右，问题解决。
解决方案：对数据库的SQL语句的where子句用到的字段加上索引。索引的原理大致就是建立一个索引表，索引表内有原表这个字段的全部值，对应着包含该字段的记录的存储地址。简单来说，假设有一个student表内有100条记录，字段sid建立了索引，并且 sid = 1 有9条记录，那么，在索引表内就会有
sid = 1 记录 = 地址1，地址2... 地址9；
sid = 2 记录 = 地址10，地址11...；
查询 SELECT * FROM student WHERE sid = 1时，那么数据库就会先在索引表内找到sid=1时对应的记录的物理地址，完成查找，就不需要扫描全表去找了。
每个DBMS实现索引的方式是不同的，但是具体的思路是一致的，详情可以看这篇博客：https://blog.csdn.net/tongdanping/article/details/79878302