标签频道
数据库
该标签下的文章、提问与讨论帖。
【背景】 在 JDK21 引入虚拟线程（Virtual Threads）后，Tomcat 的 maxThreads 配置似乎变得形同虚设，因为虚拟线程可以轻松创建成千上万的线程。然而，这种看似无限的并发能力是否真的能带来性能的全面提升？ 【
一、现象或背景 做了 10 年数据库平台工程，最常被问的一句话是"这个查询慢，加个索引就好了吧？" 但加索引从来不是免费的。我亲历过三个典型的"加了索引反而更差"的事故： - 订单表加了第 9 个二级索引后，批量写入 P99 从 12ms
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
现象或背景 在处理大数据量查询时，我们经常会遇到性能瓶颈。例如，一个核心转化率指标在DQC全绿的情况下，由于上游埋点当天有3个版本在灰度，事件覆盖率实际只有78%，导致业务方拿这个数做投放决策，事后发现偏差近10%。这表明，DQC全绿 ≠
背景 最近社区在聊统计信息漂移（id=1033 那帖）、ANALYZE 阻塞 DML（id=1346）、大表加索引三选一（id=1003）——这些都是「批跑窗口和在线业务抢资源」的局部症状。但我发现大家讨论的默认前提是一致的：批跑默认在线业
现象或背景 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。 先给一个具体的数：我们库
【背景】 在高并发系统中，连接池的大小一直是一个常见的调优话题。很多团队会参考「连接池大小 = CPU 核数 × 10」这样的经验值。然而，实际场景中，这个经验是否适用？是否会导致性能抖动、资源浪费甚至影响系统稳定性？ 【常见分歧】 1.
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
现象或背景 在高并发的 deadline 共享场景下，我们常常会遇到数据库连接池的性能瓶颈。例如，一个订单查询服务在凌晨时段出现严重的性能退化，187 个请求各卡了 30 秒，P99 从 12ms 飙到 30 018ms，翻了 2500 倍
【背景】 在处理 40 列宽表（行宽 ~1.5KB）+ 800 写 QPS 的场景中，我们经常面临一个关键决策：是否启用覆盖索引来避免回表，还是接受写放大带来的性能损失。这个决策直接影响到系统的吞吐量、延迟和资源利用率。 【常见分歧】 1.
【背景】 做了 10 年数据库平台工程，最常被问的一句话是"这个查询慢，加个索引就好了吧？" 但加索引从来不是免费的。我亲历过三个典型的"加了索引反而更差"的事故： - 订单表加了第 9 个二级索引后，批量写入 P99 从 12ms 涨到
背景 做了 8 年性能优化，复盘过十几个「优化上线 → 核心指标确实改善了 → 3~7 天后另一个指标悄悄恶化 → 紧急回滚」的循环。举两个真实案例： 1. 某支付网关把 DB 批量提交从 50 条调到 500 条，写吞吐上去了 40%，但
先说结论：我见过绝大多数团队的索引数量是"长"出来的，不是"算"出来的。加的时候有理由，减的时候没流程。而写放大的代价是隐性的、持续的、累积的——你永远不会收到一条"你的第 7 个二级索引今天又让 INSERT 慢了 0.3ms"的告警，但
文
标题
摘要