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