实用：性能优化的几点总结

一、最基本查看sql，是否建索引，索引是否生效，走了多少条数据，一般如果走了索引，并且索引生效，基本row数据会很少，相反，成百上千上万都有可能。

二、查询的数据量，如果针对像订单或者商品这种业务的查询，必须要加限定时间范围的，除非是单号或者id查询。否则查询的量很大，导致系统卡慢。

三、设计层面的优化。如果某块业务数量很大，比如说考试系统中，每个学生试卷中题目的阅卷老师的配置。之前系统中，产品设计的要求是每个学生试卷中的每个题目可以是不同的阅卷老师。这样的一场考试100份试卷，每个试卷100道题目，设置阅卷老师，就会有100*100，10000的数据量，而且是这些数据是一次批量插入数据库，当然会卡慢。如果我们以大字段的方式，也就是字符串拼接id(1,2,3,4,5.....)的方式保存每个阅卷老师的题目，那么会极大的减少数据量，假设每份试卷分配的老师不会超过10个的，也就是最多也就1000条数据。

四、代码优化。避免for循环里更新和插入，建议改成创建list，然后批量保存。注意保存的时候可以设置batchSize。防止batchSize过长，超过sql的长度限制导致执行失败。

四、异步。之前项目中上了生产，用户反馈按钮操作卡慢。查看代码，发现一次按钮对应的后台操作太多，而其中某些操作实时性不高。比如说上完课给学生发试卷，后来利用MQ做了解耦，极大的减少了时间。不过改成异步，就需要保证数据一致性。异步的方式需要做幂等以及并发控制。

五、搜索引擎。之前项目中题库系统，用户反馈查询卡慢。后来查询发现产品设计的需求里要求能根据关键词搜索，而搜索的字段包含text类型的题干。我们知道题干是文本类型，并且像阅读理解题的题干都是超长的，所以并不会加索引。并且根据关键词like模糊查询，本身也不会走索引。所以像这种问题，当题库中题目越来越多，查询必然会卡慢。这样情况，数据库层面是无法优化的，只能走搜索引擎。这里需要注意一点，使用搜索引擎，必然涉及到数据和搜索引擎的数据同步，而同步是存在失败的可能的，并且同步需要短暂的时间。这就必然会存在数据库和搜索引擎数据会短时间内的不一致。比如新创建的数据，入库成功了，但是还没入搜索引擎，导致用户刷新页码看不到新创建的数据。

六、分库分表，读写分离，减少写库的压力，将查询的请求指定到读库。

七、缓存，使用redis缓存使用比较频繁的数据。

性能优化是很大的问题，目前能总结的就是这些，后面有新的会持续更新。