从经验上来看，在数据库层面的请求应答时间必须在100ms以内，秒级的SQL查询通常存在巨大的性能提升空间。有如下应对方案：
建立高效且合适的索引
索引谁都可以建，但是要想建好难度极大。因为索引既有数据特征，又有业务特征，数据量的变化会影响索引的选择，业务特点不一样，索引的优化思路也不一样。通常某个字段平时不用，到是某种触发场景下命中”索引缺失“的字段会导致查询瞬间变慢。所以，要事先明确业务场景，建立合适的索引。
排查连接资源未显式关闭的情形
要特别注意在ThreadLocal或流式计算中使用数据库连接的地方。
合并短的请求
根据CPU的空闲局部性原理，对于相近的数据，CPU会一起提取到中。另外，合并请求也可以有效减少连接的次数。
合理拆分多个表join的SQL，若是超过三个表则禁止join
如果表结构建得不合理，应用逻辑处理不当，业务模型抽象有问题，那么三表join的数据量由于笛卡儿积操作呈几何级数增加，所以不推荐这样的做法。另外，对于需要join的字段，数据类型应保持一致。多表关联查询时，应确保被关联的字段要有索引
使用临时表
某种情况下，该方法是一种比较好的选择。曾经遇到一个场景不使用临时表需要执行一个多小时，使用临时表可以降低至2分钟以内。因为在不断的嵌套查询中，已经无法很好地利用现有的索引提升查询效率，所以把中间结果保存到临时表中，然后重建索引，再通过临时表进行后续的数据操作
应用层优化
包括进行数据库结构优化、并发多线程改造等
改用其他数据库
因为不同数据库针对的业务场景是不同的，比如Cassandra、MongoDB。
