优先根据数据量和系统瓶颈选择算力位置：小数据且已加载时用Collections.max()更轻量；大数据或仅需单值时交由数据库MAX()并确保索引命中；混合场景可分阶段下推加应用层兜底。
直接用 collections.max() 在内存中找最大值，和让数据库用 max() 聚合函数计算，本质是算力在应用层和数据库层之间的分配问题——选哪边，取决于数据量、网络、一致性要求和系统瓶颈。
小数据量且已加载到内存时，Collections.max() 更轻量
如果业务逻辑本身就需要遍历整个集合（比如查出 100 条订单做本地统计），再额外发一条 SELECT MAX(amount) 就是冗余 IO。此时直接调用 Collections.max(list, Comparator.comparing(Order::getAmount)) 零额外延迟，不占数据库连接，也避免了序列化/反序列化开销。
- 适用场景：后台导出报表前的临时汇总、缓存中预聚合的数据分析、单元测试中的断言校验
- 注意点：确保集合非空，否则抛
NoSuchElementException；若元素为 null，需自定义比较器或提前过滤
大数据量或仅需单个极值时，优先交给数据库 MAX()
查 1000 万条订单只为了取最高金额，把全量数据拉到 JVM 再用 Collections.max() 处理，会触发频繁 GC、占用大量堆内存，还可能 OOM。而 SELECT MAX(amount) FROM orders WHERE status = 'paid' 只返回一个数字，数据库能利用索引（如 INDEX(status, amount)）快速定位，IO 和网络传输都最小化。
- 适用场景：实时看板的指标展示、分页列表顶部的“历史最高价”提示、风控规则中对单字段极值的判断
- 关键细节：确保查询条件能命中索引，否则
MAX()仍要全表扫描；若需同时获取最大值对应整行记录，用ORDER BY ... LIMIT 1比子查询更高效
混合策略：分阶段下推 + 应用层兜底
真实业务常需平衡响应速度与结果精度。例如电商比价系统：先查各品类最近 1000 笔成交价的 MAX()（带时间范围和索引），再在应用层合并多个品类结果取全局最大；若某品类无数据，用默认值或缓存兜底，避免因单点数据库延迟拖垮整个接口。
- 典型做法：数据库做粗粒度过滤（按时间/状态/分区下推），应用层做细粒度逻辑（如加权计算、业务规则排除异常值）
- 风险提示：跨库或分库场景下，
MAX()无法跨物理节点执行，必须由应用层归并；此时应明确分片键语义，避免误判
性能验证不能只看单次耗时
压测时发现 Collections.max() 单次快 2ms，但并发 500 时 JVM 堆使用率飙升 40%，而数据库 MAX() 在连接池满时开始排队——这说明瓶颈不在算法，而在资源维度。应监控 GC 时间、数据库连接等待数、网络吞吐，再结合业务 SLA（比如“99% 请求
- 建议动作：对高频极值查询建覆盖索引；给
Collections.max()使用场景设集合大小阈值（如 > 5000 自动切数据库） - 工具辅助：用 Arthas 观察 List 创建和遍历栈帧，用慢日志 +
EXPLAIN对齐数据库执行计划
