您的熔断器止步于服务层。慢查询 SQL 也需要一个。
单个慢查询可能在几秒钟内拖垮整个服务。本文从一次生产环境的级联故障说起，逐步介绍我如何构建一个 Spring Boot 启动器，在 MyBatis 拦截器层实现熔断，以 SQL 类型 + SQL 指纹为键——此外还探讨了一些值得讨论的设计权衡。该软件开发工具包（SDK）已开源，发布在 Maven 中央仓库，只需添加一个依赖项并配置少量 YAML 即可接入。
1. 一段简短的实战经历：单个慢查询如何拖垮服务
在一个流量高峰期的傍晚，订单服务开始处处超时，警报频发。根本原因很平常：一个列表查询新增了一个未被索引覆盖的过滤条件，导致全表扫描，每次调用耗时超过 30 秒。
问题在于，这并不会止步于“慢一次”：
- 一个慢查询会占用数据库连接长达 30 秒。
- 在高负载下，更多相同的请求不断涌入，逐个消耗连接。
- 连接池耗尽 → 所有其他查询（包括完全健康的查询）都无法获取连接，排队等待，最终超时。
- 上游线程全部阻塞等待连接 → 接口超时 → 调用方重试 → 情况恶化。
单个慢查询最终拖垮了整个数据库，以及整个服务。
在事后复盘中，第一反应是：“我们不是已经有熔断器了吗？”
2. 为什么常规熔断器不够用
Resilience4j、Hystrix、Sentinel —— 都很成熟。但它们运行在端点 / 远程过程调用（RPC）/ 方法调用级别。它们可以告诉您“此端点的失败率很高，触发熔断”，但它们不理解 SQL：
- 它们不知道哪个查询很慢 —— 它们只能熔断整个端点，即使背后 90% 的 SQL
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
