技术层面【配置项】拉出主库，或者永久放在缓存中，guava或者redis或者两者可以同时使用（高并发时，需要考虑redis的最大连接数等瓶颈，小数据量配置项可以考虑只使用本地缓存），配置项变化时刷新缓存，通过广播通知所有实例刷新本地缓存（dubbo)根据业务情况减少C端接口【数据库】的调用时间，配置数据库链接的最大数量等于初始数量，即期间不申请新的数据库链接的行为程序的运行可以避免大数据量下高并发条件下[SQL]大量请求同时获取数据库链接造成的耗时竞争某些情况下索引对应的数据过多时，它会导致简单的性能下降，甚至是全表扫描。在内存情况允许的情况下（即运行实例能够承受的内存空间，空间换时间），可以使用代码过滤代替数据库级别的过滤，提高数据库级别的Query效率；编码时慎用notin条件，时间类型查询条件可以考虑通过主键过滤（业务允许的情况下）【数据归档】结合实际业务情况，对数据进行归档，比如half一年或一年前的订单数据，两年前过期的信用等非高频数据；可以结合数据仓库，如hive，es等进行冷数据查询【使用从库】结合实际业务情况，可以使用从库完成一些复杂的任务报表统计，当从库延迟满足业务受理的最大延迟，可以完整的从库中读取数据，比如T-1账单，积分统计，门店业绩统计等。【交易】高并发场景更加谨慎确定交易覆盖范围.比如在一些需要获取锁的场景下，获取锁失败的请求会抛出异常并返回。如果此时有事务覆盖，就会浪费系统性能。事务在获取锁之前应该覆盖Afterwards（事务应该只覆盖真正的DB操作区间）在业务层面【数据时效性】引导产品深入分析业务需求，确定业务可接受的最大数据延迟，如报表，或C端数据概览，建立数据时间边界，避免非刚性需求的实时数据查询【业务理性】从功能层面提升业务需求，并非所有需求都是业务决策，当面临系统压力时海量数据带来的，可以考虑从业务角度出发，先对需要处理的数据进行分解重组数据，避免系统性能瓶颈，比如预订数据，可以通过发送邮件和生成报告下载来代替等，在不影响用户体验的情况下，尽可能节省系统性能优化案例，用于查询用户基础数据当查询条件类型较多时，数据需要通过多表聚合，敏感信息通常需要解密，所以耗时长，接口性能差；因为代码迭代时间过长，单个方法混合冗余查询，查询速度慢。经排查，发现某些数据存储的查询条件不同在多次查询的情况下，优化了对齐方式，每个关键数据只查询一次，提高了系统性能；以往最高TPS为2800/s，优化后在压力测试TPS9000/s消费点时，为了保持数据唯一性，锁定userId（即相同userId的请求必须串行执行）。在代码优化之前，事务在获取锁之前就已经被覆盖了。导致第二次请求同一个userId在高并发时无法获取到锁，代码抛出异常，事务回滚，整个请求时间延长，性能下降。优化后事务只有在获取到锁后才被覆盖，大大提高了接口的性能，避免了资源的浪费
