sql语句
在sql层面，如果缺乏优化意识，一量数据量上涨或者是并发上涨到一定知识，必然会导致jvm崩溃或者是线程被占满。
- 数据量大，没有索引，全表扫描（前期开发时、设计表结构时，未考虑索引创建）
- 索引失效或者未命中
- 数据量小
- 数据量大，非精确过滤
- sql索引字段使用了如函数、计算、or、like +前%、not....
- 索引太多、设计不合理，导致数据库发神经，无法命中高效索引
- 过滤条件太多，每个条件过滤结果都不精确，导致数据被多次过滤检索，cpu消耗大
- 多表关联时，关联字段没有使用外键索引，或者是关联条件复杂且使用了函数计算
- 表里存在大字段，未对大字段做特殊处理，每次查询都将大字段数据查询出来加载到内存中，但又并未使用。
- sql编写太过复杂，随意使用了特殊函数。应该从设计时考虑，前端做必要的多次请求（请求非常快）和缓存、后端也需要做必要的缓存机制、多线程处理、分多次请求（也需要控制次数）
- 针对上述情况，最根本的建表时是否合理，创建索引是否合理，必要情况可以使用函数索引。
后端程序
- jvm 崩溃
- 参数没有调优
- 将全表数据查询出来，加载到内存中
- 原因：1、一些没有分页的列表查询，过滤条件没有做非空判断。2、有过滤条件，但是过滤后，仍然返回了大量的数据，并且存在大量循环情况。
- 存在多次循环调用接口或者数据库请求的情况，当并发上去后，线程被占满，资源无法释放。（适当采用多线程，建议使用响应式异步编程）
- 大量使用了数据库事务及代码同步锁，容易引起交叉事务，进而导致锁表发生，数据库事务无法释放。
- 数据库连接，文件流等未做规范的关闭处理，一旦出现异常，连接无法关闭，导致资源不足，引起系统崩溃。
- 接口请求的http连接，没有设置超时时间，一旦接口提供方存在异常，http连接一直处于请求状态中，积累一定量后，也会引起应用资源不足的情况。
前端程序
- 接口请求使用了同步方法，如果接口请求时间较长，自然就会直接表现出系统卡顿现象。
- 对于高步的操作，未做点击的屏蔽事件，即一次请求还未完全响应，用户可以重复点击请求。这对后端来说，非常容易引起高并发现象。高并发自然会引起非常多的问题，所以前端必须注意控制接口的请求频次。
- 静态资源为做压缩，或者文件数量多，用户量一旦上去，也容易产生高并发，对服务器的线程数、网络流量也有不小的压力。