Java高频面试考点18

千万级表深分页查询的优化方法可从技术与业务层面逐层推进。

深分页问题解析：MySQL 执行 LIMIT 1000000 时，会先扫描一百万零十条数据，再丢弃前一百万条；若用 SELECT*，还会触发一百万次回表，产生海量 IO 与 CPU 开销。
延迟关联优化：先通过子查询仅查主键 ID（利用覆盖索引避免回表），再用 ID 与原表关联获取完整数据，减少无用回表操作。
游标分页优化：针对瀑布流场景，前端传递上一页最后一条记录的 ID，后端用 WHERE id>last_id LIMIT 10 查询，直接走 B + 树查找，时间复杂度为 O (logN)。
多维度查询优化：多条件组合且需跳页的场景，将数据同步到 Elasticsearch，用 Scroll 或 Search_After 游标查询；ES 默认限制 10000 条深分页，超量会报错。
业务层面优化：限制最大查询页码或要求用户输入更精确条件，从业务源头解决技术瓶颈。

技术为业务服务，从业务端优化是高级解决思路。

场景案例：用户画像服务批量查询 100 个 ID，突然从 200 毫秒涨到 3 秒超时，数据库、CPU、GC 均无异常，卡在 HTTP 请求执行环节。
问题根源：连接池最大为 20，同时进来 200 个请求，每个请求调用 100 次外部服务，导致连接池耗尽，请求排队等待连接。
根因定位方法：用 Arthas 的 trace 命令追踪调用链，区分连接获取与请求耗时；查看 HTTP 连接池 list、pending 指标；用 jstack 看线程堆栈，大量线程卡在连接池等待方法即可确认。
事前防御措施：压测模拟多路并发抢连接场景，监控连接池指标并设置告警；代码审查强制统一连接池配置，禁止每次调用新建客户端。
代码层优化：合理设置连接池参数，根据业务峰值调整 max per route；使用异步 HTTP 客户端，单个连接并发处理多请求；合并外部调用，一次批量传参；配置连接、请求超时，开启空闲连接清理。

该题考查开发者对外部调用资源竞争问题的认知能力。

核心错误：粉丝面试时将 INT (11) 理解为可存储 11 位整数，被面试官淘汰。

存储规则：INT 类型无论括号内数字是 4 还是 11，均占用 4 个字节，存储范围固定为负 21 亿到正 21 亿。

显示宽度作用：仅影响查询结果的显示形式，如 INT (4) 加 ZEROFILL 会显示 0022，不加则补空格。

版本变化：MySQL 8.0 开始废弃显示宽度，仅在使用 ZEROFILL 时仍有效。

视频给出了应对该问题的三句关键结论，同时提及整理的 Java 面试必考题库。

调优思路：调优分为 SQL 调优和执行环节调优，需先本地用 explain 查看执行计划，再到线上看实际执行时间。

常见误区：需排除缓存干扰，MySQL8.0 前加 sql_no_cache 查看真实查询时间；explain 统计数据可能因数据变化失效，需用 analyze table 重新统计或强制走正确索引。

索引核心：覆盖索引可避免回表；联合索引需遵循最左匹配原则；索引下推能减少回表数据；写多业务用普通索引比唯一索引性能更优；长字段用前缀索引可省空间。

其他细节：MySQL 卡顿可能是刷脏页，8.0 版本 innodb_flush_neighbors 默认设为 0 适配固态硬盘。

调优核心是找瓶颈和避坑，掌握后能应对面试和实际工作。

首次拉取配置：应用启动时通过 HTTP 请求向 Nacos 服务端拉取配置，将配置缓存至本地内存以减少网络开销，同时持久化到本地磁盘，避免重启时依赖网络。

配置变更同步：客户端通过长轮询机制保持配置同步，默认等待 30 秒，期间配置变更则服务端立即返回更新，无变更则返回空响应，客户端再发起新请求。

监听器触发：客户端获取配置更新后，更新本地内存和磁盘文件，触发监听器执行自定义逻辑，如刷新属性值或重新初始化组件。

视频通过具体场景展示了 Nacos 配置同步的核心机制与面试应答要点。

错误做法：视频指出直接使用 MD5、SHA1 等快哈希算法不安全，黑客可通过彩虹表快速破解；加固定盐的哈希同样存在风险，盐泄露后仍可批量破解。

正确方案：推荐使用 BCrypt、Argon2、PBKDF2 等慢哈希算法，这类算法自带随机盐、计算速度慢且可调整算力成本，能有效提升破解难度。

全链路安全：除存储外，需通过 HTTPS 传输、前后端密码复杂度校验、输错锁定、权限最小化等措施保障敏感数据安全。

视频强调 Java 生态中 Spring Security 框架已集成上述安全算法，开发者可直接使用。