共计 691 个字符，预计需要花费 2 分钟才能阅读完成。
技术层面
【配置项】抽离主库，或永恒搁置于缓存中（举荐），guava 或 redis 或二者同时应用皆可，在配置项发生变化时刷新缓存，可透过播送（Dubbo）告诉所有实例刷新本地缓存，以升高 C 端接口调用工夫
【数据库】视业务状况，配置数据库链接最大数等于初始量，即程序运行过程中不进行新申请数据库链接的行为，可防止在高并发状况下，大量申请同时获取数据库链接导致的竞争耗时
【SQL】在大数据量状况下，当索引对应过多数据会导致索性性能降落，甚至全表扫描，在内存状况容许时（即运行实例能够接受的内存空间），可用代码过滤来代替数据库级别筛选，进步数据库层面查问效率；在 coding 时应谨慎应用 not in 条件，同时工夫类型查问条件能够思考通过主键进行筛选（业务容许时）
【数据归档】结合实际业务状况，将数据归档，例如半年、一年前的订单数据，两年前已过期的积分流水等非高频数据；可联合数仓，如 hive，es 等进行冷数据查问
【应用从库】结合实际业务状况，可利用从库实现某些简单报表统计，当从库延时满足业务承受最大延时的条件下，可齐全读取从库数据，如 T - 1 账单，积分统计，门店业绩统计等
业务层面
【数据时效性】疏导产品深入分析业务需要，确定业务承受的最大数据延时，例如报表，或 C 端数据概览，确立数据工夫边界，躲避非刚需的实时数据查问
【业务合理性】从性能层面推动业务需要，并非所有需要都是业务决定，当面临大体量数据带来的零碎压力，能够思考从业务角度登程，先将所需解决的数据合成，再拼凑，躲避零碎性能瓶颈，例如预约数据，可通过发送邮件、生成报表提供下载等模式代替实时生成，在不影响用户体验的状况下，尽可能节约零碎性能
正文完
