[{"data":1,"prerenderedAt":16071},["ShallowReactive",2],{"java:java-thread-pool-core-parameters-and-practice\u002F":3,"java-wiki-navigation":1656},{"id":4,"title":5,"body":6,"commentId":1643,"description":1644,"difficulty":1645,"draft":1646,"extension":1647,"meta":1648,"navigation":780,"order":1649,"path":1650,"section":1651,"seo":1652,"stem":1653,"updated":1654,"__hash__":1655},"java\u002Fjava\u002Fjava-thread-pool-core-parameters-and-practice.md","Java 线程池核心参数有哪些？日常应该怎么使用？",{"type":7,"value":8,"toc":1599},"minimark",[9,13,17,53,56,59,62,71,74,88,91,95,98,114,117,127,131,134,191,196,201,204,213,216,225,231,235,240,243,249,254,258,264,272,281,284,287,295,299,307,324,327,331,337,340,419,422,439,442,446,451,465,468,474,477,481,484,487,559,562,566,569,578,583,589,592,595,599,602,608,611,617,623,632,636,640,643,646,652,655,659,662,668,671,677,680,697,700,704,707,722,725,731,734,738,741,1082,1085,1109,1112,1116,1122,1126,1129,1135,1139,1145,1151,1162,1168,1172,1175,1183,1198,1201,1210,1242,1254,1258,1261,1264,1270,1273,1290,1293,1297,1300,1406,1409,1429,1432,1436,1446,1452,1455,1461,1467,1471,1475,1478,1482,1485,1489,1494,1498,1501,1505,1516,1520,1523,1527,1568,1571,1595],[10,11,5],"h1",{"id":12},"java-线程池核心参数有哪些日常应该怎么使用",[14,15,16],"h2",{"id":16},"面试回答",[18,19,20,24,25,28,29,32,33,36,37,40,41,44,45,48,49,52],"p",{},[21,22,23],"code",{},"ThreadPoolExecutor"," 有七个核心参数：核心线程数 ",[21,26,27],{},"corePoolSize","、最大线程数 ",[21,30,31],{},"maximumPoolSize","、非核心线程空闲存活时间 ",[21,34,35],{},"keepAliveTime","、时间单位 ",[21,38,39],{},"unit","、任务队列 ",[21,42,43],{},"workQueue","、线程工厂 ",[21,46,47],{},"threadFactory"," 和拒绝策略 ",[21,50,51],{},"handler","。",[18,54,55],{},"提交任务后，线程池先判断当前工作线程数是否小于核心线程数，是则创建线程执行；否则尝试将任务放入队列。队列已满时，如果线程数还没有达到最大线程数，就继续创建非核心线程；线程数达到最大值后仍无法接收任务，才执行拒绝策略。因此，最大线程数是否生效与队列是否有界密切相关。",[18,57,58],{},"日常使用时，应根据任务是 CPU 密集型还是 I\u002FO 密集型划分独立线程池，明确核心线程数、最大线程数和有界队列，设置有业务含义的线程名，并根据业务选择可观测、可补偿的拒绝策略。同时监控活跃线程数、队列长度、拒绝次数、排队耗时和执行耗时，应用停止时进行优雅关闭。线程数和队列容量不能只靠固定公式决定，还要结合机器 CPU、任务等待与计算比例、下游容量及允许的业务延迟进行压测和调整。",[18,60,61],{},"一句话总结：",[63,64,65],"blockquote",{},[18,66,67],{},[68,69,70],"strong",{},"线程池用有限的线程和队列承接任务；日常配置的核心不是把参数设大，而是明确资源上限、过载行为和监控补偿机制。",[14,72,73],{"id":73},"一张图看懂",[18,75,76],{},[77,78,84],"a",{"href":79,"target":80,"rel":81},"\u002Fimages\u002Fwiki\u002Fjava\u002Fjava-thread-pool-core-parameters-and-practice.svg","_blank",[82,83],"noopener","noreferrer",[85,86],"img",{"src":79,"alt":87},"Java 线程池七个核心参数、任务提交流程和日常使用原则",[14,89,90],{"id":90},"详细讲解",[14,92,94],{"id":93},"一为什么使用线程池","一、为什么使用线程池",[18,96,97],{},"如果每个任务都创建一个新线程，会带来以下问题：",[99,100,101,105,108,111],"ul",{},[102,103,104],"li",{},"创建和销毁线程需要消耗时间与内存；",[102,106,107],{},"线程数量缺少上限，突发流量可能耗尽系统资源；",[102,109,110],{},"大量线程会增加上下文切换和调度开销；",[102,112,113],{},"无法统一管理任务排队、拒绝、监控和关闭。",[18,115,116],{},"线程池的核心价值不是单纯复用线程，而是对并发资源进行治理：",[118,119,125],"pre",{"className":120,"code":122,"language":123,"meta":124},[121],"language-text","控制线程数量\n+ 缓冲暂时处理不了的任务\n+ 定义系统过载时的行为\n+ 统一监控和生命周期管理\n","text","",[21,126,122],{"__ignoreMap":124},[14,128,130],{"id":129},"二threadpoolexecutor-的七个核心参数","二、ThreadPoolExecutor 的七个核心参数",[18,132,133],{},"常用构造方法如下：",[118,135,139],{"className":136,"code":137,"language":138,"meta":124,"style":124},"language-java shiki shiki-themes github-light github-dark","public ThreadPoolExecutor(\n int corePoolSize,\n int maximumPoolSize,\n long keepAliveTime,\n TimeUnit unit,\n BlockingQueue\u003CRunnable> workQueue,\n ThreadFactory threadFactory,\n RejectedExecutionHandler handler)\n","java",[21,140,141,149,155,161,167,173,179,185],{"__ignoreMap":124},[142,143,146],"span",{"class":144,"line":145},"line",1,[142,147,148],{},"public ThreadPoolExecutor(\n",[142,150,152],{"class":144,"line":151},2,[142,153,154],{}," int corePoolSize,\n",[142,156,158],{"class":144,"line":157},3,[142,159,160],{}," int maximumPoolSize,\n",[142,162,164],{"class":144,"line":163},4,[142,165,166],{}," long keepAliveTime,\n",[142,168,170],{"class":144,"line":169},5,[142,171,172],{}," TimeUnit unit,\n",[142,174,176],{"class":144,"line":175},6,[142,177,178],{}," BlockingQueue\u003CRunnable> workQueue,\n",[142,180,182],{"class":144,"line":181},7,[142,183,184],{}," ThreadFactory threadFactory,\n",[142,186,188],{"class":144,"line":187},8,[142,189,190],{}," RejectedExecutionHandler handler)\n",[192,193,195],"h3",{"id":194},"_1-corepoolsize核心线程数","1. corePoolSize：核心线程数",[18,197,198,200],{},[21,199,27],{}," 表示线程池希望长期保留的基本工作线程数量。",[18,202,203],{},"默认情况下，核心线程也不是在线程池创建时立即启动，而是在任务到来后按需创建。需要提前完成线程创建时，可以调用：",[118,205,207],{"className":136,"code":206,"language":138,"meta":124,"style":124},"threadPool.prestartAllCoreThreads();\n",[21,208,209],{"__ignoreMap":124},[142,210,211],{"class":144,"line":145},[142,212,206],{},[18,214,215],{},"核心线程默认不会因为空闲而退出。调用以下方法后，核心线程也可以受空闲超时控制：",[118,217,219],{"className":136,"code":218,"language":138,"meta":124,"style":124},"threadPool.allowCoreThreadTimeOut(true);\n",[21,220,221],{"__ignoreMap":124},[142,222,223],{"class":144,"line":145},[142,224,218],{},[18,226,227,228,230],{},"此时 ",[21,229,35],{}," 必须大于零。",[192,232,234],{"id":233},"_2-maximumpoolsize最大线程数","2. maximumPoolSize：最大线程数",[18,236,237,239],{},[21,238,31],{}," 是线程池允许存在的最大工作线程数量，必须大于或等于核心线程数。",[18,241,242],{},"它并不是任务一多就立即生效。只有满足以下条件时，线程池才会创建超过核心数量的线程：",[118,244,247],{"className":245,"code":246,"language":123,"meta":124},[121],"核心线程都在工作\n+ workQueue 已满\n+ 当前线程数小于 maximumPoolSize\n",[21,248,246],{"__ignoreMap":124},[18,250,251,252,52],{},"如果使用不会被填满的无界队列，任务会持续进入队列，线程池通常不会扩展到 ",[21,253,31],{},[192,255,257],{"id":256},"_3-keepalivetime空闲线程存活时间","3. keepAliveTime：空闲线程存活时间",[18,259,260,261,263],{},"当工作线程数量超过 ",[21,262,27],{}," 时，多出来的线程如果在指定时间内没有获取到任务，就会被回收。",[18,265,266,268,269,271],{},[21,267,35],{}," 决定空闲等待时长，",[21,270,39],{}," 决定它的时间单位：",[118,273,275],{"className":136,"code":274,"language":138,"meta":124,"style":124},"60L, TimeUnit.SECONDS\n",[21,276,277],{"__ignoreMap":124},[142,278,279],{"class":144,"line":145},[142,280,274],{},[18,282,283],{},"它们共同表示空闲线程最多等待 60 秒。",[18,285,286],{},"该参数是在以下两者之间取舍：",[99,288,289,292],{},[102,290,291],{},"设置较短：流量下降后能更快释放线程资源，但下一次突发流量需要重新创建线程；",[102,293,294],{},"设置较长：可以减少线程反复创建，但空闲线程会占用更多内存。",[192,296,298],{"id":297},"_4-unit时间单位","4. unit：时间单位",[18,300,301,303,304,306],{},[21,302,39],{}," 是 ",[21,305,35],{}," 的单位，常用值包括：",[99,308,309,314,319],{},[102,310,311],{},[21,312,313],{},"TimeUnit.MILLISECONDS",[102,315,316],{},[21,317,318],{},"TimeUnit.SECONDS",[102,320,321],{},[21,322,323],{},"TimeUnit.MINUTES",[18,325,326],{},"把时间值和单位拆开传入，可以避免代码中出现含义不清的裸数字。",[192,328,330],{"id":329},"_5-workqueue任务队列","5. workQueue：任务队列",[18,332,333,334,336],{},"当核心线程都在工作时，新任务会先尝试进入 ",[21,335,43],{}," 等待，而不是立即创建非核心线程。",[18,338,339],{},"常见队列如下：",[341,342,343,359],"table",{},[344,345,346],"thead",{},[347,348,349,353,356],"tr",{},[350,351,352],"th",{},"队列",[350,354,355],{},"特点",[350,357,358],{},"适用场景与注意事项",[360,361,362,376,393,406],"tbody",{},[347,363,364,370,373],{},[365,366,367],"td",{},[21,368,369],{},"ArrayBlockingQueue",[365,371,372],{},"基于数组的有界队列，容量固定",[365,374,375],{},"资源边界明确，适合大多数需要控制积压的服务端任务",[347,377,378,383,386],{},[365,379,380],{},[21,381,382],{},"LinkedBlockingQueue",[365,384,385],{},"基于链表，可指定容量",[365,387,388,389,392],{},"不传容量时上限为 ",[21,390,391],{},"Integer.MAX_VALUE","，容易隐藏长期积压",[347,394,395,400,403],{},[365,396,397],{},[21,398,399],{},"SynchronousQueue",[365,401,402],{},"不保存任务，每次提交都直接移交给工作线程",[365,404,405],{},"适合希望快速扩展线程、任务很短且能够严格控制最大线程数的场景",[347,407,408,413,416],{},[365,409,410],{},[21,411,412],{},"PriorityBlockingQueue",[365,414,415],{},"按优先级取任务，通常是无界队列",[365,417,418],{},"任务需要可比较；要防止低优先级任务长期得不到执行",[18,420,421],{},"队列容量并非越大越好。大队列虽然能暂时降低拒绝次数，却可能带来：",[99,423,424,427,430,433,436],{},[102,425,426],{},"任务排队时间不断增长；",[102,428,429],{},"内存占用上升；",[102,431,432],{},"故障被延迟暴露；",[102,434,435],{},"应用关闭时遗留大量未完成任务；",[102,437,438],{},"请求已经失去业务时效后仍在执行。",[18,440,441],{},"有界队列能够让系统在达到承载上限时尽早进入明确的过载处理流程。",[192,443,445],{"id":444},"_6-threadfactory线程工厂","6. threadFactory：线程工厂",[18,447,448,450],{},[21,449,47],{}," 负责创建工作线程，可以统一设置：",[99,452,453,456,459,462],{},[102,454,455],{},"线程名称；",[102,457,458],{},"是否为守护线程；",[102,460,461],{},"线程优先级；",[102,463,464],{},"未捕获异常处理器。",[18,466,467],{},"线程名应体现业务用途，例如：",[118,469,472],{"className":470,"code":471,"language":123,"meta":124},[121],"order-notify-1\norder-notify-2\n",[21,473,471],{"__ignoreMap":124},[18,475,476],{},"出现高 CPU、死锁或任务堆积时，有业务含义的线程名能显著降低线程栈排查成本。",[192,478,480],{"id":479},"_7-handler拒绝策略","7. handler：拒绝策略",[18,482,483],{},"当线程池没有运行，或者同时满足“线程数达到最大值、任务队列已满”时，新任务会被拒绝。",[18,485,486],{},"JDK 提供四种常用策略：",[341,488,489,502],{},[344,490,491],{},[347,492,493,496,499],{},[350,494,495],{},"策略",[350,497,498],{},"行为",[350,500,501],{},"适用提醒",[360,503,504,520,533,546],{},[347,505,506,511,517],{},[365,507,508],{},[21,509,510],{},"AbortPolicy",[365,512,513,514],{},"抛出 ",[21,515,516],{},"RejectedExecutionException",[365,518,519],{},"默认策略，能够明确暴露过载，调用方需要处理异常",[347,521,522,527,530],{},[365,523,524],{},[21,525,526],{},"CallerRunsPolicy",[365,528,529],{},"由提交任务的线程直接执行",[365,531,532],{},"可以减慢生产者形成一定反压，但会增加调用线程延迟",[347,534,535,540,543],{},[365,536,537],{},[21,538,539],{},"DiscardPolicy",[365,541,542],{},"静默丢弃新任务",[365,544,545],{},"只适合明确允许丢弃且有独立监控的低价值任务",[347,547,548,553,556],{},[365,549,550],{},[21,551,552],{},"DiscardOldestPolicy",[365,554,555],{},"丢弃队列头任务，再尝试提交新任务",[365,557,558],{},"可能丢掉等待最久或优先级最高的任务，使用前必须确认业务语义",[18,560,561],{},"拒绝策略没有适用于所有业务的统一答案。核心交易任务通常不能静默丢弃，可以抛出异常后进入降级、补偿或持久化重试；允许采样的日志、指标任务才可能接受丢弃。",[14,563,565],{"id":564},"三任务提交后的完整流程","三、任务提交后的完整流程",[18,567,568],{},"调用：",[118,570,572],{"className":136,"code":571,"language":138,"meta":124,"style":124},"threadPool.execute(task);\n",[21,573,574],{"__ignoreMap":124},[142,575,576],{"class":144,"line":145},[142,577,571],{},[18,579,580,582],{},[21,581,23],{}," 的处理流程可以概括为：",[118,584,587],{"className":585,"code":586,"language":123,"meta":124},[121],"1. 当前工作线程数小于 corePoolSize\n → 创建核心工作线程执行任务\n\n2. 当前工作线程数已达到 corePoolSize\n → 尝试将任务加入 workQueue\n\n3. workQueue 已满，且工作线程数小于 maximumPoolSize\n → 创建非核心工作线程执行任务\n\n4. workQueue 已满，且工作线程数已达到 maximumPoolSize\n → 执行拒绝策略\n",[21,588,586],{"__ignoreMap":124},[18,590,591],{},"任务成功入队后，线程池还会再次检查运行状态。如果线程池在入队期间已经停止，会尝试移除该任务并拒绝；如果池中没有工作线程，则会补充一个工作线程负责消费队列。",[18,593,594],{},"这个二次检查避免了任务已经进入队列，却因为线程池状态变化或没有消费者而一直得不到执行。",[14,596,598],{"id":597},"四队列与最大线程数如何相互影响","四、队列与最大线程数如何相互影响",[18,600,601],{},"假设配置如下：",[118,603,606],{"className":604,"code":605,"language":123,"meta":124},[121],"corePoolSize = 8\nmaximumPoolSize = 16\nworkQueue 容量 = 500\n",[21,607,605],{"__ignoreMap":124},[18,609,610],{},"任务增长过程是：",[118,612,615],{"className":613,"code":614,"language":123,"meta":124},[121],"前 8 个并发任务\n→ 创建至 8 个核心线程\n\n核心线程忙碌后的新任务\n→ 最多 500 个进入队列\n\n队列满后的新任务\n→ 继续创建线程，最多扩展到 16 个\n\n16 个线程都忙且队列仍满\n→ 触发拒绝策略\n",[21,616,614],{"__ignoreMap":124},[18,618,619,620,622],{},"如果把队列改成默认构造的 ",[21,621,382],{},"，它的容量接近无界，任务通常只会继续排队，线程数量很难从 8 扩展到 16。",[18,624,625,626,628,629,631],{},"因此不能孤立地解释 ",[21,627,31],{},"，必须和 ",[21,630,43],{}," 一起分析。",[14,633,635],{"id":634},"五线程数应该怎么估算","五、线程数应该怎么估算",[192,637,639],{"id":638},"_1-cpu-密集型任务","1. CPU 密集型任务",[18,641,642],{},"CPU 密集型任务的大部分时间都在执行计算，例如加密、压缩、图像处理和复杂规则计算。",[18,644,645],{},"可以把下面的数值作为初始估算：",[118,647,650],{"className":648,"code":649,"language":123,"meta":124},[121],"线程数 ≈ CPU 核数 + 1\n",[21,651,649],{"__ignoreMap":124},[18,653,654],{},"线程数明显超过 CPU 并行能力，通常只会增加上下文切换，并不会线性提升吞吐。",[192,656,658],{"id":657},"_2-io-密集型任务","2. I\u002FO 密集型任务",[18,660,661],{},"I\u002FO 密集型任务会花较多时间等待数据库、网络、文件或远程服务，可以用以下公式进行初始估算：",[118,663,666],{"className":664,"code":665,"language":123,"meta":124},[121],"线程数 ≈ CPU 核数 ×（1 + 平均等待时间 ÷ 平均计算时间）\n",[21,667,665],{"__ignoreMap":124},[18,669,670],{},"例如任务平均计算 10 毫秒、等待下游 40 毫秒，机器有 8 个 CPU 核：",[118,672,675],{"className":673,"code":674,"language":123,"meta":124},[121],"8 ×（1 + 40 ÷ 10）= 40\n",[21,676,674],{"__ignoreMap":124},[18,678,679],{},"40 只能作为起始测试值，不能直接当作生产结论。真实上限还受以下因素约束：",[99,681,682,685,688,691,694],{},[102,683,684],{},"数据库连接池只有多少连接；",[102,686,687],{},"下游接口允许多少并发；",[102,689,690],{},"单任务占用多少内存；",[102,692,693],{},"机器 CPU、内存和网络容量；",[102,695,696],{},"业务允许的超时和排队时长。",[18,698,699],{},"如果数据库连接池只有 20 个可用连接，把线程池配置成 200 个线程，往往只是让更多线程阻塞在等待连接上。",[192,701,703],{"id":702},"_3-队列容量怎么定","3. 队列容量怎么定",[18,705,706],{},"队列容量应结合四个维度：",[708,709,710,713,716,719],"ol",{},[102,711,712],{},"高峰任务到达速率；",[102,714,715],{},"线程池稳定处理速率；",[102,717,718],{},"业务允许的最大排队时间；",[102,720,721],{},"单个排队任务占用的内存。",[18,723,724],{},"假设高峰期每秒比稳定处理能力多出 100 个任务，业务最多允许这种峰值持续 3 秒，可以从约 300 个队列容量开始评估：",[118,726,729],{"className":727,"code":728,"language":123,"meta":124},[121],"暂时积压量\n≈（任务到达速率－稳定处理速率）× 峰值持续时间\n",[21,730,728],{"__ignoreMap":124},[18,732,733],{},"还必须验证队列排满时的内存占用和最老任务等待时间。容量评估的目标不是永不拒绝，而是在允许的延迟和资源范围内吸收短时突发。",[14,735,737],{"id":736},"六日常推荐写法","六、日常推荐写法",[18,739,740],{},"下面是一个边界清晰的业务线程池示例：",[118,742,744],{"className":136,"code":743,"language":138,"meta":124,"style":124},"import java.util.concurrent.ArrayBlockingQueue;\nimport java.util.concurrent.RejectedExecutionException;\nimport java.util.concurrent.ThreadFactory;\nimport java.util.concurrent.ThreadPoolExecutor;\nimport java.util.concurrent.TimeUnit;\nimport java.util.concurrent.atomic.AtomicInteger;\n\npublic final class OrderAsyncExecutor {\n\n private static final AtomicInteger THREAD_ID = new AtomicInteger();\n\n private static final ThreadFactory THREAD_FACTORY = task -> {\n Thread thread = new Thread(\n task,\n \"order-async-\" + THREAD_ID.incrementAndGet()\n );\n thread.setUncaughtExceptionHandler((currentThread, error) ->\n System.err.println(\n currentThread.getName() + \": \" + error.getMessage()\n )\n );\n return thread;\n };\n\n private static final ThreadPoolExecutor EXECUTOR =\n new ThreadPoolExecutor(\n 8,\n 16,\n 60L,\n TimeUnit.SECONDS,\n new ArrayBlockingQueue\u003C>(500),\n THREAD_FACTORY,\n new ThreadPoolExecutor.AbortPolicy()\n );\n\n private OrderAsyncExecutor() {\n }\n\n public static void execute(Runnable task) {\n try {\n EXECUTOR.execute(task);\n } catch (RejectedExecutionException exception) {\n \u002F\u002F 根据业务接入告警、降级、持久化重试或补偿流程\n throw exception;\n }\n }\n\n public static void shutdown() {\n EXECUTOR.shutdown();\n try {\n if (!EXECUTOR.awaitTermination(30, TimeUnit.SECONDS)) {\n EXECUTOR.shutdownNow();\n }\n } catch (InterruptedException exception) {\n EXECUTOR.shutdownNow();\n Thread.currentThread().interrupt();\n }\n }\n}\n",[21,745,746,751,756,761,766,771,776,782,787,792,798,803,809,815,821,827,833,839,845,851,857,862,868,874,879,885,891,897,903,909,915,921,927,933,939,944,950,956,961,967,973,979,985,991,997,1003,1008,1013,1019,1025,1030,1036,1042,1048,1054,1060,1066,1071,1076],{"__ignoreMap":124},[142,747,748],{"class":144,"line":145},[142,749,750],{},"import java.util.concurrent.ArrayBlockingQueue;\n",[142,752,753],{"class":144,"line":151},[142,754,755],{},"import java.util.concurrent.RejectedExecutionException;\n",[142,757,758],{"class":144,"line":157},[142,759,760],{},"import java.util.concurrent.ThreadFactory;\n",[142,762,763],{"class":144,"line":163},[142,764,765],{},"import java.util.concurrent.ThreadPoolExecutor;\n",[142,767,768],{"class":144,"line":169},[142,769,770],{},"import java.util.concurrent.TimeUnit;\n",[142,772,773],{"class":144,"line":175},[142,774,775],{},"import java.util.concurrent.atomic.AtomicInteger;\n",[142,777,778],{"class":144,"line":181},[142,779,781],{"emptyLinePlaceholder":780},true,"\n",[142,783,784],{"class":144,"line":187},[142,785,786],{},"public final class OrderAsyncExecutor {\n",[142,788,790],{"class":144,"line":789},9,[142,791,781],{"emptyLinePlaceholder":780},[142,793,795],{"class":144,"line":794},10,[142,796,797],{}," private static final AtomicInteger THREAD_ID = new AtomicInteger();\n",[142,799,801],{"class":144,"line":800},11,[142,802,781],{"emptyLinePlaceholder":780},[142,804,806],{"class":144,"line":805},12,[142,807,808],{}," private static final ThreadFactory THREAD_FACTORY = task -> {\n",[142,810,812],{"class":144,"line":811},13,[142,813,814],{}," Thread thread = new Thread(\n",[142,816,818],{"class":144,"line":817},14,[142,819,820],{}," task,\n",[142,822,824],{"class":144,"line":823},15,[142,825,826],{}," \"order-async-\" + THREAD_ID.incrementAndGet()\n",[142,828,830],{"class":144,"line":829},16,[142,831,832],{}," );\n",[142,834,836],{"class":144,"line":835},17,[142,837,838],{}," thread.setUncaughtExceptionHandler((currentThread, error) ->\n",[142,840,842],{"class":144,"line":841},18,[142,843,844],{}," System.err.println(\n",[142,846,848],{"class":144,"line":847},19,[142,849,850],{}," currentThread.getName() + \": \" + error.getMessage()\n",[142,852,854],{"class":144,"line":853},20,[142,855,856],{}," )\n",[142,858,860],{"class":144,"line":859},21,[142,861,832],{},[142,863,865],{"class":144,"line":864},22,[142,866,867],{}," return thread;\n",[142,869,871],{"class":144,"line":870},23,[142,872,873],{}," };\n",[142,875,877],{"class":144,"line":876},24,[142,878,781],{"emptyLinePlaceholder":780},[142,880,882],{"class":144,"line":881},25,[142,883,884],{}," private static final ThreadPoolExecutor EXECUTOR =\n",[142,886,888],{"class":144,"line":887},26,[142,889,890],{}," new ThreadPoolExecutor(\n",[142,892,894],{"class":144,"line":893},27,[142,895,896],{}," 8,\n",[142,898,900],{"class":144,"line":899},28,[142,901,902],{}," 16,\n",[142,904,906],{"class":144,"line":905},29,[142,907,908],{}," 60L,\n",[142,910,912],{"class":144,"line":911},30,[142,913,914],{}," TimeUnit.SECONDS,\n",[142,916,918],{"class":144,"line":917},31,[142,919,920],{}," new ArrayBlockingQueue\u003C>(500),\n",[142,922,924],{"class":144,"line":923},32,[142,925,926],{}," THREAD_FACTORY,\n",[142,928,930],{"class":144,"line":929},33,[142,931,932],{}," new ThreadPoolExecutor.AbortPolicy()\n",[142,934,936],{"class":144,"line":935},34,[142,937,938],{}," );\n",[142,940,942],{"class":144,"line":941},35,[142,943,781],{"emptyLinePlaceholder":780},[142,945,947],{"class":144,"line":946},36,[142,948,949],{}," private OrderAsyncExecutor() {\n",[142,951,953],{"class":144,"line":952},37,[142,954,955],{}," }\n",[142,957,959],{"class":144,"line":958},38,[142,960,781],{"emptyLinePlaceholder":780},[142,962,964],{"class":144,"line":963},39,[142,965,966],{}," public static void execute(Runnable task) {\n",[142,968,970],{"class":144,"line":969},40,[142,971,972],{}," try {\n",[142,974,976],{"class":144,"line":975},41,[142,977,978],{}," EXECUTOR.execute(task);\n",[142,980,982],{"class":144,"line":981},42,[142,983,984],{}," } catch (RejectedExecutionException exception) {\n",[142,986,988],{"class":144,"line":987},43,[142,989,990],{}," \u002F\u002F 根据业务接入告警、降级、持久化重试或补偿流程\n",[142,992,994],{"class":144,"line":993},44,[142,995,996],{}," throw exception;\n",[142,998,1000],{"class":144,"line":999},45,[142,1001,1002],{}," }\n",[142,1004,1006],{"class":144,"line":1005},46,[142,1007,955],{},[142,1009,1011],{"class":144,"line":1010},47,[142,1012,781],{"emptyLinePlaceholder":780},[142,1014,1016],{"class":144,"line":1015},48,[142,1017,1018],{}," public static void shutdown() {\n",[142,1020,1022],{"class":144,"line":1021},49,[142,1023,1024],{}," EXECUTOR.shutdown();\n",[142,1026,1028],{"class":144,"line":1027},50,[142,1029,972],{},[142,1031,1033],{"class":144,"line":1032},51,[142,1034,1035],{}," if (!EXECUTOR.awaitTermination(30, TimeUnit.SECONDS)) {\n",[142,1037,1039],{"class":144,"line":1038},52,[142,1040,1041],{}," EXECUTOR.shutdownNow();\n",[142,1043,1045],{"class":144,"line":1044},53,[142,1046,1047],{}," }\n",[142,1049,1051],{"class":144,"line":1050},54,[142,1052,1053],{}," } catch (InterruptedException exception) {\n",[142,1055,1057],{"class":144,"line":1056},55,[142,1058,1059],{}," EXECUTOR.shutdownNow();\n",[142,1061,1063],{"class":144,"line":1062},56,[142,1064,1065],{}," Thread.currentThread().interrupt();\n",[142,1067,1069],{"class":144,"line":1068},57,[142,1070,1002],{},[142,1072,1074],{"class":144,"line":1073},58,[142,1075,955],{},[142,1077,1079],{"class":144,"line":1078},59,[142,1080,1081],{},"}\n",[18,1083,1084],{},"这个示例体现了几个基本原则：",[99,1086,1087,1090,1093,1096,1099,1102],{},[102,1088,1089],{},"线程池被复用，而不是每次请求临时创建；",[102,1091,1092],{},"核心线程、最大线程和队列容量都有明确上限；",[102,1094,1095],{},"线程名能够定位到业务；",[102,1097,1098],{},"拒绝不会被静默忽略；",[102,1100,1101],{},"停止应用时先等待已有任务完成，超时后再中断；",[102,1103,1104,1105,1108],{},"捕获 ",[21,1106,1107],{},"InterruptedException"," 后恢复当前线程的中断状态。",[18,1110,1111],{},"实际业务应把告警、指标和补偿接入统一基础设施，而不是只输出错误信息。",[14,1113,1115],{"id":1114},"七为什么不建议盲目使用-executors-工厂方法","七、为什么不建议盲目使用 Executors 工厂方法",[18,1117,1118,1121],{},[21,1119,1120],{},"Executors"," 提供的工厂方法使用方便，但部分方法隐藏了重要的资源边界。",[192,1123,1125],{"id":1124},"_1-newfixedthreadpool-和-newsinglethreadexecutor","1. newFixedThreadPool 和 newSingleThreadExecutor",[18,1127,1128],{},"它们使用共享的无界队列。线程数有上限，但任务积压量缺少实际可用的业务上限：",[118,1130,1133],{"className":1131,"code":1132,"language":123,"meta":124},[121],"生产速度长期大于处理速度\n→ 队列持续增长\n→ 排队延迟和内存占用持续上升\n",[21,1134,1132],{"__ignoreMap":124},[192,1136,1138],{"id":1137},"_2-newcachedthreadpool","2. newCachedThreadPool",[18,1140,1141,1142,1144],{},"它使用 ",[21,1143,399],{}," 直接移交任务，并允许按需创建大量线程。任务持续阻塞时，线程数量可能快速增长。",[18,1146,1147,1148,1150],{},"因此在资源敏感的服务端业务中，显式创建 ",[21,1149,23],{}," 通常更容易表达：",[99,1152,1153,1156,1159],{},[102,1154,1155],{},"最多允许多少并发线程；",[102,1157,1158],{},"最多允许积压多少任务；",[102,1160,1161],{},"超出能力后如何处理。",[18,1163,1164,1165,1167],{},"这并不表示所有 ",[21,1166,1120],{}," 方法都不能使用，而是需要先理解其内部参数和运行边界。",[14,1169,1171],{"id":1170},"八execute-和-submit-有什么区别","八、execute 和 submit 有什么区别",[192,1173,1174],{"id":1174},"execute",[118,1176,1177],{"className":136,"code":571,"language":138,"meta":124,"style":124},[21,1178,1179],{"__ignoreMap":124},[142,1180,1181],{"class":144,"line":145},[142,1182,571],{},[99,1184,1185,1192,1195],{},[102,1186,1187,1188,1191],{},"只接收 ",[21,1189,1190],{},"Runnable","；",[102,1193,1194],{},"没有任务结果；",[102,1196,1197],{},"任务抛出的未捕获异常可以到达线程的未捕获异常处理流程。",[192,1199,1200],{"id":1200},"submit",[118,1202,1204],{"className":136,"code":1203,"language":138,"meta":124,"style":124},"Future\u003CResult> future = threadPool.submit(callable);\n",[21,1205,1206],{"__ignoreMap":124},[142,1207,1208],{"class":144,"line":145},[142,1209,1203],{},[99,1211,1212,1221,1228],{},[102,1213,1214,1215,1217,1218,1191],{},"可以接收 ",[21,1216,1190],{}," 或 ",[21,1219,1220],{},"Callable",[102,1222,1223,1224,1227],{},"返回 ",[21,1225,1226],{},"Future","，可以获取结果、等待完成或取消任务；",[102,1229,1230,1231,1233,1234,1237,1238,1241],{},"任务异常会被封装在 ",[21,1232,1226],{}," 中，调用 ",[21,1235,1236],{},"get()"," 时以 ",[21,1239,1240],{},"ExecutionException"," 抛出。",[18,1243,1244,1245,1248,1249,1251,1252,52],{},"如果调用 ",[21,1246,1247],{},"submit()"," 后既不保存 ",[21,1250,1226],{},"，也不检查任务结果，异常很容易被忽略。此时应在任务内部记录异常，或统一检查 ",[21,1253,1226],{},[14,1255,1257],{"id":1256},"九不同类型的任务为什么要隔离线程池","九、不同类型的任务为什么要隔离线程池",[18,1259,1260],{},"把所有异步任务放进同一个线程池，会产生资源相互影响。",[18,1262,1263],{},"例如：",[118,1265,1268],{"className":1266,"code":1267,"language":123,"meta":124},[121],"慢第三方接口占满全部线程\n→ 订单本地计算任务无法执行\n→ 两类本来无关的业务一起超时\n",[21,1269,1267],{"__ignoreMap":124},[18,1271,1272],{},"可以按资源特征或故障域拆分：",[99,1274,1275,1278,1281,1284,1287],{},[102,1276,1277],{},"CPU 计算任务使用计算线程池；",[102,1279,1280],{},"数据库写入任务使用受连接池容量约束的线程池；",[102,1282,1283],{},"慢第三方接口使用独立线程池；",[102,1285,1286],{},"核心交易和非核心通知分开；",[102,1288,1289],{},"不同下游服务使用独立的并发上限。",[18,1291,1292],{},"线程池隔离不是越细越好。线程池过多会增加线程总数和管理成本，应围绕“是否共享同一个资源上限、是否应该相互影响”来划分。",[14,1294,1296],{"id":1295},"十需要监控哪些指标","十、需要监控哪些指标",[18,1298,1299],{},"线程池上线后至少应监控：",[341,1301,1302,1312],{},[344,1303,1304],{},[347,1305,1306,1309],{},[350,1307,1308],{},"指标",[350,1310,1311],{},"说明",[360,1313,1314,1325,1336,1347,1355,1363,1374,1382,1390,1398],{},[347,1315,1316,1322],{},[365,1317,1318,1319],{},"当前线程数 ",[21,1320,1321],{},"poolSize",[365,1323,1324],{},"线程池当前拥有的工作线程数量",[347,1326,1327,1333],{},[365,1328,1329,1330],{},"活跃线程数 ",[21,1331,1332],{},"activeCount",[365,1334,1335],{},"正在执行任务的线程数量",[347,1337,1338,1344],{},[365,1339,1340,1341],{},"历史最大线程数 ",[21,1342,1343],{},"largestPoolSize",[365,1345,1346],{},"是否曾经逼近最大线程数",[347,1348,1349,1352],{},[365,1350,1351],{},"队列长度",[365,1353,1354],{},"当前排队任务数量",[347,1356,1357,1360],{},[365,1358,1359],{},"队列剩余容量",[365,1361,1362],{},"距离队列满还有多少空间",[347,1364,1365,1371],{},[365,1366,1367,1368],{},"已完成任务数 ",[21,1369,1370],{},"completedTaskCount",[365,1372,1373],{},"任务是否持续推进",[347,1375,1376,1379],{},[365,1377,1378],{},"拒绝次数",[365,1380,1381],{},"线程池是否已经过载",[347,1383,1384,1387],{},[365,1385,1386],{},"任务排队耗时",[365,1388,1389],{},"任务从提交到开始执行等待了多久",[347,1391,1392,1395],{},[365,1393,1394],{},"任务执行耗时",[365,1396,1397],{},"业务逻辑自身耗时",[347,1399,1400,1403],{},[365,1401,1402],{},"任务成功率与异常数",[365,1404,1405],{},"是否存在持续失败或异常被吞掉",[18,1407,1408],{},"常见告警信号包括：",[99,1410,1411,1414,1417,1420,1423,1426],{},[102,1412,1413],{},"活跃线程数长时间接近最大线程数；",[102,1415,1416],{},"队列长度持续上升而不是短时波动；",[102,1418,1419],{},"排队耗时接近业务超时时间；",[102,1421,1422],{},"拒绝次数持续增长；",[102,1424,1425],{},"已完成任务数停止增长；",[102,1427,1428],{},"下游连接池和线程池同时耗尽。",[18,1430,1431],{},"只监控线程数量不够。很多线程池故障的第一表现不是线程数异常，而是队列等待时间持续增加。",[14,1433,1435],{"id":1434},"十一如何优雅关闭线程池","十一、如何优雅关闭线程池",[18,1437,1438,1441,1442,1445],{},[21,1439,1440],{},"shutdown()"," 和 ",[21,1443,1444],{},"shutdownNow()"," 的语义不同：",[118,1447,1450],{"className":1448,"code":1449,"language":123,"meta":124},[121],"shutdown()\n→ 不再接收新任务\n→ 继续执行已提交任务\n\nshutdownNow()\n→ 尝试中断正在执行的任务\n→ 返回队列中尚未开始的任务\n",[21,1451,1449],{"__ignoreMap":124},[18,1453,1454],{},"常见关闭流程是：",[118,1456,1459],{"className":1457,"code":1458,"language":123,"meta":124},[121],"调用 shutdown()\n→ 在限定时间内 awaitTermination()\n→ 超时后调用 shutdownNow()\n→ 再等待一次并记录未完成任务\n",[21,1460,1458],{"__ignoreMap":124},[18,1462,1463,1464,1466],{},"任务代码还必须正确响应中断。阻塞调用收到 ",[21,1465,1107],{}," 后，不应随意吞掉中断状态。",[14,1468,1470],{"id":1469},"十二常见误区","十二、常见误区",[192,1472,1474],{"id":1473},"_1-最大线程数越大处理能力越强","1. 最大线程数越大，处理能力越强",[18,1476,1477],{},"线程数量超过 CPU、数据库连接池或下游承载能力后，只会增加竞争、等待和上下文切换。",[192,1479,1481],{"id":1480},"_2-队列越大越不容易出问题","2. 队列越大，越不容易出问题",[18,1483,1484],{},"大队列可能只是把拒绝转化为更长的延迟和更高的内存风险。",[192,1486,1488],{"id":1487},"_3-使用-callerrunspolicy-就解决了限流","3. 使用 CallerRunsPolicy 就解决了限流",[18,1490,1491,1493],{},[21,1492,526],{}," 会让提交线程执行任务，从而减慢生产者，但它不是严格的 QPS 限流器。调用线程可能是 Web 请求线程、消息消费线程或定时调度线程，执行任务会影响这些上游组件的延迟和可用性。",[192,1495,1497],{"id":1496},"_4-threadpoolexecutor-线程安全任务就一定线程安全","4. ThreadPoolExecutor 线程安全，任务就一定线程安全",[18,1499,1500],{},"线程池只负责安全调度任务，不会自动保护任务访问的共享对象。任务内部仍要正确使用锁、原子类、并发容器或不可变对象。",[192,1502,1504],{"id":1503},"_5-submit-后没有异常日志就表示任务成功","5. submit 后没有异常日志，就表示任务成功",[18,1506,1507,1509,1510,1512,1513,1515],{},[21,1508,1247],{}," 会把异常保存到 ",[21,1511,1226],{},"。如果从未调用 ",[21,1514,1236],{}," 或没有统一异常处理，失败可能没有明显日志。",[192,1517,1519],{"id":1518},"_6-线程池能够无限吸收突发流量","6. 线程池能够无限吸收突发流量",[18,1521,1522],{},"线程池只能在有限线程和有限队列范围内吸收波动。持续过载必须通过限流、降级、削峰、扩容或优化下游能力解决。",[14,1524,1526],{"id":1525},"十三日常使用检查清单","十三、日常使用检查清单",[99,1528,1529,1532,1535,1538,1541,1544,1547,1550,1558,1565],{},[102,1530,1531],{},"是否按照任务类型和下游资源进行合理隔离；",[102,1533,1534],{},"是否明确设置线程数和有界队列；",[102,1536,1537],{},"线程数量是否与 CPU、连接池和下游容量匹配；",[102,1539,1540],{},"是否设置可识别的线程名称；",[102,1542,1543],{},"拒绝策略是否符合业务语义；",[102,1545,1546],{},"被拒绝任务是否有告警、降级或补偿；",[102,1548,1549],{},"是否记录排队耗时、执行耗时和拒绝次数；",[102,1551,1552,1554,1555,1557],{},[21,1553,1247],{}," 返回的 ",[21,1556,1226],{}," 是否被正确处理；",[102,1559,1560,1561,1564],{},"任务是否支持中断，是否会泄漏 ",[21,1562,1563],{},"ThreadLocal"," 上下文；",[102,1566,1567],{},"应用关闭时是否执行线程池优雅停止。",[14,1569,1570],{"id":1570},"参考资料",[99,1572,1573,1581,1588],{},[102,1574,1575],{},[77,1576,1580],{"href":1577,"rel":1578},"https:\u002F\u002Fdocs.oracle.com\u002Fjavase\u002F8\u002Fdocs\u002Fapi\u002Fjava\u002Futil\u002Fconcurrent\u002FThreadPoolExecutor.html",[1579],"nofollow","ThreadPoolExecutor Java 8 API",[102,1582,1583],{},[77,1584,1587],{"href":1585,"rel":1586},"https:\u002F\u002Fdocs.oracle.com\u002Fjavase\u002F8\u002Fdocs\u002Fapi\u002Fjava\u002Futil\u002Fconcurrent\u002FExecutors.html",[1579],"Executors Java 8 API",[102,1589,1590],{},[77,1591,1594],{"href":1592,"rel":1593},"https:\u002F\u002Fdocs.oracle.com\u002Fjavase\u002F8\u002Fdocs\u002Fapi\u002Fjava\u002Futil\u002Fconcurrent\u002FRejectedExecutionHandler.html",[1579],"RejectedExecutionHandler Java 8 API",[1596,1597,1598],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":124,"searchDepth":151,"depth":151,"links":1600},[1601,1602,1603,1604,1605,1614,1615,1616,1621,1622,1626,1630,1631,1632,1633,1641,1642],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":93,"depth":151,"text":94},{"id":129,"depth":151,"text":130,"children":1606},[1607,1608,1609,1610,1611,1612,1613],{"id":194,"depth":157,"text":195},{"id":233,"depth":157,"text":234},{"id":256,"depth":157,"text":257},{"id":297,"depth":157,"text":298},{"id":329,"depth":157,"text":330},{"id":444,"depth":157,"text":445},{"id":479,"depth":157,"text":480},{"id":564,"depth":151,"text":565},{"id":597,"depth":151,"text":598},{"id":634,"depth":151,"text":635,"children":1617},[1618,1619,1620],{"id":638,"depth":157,"text":639},{"id":657,"depth":157,"text":658},{"id":702,"depth":157,"text":703},{"id":736,"depth":151,"text":737},{"id":1114,"depth":151,"text":1115,"children":1623},[1624,1625],{"id":1124,"depth":157,"text":1125},{"id":1137,"depth":157,"text":1138},{"id":1170,"depth":151,"text":1171,"children":1627},[1628,1629],{"id":1174,"depth":157,"text":1174},{"id":1200,"depth":157,"text":1200},{"id":1256,"depth":151,"text":1257},{"id":1295,"depth":151,"text":1296},{"id":1434,"depth":151,"text":1435},{"id":1469,"depth":151,"text":1470,"children":1634},[1635,1636,1637,1638,1639,1640],{"id":1473,"depth":157,"text":1474},{"id":1480,"depth":157,"text":1481},{"id":1487,"depth":157,"text":1488},{"id":1496,"depth":157,"text":1497},{"id":1503,"depth":157,"text":1504},{"id":1518,"depth":157,"text":1519},{"id":1525,"depth":151,"text":1526},{"id":1570,"depth":151,"text":1570},"wiki:java:java-thread-pool-core-parameters-and-practice","系统讲解 ThreadPoolExecutor 七个核心参数、任务提交流程、阻塞队列与拒绝策略选择，并给出线程池配置、监控、关闭和容量评估的日常实践。","intermediate",false,"md",{},79,"\u002Fjava\u002Fjava-thread-pool-core-parameters-and-practice","面试专题",{"title":5,"description":1644},"java\u002Fjava-thread-pool-core-parameters-and-practice","2026-07-26","yNwjZJfkON3rxGgiYoS--PURnpgITCoIe0k-VMrtxwI",[1657,3071,3989,5175,6192,7535,8975,10019,13763,14926],{"id":1658,"title":1659,"body":1660,"commentId":3061,"description":3062,"difficulty":3063,"draft":1646,"extension":1647,"meta":3064,"navigation":780,"order":941,"path":3065,"section":3066,"seo":3067,"stem":3068,"updated":3069,"__hash__":3070},"java\u002Fjava\u002Fjdk8-synchronized-lock-states.md","JDK 8 synchronized 设计与锁状态转换",{"type":7,"value":1661,"toc":3004},[1662,1666,1672,1683,1686,1692,1695,1697,1706,1711,1714,1719,1725,1729,1732,1738,1745,1748,1754,1757,1760,1808,1812,1815,1821,1827,1830,1839,1844,1848,1855,1869,1983,1989,1995,1998,2001,2007,2010,2014,2020,2023,2029,2036,2039,2072,2076,2079,2082,2085,2089,2092,2095,2102,2105,2110,2114,2117,2123,2126,2129,2132,2138,2141,2144,2147,2153,2156,2162,2168,2172,2179,2182,2188,2191,2202,2205,2208,2211,2217,2220,2223,2226,2230,2233,2236,2240,2243,2247,2250,2254,2257,2260,2265,2269,2272,2274,2277,2280,2286,2289,2292,2295,2299,2313,2316,2322,2325,2331,2334,2340,2343,2347,2350,2354,2357,2360,2363,2369,2375,2379,2382,2388,2391,2397,2400,2403,2407,2410,2424,2427,2430,2436,2439,2445,2449,2456,2462,2465,2471,2474,2477,2491,2494,2498,2503,2509,2515,2524,2529,2533,2536,2539,2548,2551,2554,2557,2561,2737,2741,2745,2751,2755,2758,2764,2767,2771,2777,2781,2784,2816,2819,2864,2867,2893,2896,2902,2905,2911,2915,2919,2922,2926,2929,2933,2936,2940,2943,2947,2950,2954,2957,2961,2991,2994,3002],[14,1663,1665],{"id":1664},"一先给出整体结论","一、先给出整体结论",[18,1667,1668,1671],{},[21,1669,1670],{},"synchronized"," 是 Java 语言提供的内置同步机制。它在语义上负责三件事：",[99,1673,1674,1677,1680],{},[102,1675,1676],{},"同一时刻只允许满足条件的线程进入临界区；",[102,1678,1679],{},"支持同一线程重复获取同一把锁，也就是可重入；",[102,1681,1682],{},"解锁 happens-before 后续对同一 Monitor 的加锁，保证相关共享数据的可见性和有序性。",[18,1684,1685],{},"在 JDK 8 HotSpot 中，为了避免所有同步操作都直接阻塞线程，JVM 会根据竞争情况使用不同实现：",[118,1687,1690],{"className":1688,"code":1689,"language":123,"meta":124},[121],"偏向锁：同一个线程反复进入，尽量避免原子操作\n轻量级锁：线程交替执行或短暂竞争，使用栈上 Lock Record 和 CAS\n重量级锁：竞争较强或必须使用 Monitor 能力时，通过 ObjectMonitor 管理等待线程\n",[21,1691,1689],{"__ignoreMap":124},[18,1693,1694],{},"通常所说的“无锁、偏向锁、轻量级锁、重量级锁”，是对对象头及其关联同步结构的概括，不是 Java 语言规范定义的四种锁类型。",[14,1696,73],{"id":73},[18,1698,1699],{},[77,1700,1703],{"href":1701,"target":80,"rel":1702},"\u002Fimages\u002Fwiki\u002Fjava\u002Fjdk8-synchronized-state-transitions.svg",[82,83],[85,1704],{"src":1701,"alt":1705},"JDK 8 synchronized 锁状态转换总览",[63,1707,1708],{},[18,1709,1710],{},"图中信息较多，可点击图片查看原图。",[18,1712,1713],{},"需要先纠正一个常见说法：",[63,1715,1716],{},[18,1717,1718],{},"“锁只能升级，不能降级”适合帮助理解竞争路径，但并不严谨。",[18,1720,1721,1722],{},"轻量级锁正常释放后会通过 CAS 恢复对象原来的 Mark Word；已经膨胀的 ObjectMonitor 也可能在后续安全点被 JVM 回收。更准确的说法是：",[68,1723,1724],{},"持锁竞争过程中通常不会为了当前请求立即从重量级锁退回轻量级锁，但对象状态并非终身只能单向变化。",[14,1726,1728],{"id":1727},"二synchronized-在字节码中的入口","二、synchronized 在字节码中的入口",[18,1730,1731],{},"同步代码块通常编译为：",[118,1733,1736],{"className":1734,"code":1735,"language":123,"meta":124},[121],"monitorenter\n 临界区代码\nmonitorexit\n",[21,1737,1735],{"__ignoreMap":124},[18,1739,1740,1741,1744],{},"编译器会为正常返回和异常退出路径生成对应的 ",[21,1742,1743],{},"monitorexit","，保证退出同步块时释放锁。",[18,1746,1747],{},"同步方法不会在方法体中出现这两个指令，而是在方法访问标志中使用：",[118,1749,1752],{"className":1750,"code":1751,"language":123,"meta":124},[121],"ACC_SYNCHRONIZED\n",[21,1753,1751],{"__ignoreMap":124},[18,1755,1756],{},"JVM 在调用和返回同步方法时完成 Monitor 的进入与退出。",[18,1758,1759],{},"无论入口是哪一种，最终都围绕同一个锁对象工作：",[341,1761,1762,1772],{},[344,1763,1764],{},[347,1765,1766,1769],{},[350,1767,1768],{},"写法",[350,1770,1771],{},"实际锁对象",[360,1773,1774,1785,1797],{},[347,1775,1776,1779],{},[365,1777,1778],{},"实例同步方法",[365,1780,1781,1782],{},"当前实例 ",[21,1783,1784],{},"this",[347,1786,1787,1790],{},[365,1788,1789],{},"静态同步方法",[365,1791,1792,1793,1796],{},"当前类对应的 ",[21,1794,1795],{},"Class"," 对象",[347,1798,1799,1802],{},[365,1800,1801],{},"同步代码块",[365,1803,1804,1807],{},[21,1805,1806],{},"synchronized (...)"," 中指定的对象",[14,1809,1811],{"id":1810},"三对象头与-mark-word","三、对象头与 Mark Word",[18,1813,1814],{},"普通 Java 对象的对象头主要包含：",[118,1816,1819],{"className":1817,"code":1818,"language":123,"meta":124},[121],"Mark Word\nKlass Pointer\n",[21,1820,1818],{"__ignoreMap":124},[18,1822,1823,1824,1826],{},"数组对象还会额外保存数组长度。",[21,1825,1670],{}," 的关键状态主要编码在 Mark Word 中。",[18,1828,1829],{},"以 JDK 8、64 位 HotSpot 为例，Mark Word 会复用同一段空间：",[18,1831,1832],{},[77,1833,1836],{"href":1834,"target":80,"rel":1835},"\u002Fimages\u002Fwiki\u002Fjava\u002Fjdk8-synchronized-mark-word.svg",[82,83],[85,1837],{"src":1834,"alt":1838},"JDK 8 HotSpot Mark Word 与同步结构",[63,1840,1841],{},[18,1842,1843],{},"可点击图片查看完整尺寸。",[192,1845,1847],{"id":1846},"统一按最低-3-位阅读","统一按最低 3 位阅读",[18,1849,1850,1851,1854],{},"为了避免一会儿看 2 位、一会儿看 3 位，本文后续统一展示 Mark Word 的最低 ",[68,1852,1853],{},"3 位","。但要先区分“展示宽度”和“字段含义”：",[99,1856,1857,1863,1866],{},[102,1858,1859,1860,1191],{},"真正的锁标志始终是最低 ",[68,1861,1862],{},"2 位",[102,1864,1865],{},"只有普通未锁定和偏向布局会把倒数第 3 位解释成“偏向位”；",[102,1867,1868],{},"轻量级锁、重量级锁保存的是对齐后的指针，本文把其最低 3 位也完整写出，但倒数第 3 位不再表示偏向。",[341,1870,1871,1887],{},[344,1872,1873],{},[347,1874,1875,1878,1881,1884],{},[350,1876,1877],{},"最低 3 位",[350,1879,1880],{},"最低 2 位锁标志",[350,1882,1883],{},"状态",[350,1885,1886],{},"倒数第 3 位如何解释",[360,1888,1889,1910,1929,1947,1965],{},[347,1890,1891,1896,1901,1904],{},[365,1892,1893],{},[21,1894,1895],{},"001",[365,1897,1898],{},[21,1899,1900],{},"01",[365,1902,1903],{},"普通未锁定",[365,1905,1906,1907],{},"偏向位为 ",[21,1908,1909],{},"0",[347,1911,1912,1917,1921,1924],{},[365,1913,1914],{},[21,1915,1916],{},"101",[365,1918,1919],{},[21,1920,1900],{},[365,1922,1923],{},"可偏向或已偏向",[365,1925,1906,1926],{},[21,1927,1928],{},"1",[347,1930,1931,1936,1941,1944],{},[365,1932,1933],{},[21,1934,1935],{},"000",[365,1937,1938],{},[21,1939,1940],{},"00",[365,1942,1943],{},"轻量级锁",[365,1945,1946],{},"对齐后的 Lock Record 指针低位，不是偏向位",[347,1948,1949,1954,1959,1962],{},[365,1950,1951],{},[21,1952,1953],{},"010",[365,1955,1956],{},[21,1957,1958],{},"10",[365,1960,1961],{},"重量级锁",[365,1963,1964],{},"对齐后的 ObjectMonitor 指针低位，不是偏向位",[347,1966,1967,1972,1977,1980],{},[365,1968,1969],{},[21,1970,1971],{},"011",[365,1973,1974],{},[21,1975,1976],{},"11",[365,1978,1979],{},"GC 标记",[365,1981,1982],{},"标记状态的一部分，不是偏向位",[18,1984,1985,1986,1988],{},"因此 ",[21,1987,1916],{}," 应当拆开读成：",[118,1990,1993],{"className":1991,"code":1992,"language":123,"meta":124},[121],"偏向位 1 ｜ 锁标志 01\n",[21,1994,1992],{"__ignoreMap":124},[18,1996,1997],{},"它不是一个三位的“锁标志”。本文使用三位只是为了让所有状态在图表中对齐、便于比较。",[18,1999,2000],{},"其中偏向状态可以继续区分：",[118,2002,2005],{"className":2003,"code":2004,"language":123,"meta":124},[121],"匿名偏向：线程指针为空，允许第一个线程认领\n已偏向：线程指针指向获得偏向的 JavaThread\n",[21,2006,2004],{"__ignoreMap":124},[18,2008,2009],{},"Mark Word 是一块被复用的空间。例如普通未锁定对象可以直接保存 identity hash；偏向对象需要保存线程指针，因此二者不能同时使用同一布局。",[192,2011,2013],{"id":2012},"epoch-到底是什么","epoch 到底是什么",[18,2015,2016,2019],{},[21,2017,2018],{},"epoch"," 可以理解为某个类的“偏向版本号”，它不是时间戳，也不是对象年龄。",[18,2021,2022],{},"偏向锁不只依赖对象自身。支持偏向的类会在类的 prototype header 中保存一个当前 epoch；每个偏向对象的 Mark Word 中也会记录对象认领时使用的 epoch。线程进入偏向对象时，会比较两者：",[118,2024,2027],{"className":2025,"code":2026,"language":123,"meta":124},[121],"对象 epoch == 类当前 epoch\n → 这份偏向记录仍属于当前版本，继续检查偏向线程\n\n对象 epoch != 类当前 epoch\n → 这份偏向记录已经过期，可以进入重偏向或撤销流程\n",[21,2028,2026],{"__ignoreMap":124},[18,2030,2031,2032,2035],{},"它主要服务于",[68,2033,2034],{},"批量重偏向","。当一批对象从线程 A 整体转交给线程 B 使用时，JVM 不必立即逐个改写所有对象头，而是先提升类的 epoch。旧对象之后被访问时，会因为 epoch 不匹配而按新版本重新处理。",[18,2037,2038],{},"所以需要把两个容易混淆的字段分开：",[341,2040,2041,2051],{},[344,2042,2043],{},[347,2044,2045,2048],{},[350,2046,2047],{},"字段",[350,2049,2050],{},"含义",[360,2052,2053,2063],{},[347,2054,2055,2060],{},[365,2056,2057],{},[21,2058,2059],{},"age",[365,2061,2062],{},"对象的 GC 年龄，用于分代回收",[347,2064,2065,2069],{},[365,2066,2067],{},[21,2068,2018],{},[365,2070,2071],{},"类的偏向版本，用于判断对象上的偏向记录是否过期",[14,2073,2075],{"id":2074},"四jdk-8-为什么需要三种锁实现","四、JDK 8 为什么需要三种锁实现",[18,2077,2078],{},"不同竞争场景适合不同成本的同步方式。",[192,2080,2081],{"id":2081},"只有一个线程反复进入",[18,2083,2084],{},"如果一个对象长期只被同一个线程加锁，每次都执行 CAS 仍然是额外成本。偏向锁把对象与线程关联起来，后续同一线程进入时主要检查对象头是否仍偏向自己。",[192,2086,2088],{"id":2087},"多线程交替执行但没有同时竞争","多线程交替执行，但没有同时竞争",[18,2090,2091],{},"例如线程 A 使用完后线程 B 才进入。此时没有必要挂起线程，可以通过栈上 Lock Record 和 CAS 完成加锁、解锁。",[192,2093,2094],{"id":2094},"多线程同时争抢或需要等待队列",[18,2096,2097,2098,2101],{},"当 CAS 快速路径无法解决竞争，或者调用 ",[21,2099,2100],{},"wait()"," 需要条件等待集合时，JVM 使用 ObjectMonitor 管理 Owner、竞争线程和等待线程。",[18,2103,2104],{},"所以这三种实现的目标不是简单比较“谁更高级”，而是：",[63,2106,2107],{},[18,2108,2109],{},"根据实际竞争强度，在原子操作、CPU 自旋、线程阻塞和唤醒成本之间做权衡。",[14,2111,2113],{"id":2112},"五对象初始状态普通未锁定还是匿名偏向","五、对象初始状态：普通未锁定还是匿名偏向",[18,2115,2116],{},"JDK 8 默认启用偏向锁，但默认存在启动延迟：",[118,2118,2121],{"className":2119,"code":2120,"language":123,"meta":124},[121],"-XX:+UseBiasedLocking\n-XX:BiasedLockingStartupDelay=4000\n",[21,2122,2120],{"__ignoreMap":124},[18,2124,2125],{},"因此需要区分对象创建时机：",[192,2127,2128],{"id":2128},"偏向锁尚未启用或被关闭",[18,2130,2131],{},"新对象通常使用普通未锁定布局：",[118,2133,2136],{"className":2134,"code":2135,"language":123,"meta":124},[121],"[identity hash | age | 0 | 01]\n",[21,2137,2135],{"__ignoreMap":124},[18,2139,2140],{},"线程第一次进入同步块时，直接尝试建立轻量级锁。",[192,2142,2143],{"id":2143},"偏向锁已经启用",[18,2145,2146],{},"支持偏向的类创建新对象时，对象通常处于匿名偏向状态：",[118,2148,2151],{"className":2149,"code":2150,"language":123,"meta":124},[121],"[0 | epoch | age | 1 | 01]\n",[21,2152,2150],{"__ignoreMap":124},[18,2154,2155],{},"因此严格来说，不应把这条路径描述为：",[118,2157,2160],{"className":2158,"code":2159,"language":123,"meta":124},[121],"新对象先是无锁，然后第一次进入才“升级”为可偏向状态\n",[21,2161,2159],{"__ignoreMap":124},[18,2163,2164,2165],{},"更准确的说法是：",[68,2166,2167],{},"对象创建时便根据类的 prototype header 获得普通未锁定或匿名偏向的 Mark Word。",[14,2169,2171],{"id":2170},"六偏向锁的获取与重入","六、偏向锁的获取与重入",[18,2173,2174,2175,2178],{},"线程进入一个匿名偏向对象时，会尝试通过 CAS 把自己的 ",[21,2176,2177],{},"JavaThread*","、类当前的 epoch 等信息写入 Mark Word。",[18,2180,2181],{},"成功后，对象变成：",[118,2183,2186],{"className":2184,"code":2185,"language":123,"meta":124},[121],"[当前 JavaThread* | epoch | age | 1 | 01]\n",[21,2187,2185],{"__ignoreMap":124},[18,2189,2190],{},"同一个线程以后再次进入时，主要检查：",[708,2192,2193,2196,2199],{},[102,2194,2195],{},"Mark Word 是否仍是偏向模式；",[102,2197,2198],{},"偏向线程是否是当前线程；",[102,2200,2201],{},"对象 epoch 是否仍与类的 prototype header 匹配。",[18,2203,2204],{},"全部满足时可直接进入，不需要再次通过 CAS 抢占锁。",[192,2206,2207],{"id":2207},"偏向锁退出为什么不清除线程信息",[18,2209,2210],{},"偏向锁针对的就是“同一个线程还会再次进入”这一场景。同步块结束后，Mark Word 通常仍保留对原线程的偏向：",[118,2212,2215],{"className":2213,"code":2214,"language":123,"meta":124},[121],"进入前：偏向线程 A\n执行中：偏向线程 A\n退出后：仍偏向线程 A\n",[21,2216,2214],{"__ignoreMap":124},[18,2218,2219],{},"它不是表示线程 A 永远占用临界区，而是表示下一次线程 A 再进入时可以走低成本路径。",[192,2221,2222],{"id":2222},"偏向锁如何实现可重入",[18,2224,2225],{},"对象头记录了偏向线程，但不通过一个公共计数器记录每次进入。JVM 可以结合当前线程栈上的锁记录识别同步嵌套。对同一偏向线程而言，重复进入不需要竞争性地修改对象头。",[14,2227,2229],{"id":2228},"七其他线程访问偏向对象时发生什么","七、其他线程访问偏向对象时发生什么",[18,2231,2232],{},"线程 B 遇到偏向线程 A 的对象时，不能简单地直接覆盖线程指针。JVM 需要先判断原偏向是否仍然有效。",[18,2234,2235],{},"可能出现以下路径。",[192,2237,2239],{"id":2238},"_1-epoch-已过期","1. epoch 已过期",[18,2241,2242],{},"类发生批量重偏向后，旧对象的 epoch 可能落后于类的 epoch。线程 B 可以尝试通过 CAS 将对象重新偏向自己。",[192,2244,2246],{"id":2245},"_2-原线程已经不再持有这把锁","2. 原线程已经不再持有这把锁",[18,2248,2249],{},"JVM 可以撤销原偏向，使对象恢复为普通未锁定状态，或者在允许的情况下重新偏向新线程。",[192,2251,2253],{"id":2252},"_3-原线程仍在同步块中","3. 原线程仍在同步块中",[18,2255,2256],{},"JVM 需要检查原线程栈，撤销偏向并重建合法的锁状态。如果此时存在实际竞争，后续会进入轻量级竞争或直接膨胀为 ObjectMonitor。",[18,2258,2259],{},"因此：",[63,2261,2262],{},[18,2263,2264],{},"另一个线程访问偏向对象，不等于必然直接升级为重量级锁。是否重偏向、撤销为普通状态、转换为轻量级锁或膨胀，需要结合 epoch、类级启发式统计和原线程是否仍持锁判断。",[14,2266,2268],{"id":2267},"八批量重偏向与批量撤销","八、批量重偏向与批量撤销",[18,2270,2271],{},"如果某个类的大量对象不断被不同线程使用，逐个在安全点撤销偏向的成本会很高。HotSpot 会对同一类的偏向撤销次数做启发式统计。",[192,2273,2034],{"id":2034},[18,2275,2276],{},"当撤销达到一定阈值时，JVM 可以提升类 prototype header 中的 epoch。旧对象不需要立刻逐个修改；之后线程发现对象 epoch 过期时，再尝试将它偏向当前线程。",[18,2278,2279],{},"适合这种模式：",[118,2281,2284],{"className":2282,"code":2283,"language":123,"meta":124},[121],"一批对象先由线程 A 使用\n之后整体交给线程 B 使用\n但同一时刻竞争并不强\n",[21,2285,2283],{"__ignoreMap":124},[192,2287,2288],{"id":2288},"批量撤销",[18,2290,2291],{},"如果该类持续表现出多线程竞争，偏向锁已经不再适合，JVM 可以撤销该类的偏向能力。之后新对象不再默认可偏向，已有对象也会按正常锁路径处理。",[18,2293,2294],{},"这也是为什么偏向锁不能只按“对象自身的四级升级”理解：它还存在以类为粒度的 prototype header、epoch 和批量启发式机制。",[14,2296,2298],{"id":2297},"九普通未锁定到轻量级锁","九、普通未锁定到轻量级锁",[18,2300,2301,2302,2305,2306,2309,2310,2312],{},"当对象处于普通未锁定状态，线程进入同步块时会在当前栈帧创建锁记录，HotSpot 源码中对应 ",[21,2303,2304],{},"BasicLock","，解释器栈中通常由 ",[21,2307,2308],{},"BasicObjectLock"," 将对象引用和 ",[21,2311,2304],{}," 组织在一起。",[18,2314,2315],{},"概念流程如下：",[118,2317,2320],{"className":2318,"code":2319,"language":123,"meta":124},[121],"1. 在线程栈创建 Lock Record\n2. 将对象原 Mark Word 保存到 displaced header\n3. CAS 修改对象 Mark Word\n4. 让 Mark Word 指向当前 Lock Record\n",[21,2321,2319],{"__ignoreMap":124},[18,2323,2324],{},"CAS 成功后：",[118,2326,2329],{"className":2327,"code":2328,"language":123,"meta":124},[121],"对象 Mark Word → 线程栈 Lock Record\nLock Record → 保存原 Mark Word\n",[21,2330,2328],{"__ignoreMap":124},[18,2332,2333],{},"对象头低两位为：",[118,2335,2338],{"className":2336,"code":2337,"language":123,"meta":124},[121],"00\n",[21,2339,2337],{"__ignoreMap":124},[18,2341,2342],{},"这就是通常所说的轻量级锁或栈锁。",[192,2344,2346],{"id":2345},"为什么要保存-displaced-header","为什么要保存 displaced header",[18,2348,2349],{},"轻量级锁占用了对象原来的 Mark Word。解锁时需要把原 Mark Word 恢复回对象头，因此先把它保存到 Lock Record。",[14,2351,2353],{"id":2352},"十轻量级锁的可重入","十、轻量级锁的可重入",[18,2355,2356],{},"同一个线程再次获取已经由自己栈锁定的对象时，JVM 会识别对象头中的 Lock Record 指针属于当前线程栈。",[18,2358,2359],{},"此时新的 Lock Record 会使用特殊值表示递归进入，例如 displaced header 置空，而不是再次覆盖对象头。",[18,2361,2362],{},"退出时：",[118,2364,2367],{"className":2365,"code":2366,"language":123,"meta":124},[121],"递归层 Lock Record：只退出当前递归层\n最外层 Lock Record：负责真正恢复对象头\n",[21,2368,2366],{"__ignoreMap":124},[18,2370,2371,2372,2374],{},"这解释了为什么 ",[21,2373,1670],{}," 天然支持可重入。",[14,2376,2378],{"id":2377},"十一轻量级锁如何释放","十一、轻量级锁如何释放",[18,2380,2381],{},"最外层同步块退出时，线程使用 CAS 尝试把 Lock Record 中保存的 displaced header 恢复到对象 Mark Word：",[118,2383,2386],{"className":2384,"code":2385,"language":123,"meta":124},[121],"期望值：对象头仍指向当前 Lock Record\n新值：进入同步块前保存的原 Mark Word\n",[21,2387,2385],{"__ignoreMap":124},[18,2389,2390],{},"CAS 成功：",[118,2392,2395],{"className":2393,"code":2394,"language":123,"meta":124},[121],"轻量级锁正常释放\n对象恢复普通未锁定状态\n",[21,2396,2394],{"__ignoreMap":124},[18,2398,2399],{},"CAS 失败通常意味着对象已在竞争过程中膨胀，不能再直接把原对象头覆盖回去，需要走 ObjectMonitor 的退出逻辑。",[18,2401,2402],{},"这就是“锁只能升级不能降级”表述不够准确的直接例子：没有发生膨胀的轻量级锁，退出后会恢复原 Mark Word。",[14,2404,2406],{"id":2405},"十二轻量级锁何时膨胀","十二、轻量级锁何时膨胀",[18,2408,2409],{},"线程尝试用 CAS 建立轻量级锁失败，说明对象头已经发生变化。可能原因包括：",[99,2411,2412,2415,2418,2421],{},[102,2413,2414],{},"另一个线程持有轻量级锁；",[102,2416,2417],{},"对象已经膨胀为 ObjectMonitor；",[102,2419,2420],{},"竞争期间其他线程正在处理锁状态；",[102,2422,2423],{},"必须执行依赖 ObjectMonitor 的操作。",[18,2425,2426],{},"JVM 可以先进行短暂自旋，希望持锁线程很快退出。自旋避免了线程立即挂起和恢复，但会消耗 CPU，因此只适合临界区较短的情况。",[18,2428,2429],{},"当快速路径不能解决问题时，JVM 会执行 Monitor inflation：",[118,2431,2434],{"className":2432,"code":2433,"language":123,"meta":124},[121],"创建或取得 ObjectMonitor\n复制并保存原 Mark Word\n将对象头改为指向 ObjectMonitor\n由 ObjectMonitor 负责后续竞争\n",[21,2435,2433],{"__ignoreMap":124},[18,2437,2438],{},"对象头低两位变成：",[118,2440,2443],{"className":2441,"code":2442,"language":123,"meta":124},[121],"10\n",[21,2444,2442],{"__ignoreMap":124},[14,2446,2448],{"id":2447},"十三重量级锁与-objectmonitor","十三、重量级锁与 ObjectMonitor",[18,2450,2451,2452,2455],{},"重量级状态下，对象 Mark Word 指向一个 ",[21,2453,2454],{},"ObjectMonitor","。理解它时重点关注以下字段或逻辑角色：",[118,2457,2460],{"className":2458,"code":2459,"language":123,"meta":124},[121],"_owner 当前持有 Monitor 的线程或相关锁记录\n_recursions 重入次数\n_cxq 新到达竞争线程形成的竞争队列\n_EntryList 等待重新竞争 Owner 的线程\n_WaitSet 调用 wait 后等待通知的线程\n_header 膨胀前保存的对象 Mark Word\n",[21,2461,2459],{"__ignoreMap":124},[18,2463,2464],{},"概念结构：",[118,2466,2469],{"className":2467,"code":2468,"language":123,"meta":124},[121],"对象 Mark Word\n │\n ▼\nObjectMonitor\n ├─ Owner\n ├─ Recursions\n ├─ cxq \u002F EntryList\n ├─ WaitSet\n └─ displaced header\n",[21,2470,2468],{"__ignoreMap":124},[18,2472,2473],{},"竞争线程可能先自旋尝试获得 Owner。仍然失败时，线程会进入等待结构并被挂起；持有线程退出后，Monitor 选择或唤醒后继线程继续竞争。",[18,2475,2476],{},"“重量级”的成本主要来自：",[99,2478,2479,2482,2485,2488],{},[102,2480,2481],{},"维护竞争和等待队列；",[102,2483,2484],{},"线程阻塞、唤醒与调度；",[102,2486,2487],{},"高竞争下的上下文切换；",[102,2489,2490],{},"对 Monitor 状态的原子协调。",[18,2492,2493],{},"它并不意味着每次操作都必然立刻执行一次昂贵的系统调用，HotSpot 仍包含快速路径和自适应自旋等优化。",[14,2495,2497],{"id":2496},"十四waitnotify-为什么会涉及重量级-monitor","十四、wait、notify 为什么会涉及重量级 Monitor",[18,2499,2500,2502],{},[21,2501,2100],{}," 的语义不是普通锁竞争：",[118,2504,2507],{"className":2505,"code":2506,"language":123,"meta":124},[121],"确认当前线程持有 Monitor\n完整释放锁及其重入层数\n进入 WaitSet\n等待 notify、notifyAll、中断或超时\n重新参与锁竞争\n恢复原重入状态后返回\n",[21,2508,2506],{"__ignoreMap":124},[18,2510,2511,2512,2514],{},"这需要 Owner、WaitSet、EntryList、重入次数等完整 Monitor 能力，因此 JDK 8 HotSpot 执行 ",[21,2513,2100],{}," 时会确保对象已经膨胀为 ObjectMonitor。",[18,2516,2517,1441,2520,2523],{},[21,2518,2519],{},"notify()",[21,2521,2522],{},"notifyAll()"," 存在一个细节：如果对象当前只是由调用线程栈锁定，那么它不可能已经拥有 WaitSet，HotSpot 可以直接返回而不做无意义的膨胀；否则会取得或膨胀 ObjectMonitor，再处理等待线程。",[18,2525,2526,2528],{},[21,2527,2519],{}," 只是把等待线程从“等待条件”推进到“可以重新竞争锁”的阶段，并不会让它绕过当前 Owner 立即执行。",[14,2530,2532],{"id":2531},"十五identityhashcode-对锁状态的影响","十五、identityHashCode 对锁状态的影响",[18,2534,2535],{},"普通未锁定对象可以把 identity hash 保存在 Mark Word 中，但偏向锁的 Mark Word 需要保存 JavaThread 指针。",[18,2537,2538],{},"因此，对偏向对象计算：",[118,2540,2542],{"className":136,"code":2541,"language":138,"meta":124,"style":124},"System.identityHashCode(obj);\n",[21,2543,2544],{"__ignoreMap":124},[142,2545,2546],{"class":144,"line":145},[142,2547,2541],{},[18,2549,2550],{},"通常会导致偏向撤销，使对象头能够保存 hash。",[18,2552,2553],{},"如果对象正在使用轻量级锁，原 Mark Word 已经保存在当前线程栈的 Lock Record 中。为了稳定保存 identity hash，并让其他线程可靠读取，HotSpot 的相关路径可能把对象膨胀为 ObjectMonitor，再把 hash 保存在 Monitor 保存的 header 中。",[18,2555,2556],{},"所以观察锁升级实验时，不要在不知情的情况下调用可能计算 identity hash 的方法，否则实验本身会改变对象头。",[14,2558,2560],{"id":2559},"十六完整状态转换表","十六、完整状态转换表",[341,2562,2563,2576],{},[344,2564,2565],{},[347,2566,2567,2570,2573],{},[350,2568,2569],{},"当前状态",[350,2571,2572],{},"触发条件",[350,2574,2575],{},"可能结果",[360,2577,2578,2591,2604,2617,2629,2641,2653,2666,2678,2690,2702,2713,2726],{},[347,2579,2580,2585,2588],{},[365,2581,2582,2583],{},"普通未锁定 ",[21,2584,1895],{},[365,2586,2587],{},"首次进入同步块",[365,2589,2590],{},"CAS 成功后成为轻量级锁",[347,2592,2593,2598,2601],{},[365,2594,2595,2596],{},"匿名偏向 ",[21,2597,1916],{},[365,2599,2600],{},"第一个线程进入",[365,2602,2603],{},"CAS 写入线程指针，成为已偏向状态",[347,2605,2606,2611,2614],{},[365,2607,2608,2609],{},"已偏向 ",[21,2610,1916],{},[365,2612,2613],{},"原线程再次进入",[365,2615,2616],{},"保持偏向，低成本重入",[347,2618,2619,2623,2626],{},[365,2620,2608,2621],{},[21,2622,1916],{},[365,2624,2625],{},"新线程访问且 epoch 过期",[365,2627,2628],{},"尝试重偏向或撤销",[347,2630,2631,2635,2638],{},[365,2632,2608,2633],{},[21,2634,1916],{},[365,2636,2637],{},"新线程访问，原线程未持锁",[365,2639,2640],{},"撤销为普通状态，或按策略重偏向",[347,2642,2643,2647,2650],{},[365,2644,2608,2645],{},[21,2646,1916],{},[365,2648,2649],{},"新线程访问，原线程仍持锁",[365,2651,2652],{},"撤销偏向，转轻量级或膨胀",[347,2654,2655,2660,2663],{},[365,2656,2657,2658],{},"轻量级 ",[21,2659,1940],{},[365,2661,2662],{},"当前线程重入",[365,2664,2665],{},"新增递归 Lock Record，保持轻量级",[347,2667,2668,2672,2675],{},[365,2669,2657,2670],{},[21,2671,1940],{},[365,2673,2674],{},"无竞争退出",[365,2676,2677],{},"CAS 恢复原 Mark Word",[347,2679,2680,2684,2687],{},[365,2681,2657,2682],{},[21,2683,1940],{},[365,2685,2686],{},"竞争持续或恢复对象头失败",[365,2688,2689],{},"膨胀为 ObjectMonitor",[347,2691,2692,2695,2700],{},[365,2693,2694],{},"任意适用状态",[365,2696,2697,2699],{},[21,2698,2100],{}," 等需要完整 Monitor 语义",[365,2701,2689],{},[347,2703,2704,2707,2710],{},[365,2705,2706],{},"偏向\u002F轻量级",[365,2708,2709],{},"计算 identity hash 等特殊场景",[365,2711,2712],{},"撤销偏向或膨胀",[347,2714,2715,2720,2723],{},[365,2716,2717,2718],{},"重量级 ",[21,2719,1958],{},[365,2721,2722],{},"Owner 退出",[365,2724,2725],{},"唤醒\u002F选择后继；对象仍可保持膨胀",[347,2727,2728,2731,2734],{},[365,2729,2730],{},"空闲 ObjectMonitor",[365,2732,2733],{},"后续安全点清理",[365,2735,2736],{},"JVM 可能执行 Monitor deflation",[14,2738,2740],{"id":2739},"十七三条典型执行路径","十七、三条典型执行路径",[192,2742,2744],{"id":2743},"路径一同一个线程反复进入","路径一：同一个线程反复进入",[118,2746,2749],{"className":2747,"code":2748,"language":123,"meta":124},[121],"匿名偏向\n → CAS 偏向线程 A\n → A 执行同步块\n → A 退出但保留偏向\n → A 再次进入，快速命中\n",[21,2750,2748],{"__ignoreMap":124},[192,2752,2754],{"id":2753},"路径二线程交替使用没有重叠竞争","路径二：线程交替使用，没有重叠竞争",[18,2756,2757],{},"偏向关闭或偏向已撤销时：",[118,2759,2762],{"className":2760,"code":2761,"language":123,"meta":124},[121],"普通未锁定\n → A 建立轻量级锁\n → A CAS 恢复对象头\n → B 建立轻量级锁\n → B CAS 恢复对象头\n",[21,2763,2761],{"__ignoreMap":124},[18,2765,2766],{},"这种场景没有必要让线程进入阻塞等待。",[192,2768,2770],{"id":2769},"路径三多线程同时竞争","路径三：多线程同时竞争",[118,2772,2775],{"className":2773,"code":2774,"language":123,"meta":124},[121],"A 持有轻量级锁\n → B CAS 失败并短暂自旋\n → A 未及时释放\n → 对象膨胀为 ObjectMonitor\n → B 进入竞争\u002F等待结构\n → A 退出并推进后继竞争\n",[21,2776,2774],{"__ignoreMap":124},[14,2778,2780],{"id":2779},"十八jol-验证时要注意什么","十八、JOL 验证时要注意什么",[18,2782,2783],{},"可以使用 JOL 查看对象布局：",[118,2785,2789],{"className":2786,"code":2787,"language":2788,"meta":124,"style":124},"language-xml shiki shiki-themes github-light github-dark","\u003Cdependency>\n \u003CgroupId>org.openjdk.jol\u003C\u002FgroupId>\n \u003CartifactId>jol-core\u003C\u002FartifactId>\n \u003Cversion>0.17\u003C\u002Fversion>\n\u003C\u002Fdependency>\n","xml",[21,2790,2791,2796,2801,2806,2811],{"__ignoreMap":124},[142,2792,2793],{"class":144,"line":145},[142,2794,2795],{},"\u003Cdependency>\n",[142,2797,2798],{"class":144,"line":151},[142,2799,2800],{}," \u003CgroupId>org.openjdk.jol\u003C\u002FgroupId>\n",[142,2802,2803],{"class":144,"line":157},[142,2804,2805],{}," \u003CartifactId>jol-core\u003C\u002FartifactId>\n",[142,2807,2808],{"class":144,"line":163},[142,2809,2810],{}," \u003Cversion>0.17\u003C\u002Fversion>\n",[142,2812,2813],{"class":144,"line":169},[142,2814,2815],{},"\u003C\u002Fdependency>\n",[18,2817,2818],{},"示例：",[118,2820,2822],{"className":136,"code":2821,"language":138,"meta":124,"style":124},"Object lock = new Object();\n\nSystem.out.println(ClassLayout.parseInstance(lock).toPrintable());\n\nsynchronized (lock) {\n System.out.println(ClassLayout.parseInstance(lock).toPrintable());\n}\n\nSystem.out.println(ClassLayout.parseInstance(lock).toPrintable());\n",[21,2823,2824,2829,2833,2838,2842,2847,2852,2856,2860],{"__ignoreMap":124},[142,2825,2826],{"class":144,"line":145},[142,2827,2828],{},"Object lock = new Object();\n",[142,2830,2831],{"class":144,"line":151},[142,2832,781],{"emptyLinePlaceholder":780},[142,2834,2835],{"class":144,"line":157},[142,2836,2837],{},"System.out.println(ClassLayout.parseInstance(lock).toPrintable());\n",[142,2839,2840],{"class":144,"line":163},[142,2841,781],{"emptyLinePlaceholder":780},[142,2843,2844],{"class":144,"line":169},[142,2845,2846],{},"synchronized (lock) {\n",[142,2848,2849],{"class":144,"line":175},[142,2850,2851],{}," System.out.println(ClassLayout.parseInstance(lock).toPrintable());\n",[142,2853,2854],{"class":144,"line":181},[142,2855,1081],{},[142,2857,2858],{"class":144,"line":187},[142,2859,781],{"emptyLinePlaceholder":780},[142,2861,2862],{"class":144,"line":789},[142,2863,2837],{},[18,2865,2866],{},"实验时要控制以下变量：",[99,2868,2869,2872,2878,2884,2887,2890],{},[102,2870,2871],{},"明确使用 JDK 8 HotSpot；",[102,2873,2874,2875,1191],{},"记录是否开启 ",[21,2876,2877],{},"UseBiasedLocking",[102,2879,2880,2881,1191],{},"记录 ",[21,2882,2883],{},"BiasedLockingStartupDelay",[102,2885,2886],{},"避免日志、调试器或工具意外计算 identity hash；",[102,2888,2889],{},"JOL 输出会受 32\u002F64 位、压缩指针和 GC 配置影响；",[102,2891,2892],{},"线程已经终止不代表任何场景都一定重偏向，仍要看 epoch 和撤销策略。",[18,2894,2895],{},"为了避免默认 4 秒延迟影响实验，可以显式设置：",[118,2897,2900],{"className":2898,"code":2899,"language":123,"meta":124},[121],"-XX:+UseBiasedLocking\n-XX:BiasedLockingStartupDelay=0\n",[21,2901,2899],{"__ignoreMap":124},[18,2903,2904],{},"关闭偏向锁、直接观察轻量级路径：",[118,2906,2909],{"className":2907,"code":2908,"language":123,"meta":124},[121],"-XX:-UseBiasedLocking\n",[21,2910,2908],{"__ignoreMap":124},[14,2912,2914],{"id":2913},"十九常见误区","十九、常见误区",[192,2916,2918],{"id":2917},"误区一新对象一定先是无锁再升级为偏向锁","误区一：新对象一定先是无锁，再升级为偏向锁",[18,2920,2921],{},"不准确。偏向能力启用后，支持偏向的类可以让新对象直接使用匿名偏向的 prototype header。",[192,2923,2925],{"id":2924},"误区二第二个线程出现就一定升级为重量级锁","误区二：第二个线程出现就一定升级为重量级锁",[18,2927,2928],{},"不准确。它可能触发重偏向、偏向撤销、轻量级锁，也可能在存在实际竞争时膨胀。",[192,2930,2932],{"id":2931},"误区三轻量级锁就是一直自旋","误区三：轻量级锁就是一直自旋",[18,2934,2935],{},"不准确。轻量级锁的核心是栈上 Lock Record 与对象头 CAS；自旋是竞争时可能采用的等待优化，不是轻量级锁的完整定义。",[192,2937,2939],{"id":2938},"误区四重量级锁完全由操作系统-mutex-等同实现","误区四：重量级锁完全由操作系统 Mutex 等同实现",[18,2941,2942],{},"过度简化。ObjectMonitor 是 HotSpot 的 JVM 级同步结构，内部会使用 CAS、自旋、队列、park\u002Funpark 等机制；线程最终阻塞和唤醒会依赖操作系统能力，但两者不能直接画等号。",[192,2944,2946],{"id":2945},"误区五锁一旦膨胀这个对象终身都是重量级锁","误区五：锁一旦膨胀，这个对象终身都是重量级锁",[18,2948,2949],{},"不准确。当前竞争阶段通常不会立即降级，但空闲 Monitor 后续可能由 JVM 在安全点执行 deflation。",[192,2951,2953],{"id":2952},"误区六这套流程适用于所有-jdk","误区六：这套流程适用于所有 JDK",[18,2955,2956],{},"不准确。本文讨论的是 JDK 8 HotSpot。偏向锁后来被默认禁用，现代 HotSpot 的锁实现也持续演进，因此理解具体机制时必须先限定版本。",[14,2958,2960],{"id":2959},"二十参考资料","二十、参考资料",[99,2962,2963,2970,2977,2984],{},[102,2964,2965],{},[77,2966,2969],{"href":2967,"rel":2968},"https:\u002F\u002Fgithub.com\u002Fopenjdk\u002Fjdk8u\u002Fblob\u002Fmaster\u002Fhotspot\u002Fsrc\u002Fshare\u002Fvm\u002Foops\u002FmarkOop.hpp",[1579],"JDK 8 HotSpot：markOop.hpp",[102,2971,2972],{},[77,2973,2976],{"href":2974,"rel":2975},"https:\u002F\u002Fgithub.com\u002Fopenjdk\u002Fjdk8u\u002Fblob\u002Fmaster\u002Fhotspot\u002Fsrc\u002Fshare\u002Fvm\u002Fruntime\u002Fsynchronizer.cpp",[1579],"JDK 8 HotSpot：synchronizer.cpp",[102,2978,2979],{},[77,2980,2983],{"href":2981,"rel":2982},"https:\u002F\u002Fgithub.com\u002Fopenjdk\u002Fjdk8u\u002Fblob\u002Fmaster\u002Fhotspot\u002Fsrc\u002Fshare\u002Fvm\u002Fruntime\u002FbiasedLocking.cpp",[1579],"JDK 8 HotSpot：biasedLocking.cpp",[102,2985,2986],{},[77,2987,2990],{"href":2988,"rel":2989},"https:\u002F\u002Fgithub.com\u002Fopenjdk\u002Fjdk8u\u002Fblob\u002Fmaster\u002Fhotspot\u002Fsrc\u002Fshare\u002Fvm\u002Fruntime\u002FobjectMonitor.hpp",[1579],"JDK 8 HotSpot：objectMonitor.hpp",[14,2992,2993],{"id":2993},"相关内容",[99,2995,2996],{},[102,2997,2998],{},[77,2999,3001],{"href":3000},"\u002Fwiki\u002Fjava\u002Fsynchronized-vs-reentrantlock\u002F","synchronized 和 ReentrantLock 的区别",[1596,3003,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":3005},[3006,3007,3008,3009,3013,3018,3022,3026,3031,3035,3038,3039,3040,3041,3042,3043,3044,3045,3050,3051,3059,3060],{"id":1664,"depth":151,"text":1665},{"id":73,"depth":151,"text":73},{"id":1727,"depth":151,"text":1728},{"id":1810,"depth":151,"text":1811,"children":3010},[3011,3012],{"id":1846,"depth":157,"text":1847},{"id":2012,"depth":157,"text":2013},{"id":2074,"depth":151,"text":2075,"children":3014},[3015,3016,3017],{"id":2081,"depth":157,"text":2081},{"id":2087,"depth":157,"text":2088},{"id":2094,"depth":157,"text":2094},{"id":2112,"depth":151,"text":2113,"children":3019},[3020,3021],{"id":2128,"depth":157,"text":2128},{"id":2143,"depth":157,"text":2143},{"id":2170,"depth":151,"text":2171,"children":3023},[3024,3025],{"id":2207,"depth":157,"text":2207},{"id":2222,"depth":157,"text":2222},{"id":2228,"depth":151,"text":2229,"children":3027},[3028,3029,3030],{"id":2238,"depth":157,"text":2239},{"id":2245,"depth":157,"text":2246},{"id":2252,"depth":157,"text":2253},{"id":2267,"depth":151,"text":2268,"children":3032},[3033,3034],{"id":2034,"depth":157,"text":2034},{"id":2288,"depth":157,"text":2288},{"id":2297,"depth":151,"text":2298,"children":3036},[3037],{"id":2345,"depth":157,"text":2346},{"id":2352,"depth":151,"text":2353},{"id":2377,"depth":151,"text":2378},{"id":2405,"depth":151,"text":2406},{"id":2447,"depth":151,"text":2448},{"id":2496,"depth":151,"text":2497},{"id":2531,"depth":151,"text":2532},{"id":2559,"depth":151,"text":2560},{"id":2739,"depth":151,"text":2740,"children":3046},[3047,3048,3049],{"id":2743,"depth":157,"text":2744},{"id":2753,"depth":157,"text":2754},{"id":2769,"depth":157,"text":2770},{"id":2779,"depth":151,"text":2780},{"id":2913,"depth":151,"text":2914,"children":3052},[3053,3054,3055,3056,3057,3058],{"id":2917,"depth":157,"text":2918},{"id":2924,"depth":157,"text":2925},{"id":2931,"depth":157,"text":2932},{"id":2938,"depth":157,"text":2939},{"id":2945,"depth":157,"text":2946},{"id":2952,"depth":157,"text":2953},{"id":2959,"depth":151,"text":2960},{"id":2993,"depth":151,"text":2993},"wiki:java:jdk8-synchronized-lock-states","从 Mark Word、Lock Record 与 ObjectMonitor 出发，系统理解 JDK 8 HotSpot 中偏向锁、轻量级锁、重量级锁的获取、撤销、膨胀和释放过程。","advanced",{},"\u002Fjava\u002Fjdk8-synchronized-lock-states","并发编程",{"title":1659,"description":3062},"java\u002Fjdk8-synchronized-lock-states","2026-07-23","o8PHY3tOTf0rejJ23m3VdGgkxtPD3RVAY71ujC1dbCs",{"id":3072,"title":3001,"body":3073,"commentId":3980,"description":3981,"difficulty":1645,"draft":1646,"extension":1647,"meta":3982,"navigation":780,"order":3983,"path":3984,"section":1651,"seo":3985,"stem":3986,"updated":3987,"__hash__":3988},"java\u002Fjava\u002Fsynchronized-vs-reentrantlock.md",{"type":7,"value":3074,"toc":3958},[3075,3078,3081,3086,3089,3096,3098,3107,3109,3117,3127,3131,3133,3139,3142,3148,3151,3154,3160,3167,3170,3174,3327,3329,3333,3336,3341,3344,3350,3353,3356,3362,3365,3367,3371,3377,3380,3383,3389,3392,3397,3399,3403,3406,3409,3415,3418,3421,3427,3430,3436,3438,3444,3447,3449,3453,3456,3462,3465,3471,3476,3479,3481,3485,3490,3493,3499,3505,3511,3514,3520,3523,3529,3532,3538,3541,3547,3550,3556,3559,3561,3565,3568,3571,3577,3580,3586,3589,3592,3595,3601,3604,3607,3613,3616,3622,3629,3631,3635,3640,3646,3649,3652,3658,3665,3671,3674,3680,3683,3685,3689,3692,3695,3711,3714,3719,3722,3724,3728,3731,3751,3753,3759,3762,3767,3769,3773,3775,3801,3804,3810,3813,3815,3819,3864,3867,3872,3879,3885,3888,3890,3894,3898,3901,3905,3908,3912,3915,3923,3927,3930,3934,3937,3940,3946,3948,3951],[18,3076,3077],{},"synchronized和reentrantLock的区别？",[10,3079,3080],{"id":3080},"面试标准回答",[63,3082,3083],{},[18,3084,3085],{},"synchronized 是 JVM 层面的内置锁，语法简单，进入同步块后自动加锁，退出时自动释放，支持可重入和内存可见性。ReentrantLock 是基于 AQS 实现的显式锁，同样支持可重入，但提供了公平锁、可响应中断获取锁、tryLock、超时获取以及多个 Condition 等高级能力。两者在现代 JDK 中性能差距通常不是主要选型依据；功能简单时优先 synchronized，需要精细控制时使用 ReentrantLock，并且必须在 finally 中释放锁。",[18,3087,3088],{},"一句话记忆：",[63,3090,3091],{},[18,3092,3093],{},[68,3094,3095],{},"synchronized 简单自动，ReentrantLock 灵活可控。",[14,3097,73],{"id":73},[18,3099,3100],{},[77,3101,3104],{"href":3102,"target":80,"rel":3103},"\u002Fimages\u002Fwiki\u002Fjava\u002Fsynchronized-vs-reentrantlock.svg",[82,83],[85,3105],{"src":3102,"alt":3106},"synchronized 与 ReentrantLock 核心差异和选型建议",[10,3108,90],{"id":90},[18,3110,3111,1441,3113,3116],{},[21,3112,1670],{},[21,3114,3115],{},"ReentrantLock"," 都能实现互斥和可见性，但定位不同：",[63,3118,3119],{},[18,3120,3121,3123,3124,3126],{},[21,3122,1670],{}," 是 JVM 原生关键字，语法简单；",[21,3125,3115],{}," 是 JUC 提供的显式锁，功能更丰富、控制能力更强。",[14,3128,3130],{"id":3129},"一基本用法","一、基本用法",[192,3132,1670],{"id":1670},[118,3134,3137],{"className":3135,"code":3136,"language":123},[121],"synchronized (lock) {\n \u002F\u002F 临界区\n}\n",[21,3138,3136],{"__ignoreMap":124},[18,3140,3141],{},"或者：",[118,3143,3146],{"className":3144,"code":3145,"language":123},[121],"public synchronized void method() {\n}\n",[21,3147,3145],{"__ignoreMap":124},[18,3149,3150],{},"锁会自动释放。",[192,3152,3115],{"id":3153},"reentrantlock",[118,3155,3158],{"className":3156,"code":3157,"language":123},[121],"ReentrantLock lock = new ReentrantLock();\n\nlock.lock();\ntry {\n \u002F\u002F 临界区\n} finally {\n lock.unlock();\n}\n",[21,3159,3157],{"__ignoreMap":124},[18,3161,3162,3163,3166],{},"必须手动释放，所以通常必须写在 ",[21,3164,3165],{},"finally"," 中。",[3168,3169],"hr",{},[14,3171,3173],{"id":3172},"二核心区别","二、核心区别",[341,3175,3176,3187],{},[344,3177,3178],{},[347,3179,3180,3183,3185],{},[350,3181,3182],{},"对比项",[350,3184,1670],{},[350,3186,3115],{},[360,3188,3189,3200,3211,3221,3231,3244,3256,3268,3279,3294,3305,3316],{},[347,3190,3191,3194,3197],{},[365,3192,3193],{},"实现层次",[365,3195,3196],{},"JVM 关键字、Monitor",[365,3198,3199],{},"Java 类，基于 AQS",[347,3201,3202,3205,3208],{},[365,3203,3204],{},"加锁释放",[365,3206,3207],{},"自动",[365,3209,3210],{},"手动",[347,3212,3213,3216,3219],{},[365,3214,3215],{},"可重入",[365,3217,3218],{},"支持",[365,3220,3218],{},[347,3222,3223,3226,3229],{},[365,3224,3225],{},"公平锁",[365,3227,3228],{},"不支持显式配置",[365,3230,3218],{},[347,3232,3233,3236,3239],{},[365,3234,3235],{},"可中断获取锁",[365,3237,3238],{},"不支持",[365,3240,3241],{},[21,3242,3243],{},"lockInterruptibly()",[347,3245,3246,3249,3251],{},[365,3247,3248],{},"尝试获取锁",[365,3250,3238],{},[365,3252,3253],{},[21,3254,3255],{},"tryLock()",[347,3257,3258,3261,3263],{},[365,3259,3260],{},"超时获取锁",[365,3262,3238],{},[365,3264,3265],{},[21,3266,3267],{},"tryLock(timeout, unit)",[347,3269,3270,3273,3276],{},[365,3271,3272],{},"条件队列",[365,3274,3275],{},"一个 Monitor WaitSet",[365,3277,3278],{},"可创建多个 Condition",[347,3280,3281,3284,3289],{},[365,3282,3283],{},"等待通知",[365,3285,3286],{},[21,3287,3288],{},"wait\u002Fnotify\u002FnotifyAll",[365,3290,3291],{},[21,3292,3293],{},"await\u002Fsignal\u002FsignalAll",[347,3295,3296,3299,3302],{},[365,3297,3298],{},"锁状态查询",[365,3300,3301],{},"能力有限",[365,3303,3304],{},"提供较多查询方法",[347,3306,3307,3310,3313],{},[365,3308,3309],{},"编码复杂度",[365,3311,3312],{},"低",[365,3314,3315],{},"较高",[347,3317,3318,3321,3324],{},[365,3319,3320],{},"异常释放",[365,3322,3323],{},"自动释放",[365,3325,3326],{},"必须 finally unlock",[3168,3328],{},[10,3330,3332],{"id":3331},"三两者都支持可重入","三、两者都支持可重入",[18,3334,3335],{},"可重入指：",[63,3337,3338],{},[18,3339,3340],{},"同一个线程已经持有锁时，可以再次获取同一把锁。",[192,3342,1670],{"id":3343},"synchronized-1",[118,3345,3348],{"className":3346,"code":3347,"language":123},[121],"public synchronized void methodA() {\n methodB();\n}\n\npublic synchronized void methodB() {\n}\n",[21,3349,3347],{"__ignoreMap":124},[18,3351,3352],{},"同一个对象上的两个同步方法，线程可以重入。",[192,3354,3115],{"id":3355},"reentrantlock-1",[118,3357,3360],{"className":3358,"code":3359,"language":123},[121],"lock.lock();\ntry {\n lock.lock();\n try {\n \u002F\u002F 重入\n } finally {\n lock.unlock();\n }\n} finally {\n lock.unlock();\n}\n",[21,3361,3359],{"__ignoreMap":124},[18,3363,3364],{},"获取几次，就必须释放几次。",[3168,3366],{},[10,3368,3370],{"id":3369},"四reentrantlock-支持公平锁","四、ReentrantLock 支持公平锁",[118,3372,3375],{"className":3373,"code":3374,"language":123},[121],"ReentrantLock fairLock = new ReentrantLock(true);\n",[21,3376,3374],{"__ignoreMap":124},[18,3378,3379],{},"公平锁会尽量按 AQS 队列顺序获取锁。",[18,3381,3382],{},"默认是非公平锁：",[118,3384,3387],{"className":3385,"code":3386,"language":123},[121],"ReentrantLock lock = new ReentrantLock();\n",[21,3388,3386],{"__ignoreMap":124},[18,3390,3391],{},"非公平锁允许新线程插队，吞吐量通常更高。",[18,3393,3394,3396],{},[21,3395,1670],{}," 没有 API 让你指定公平性，通常按非公平竞争理解。",[3168,3398],{},[10,3400,3402],{"id":3401},"五reentrantlock-支持可响应中断等待","五、ReentrantLock 支持可响应中断等待",[18,3404,3405],{},"假设线程正在等待锁。",[18,3407,3408],{},"使用：",[118,3410,3413],{"className":3411,"code":3412,"language":123},[121],"lock.lock();\n",[21,3414,3412],{"__ignoreMap":124},[18,3416,3417],{},"即使线程被中断，也不会因为中断立即退出获取锁过程。",[18,3419,3420],{},"而：",[118,3422,3425],{"className":3423,"code":3424,"language":123},[121],"lock.lockInterruptibly();\n",[21,3426,3424],{"__ignoreMap":124},[18,3428,3429],{},"等待期间如果收到中断，会抛出：",[118,3431,3434],{"className":3432,"code":3433,"language":123},[121],"InterruptedException\n",[21,3435,3433],{"__ignoreMap":124},[18,3437,1263],{},[118,3439,3442],{"className":3440,"code":3441,"language":123},[121],"try {\n lock.lockInterruptibly();\n try {\n doWork();\n } finally {\n lock.unlock();\n }\n} catch (InterruptedException e) {\n Thread.currentThread().interrupt();\n}\n",[21,3443,3441],{"__ignoreMap":124},[18,3445,3446],{},"这对于避免线程长时间死等、响应取消请求很有价值。",[3168,3448],{},[10,3450,3452],{"id":3451},"六reentrantlock-支持尝试获取和超时","六、ReentrantLock 支持尝试获取和超时",[192,3454,3455],{"id":3455},"立即尝试",[118,3457,3460],{"className":3458,"code":3459,"language":123},[121],"if (lock.tryLock()) {\n try {\n doWork();\n } finally {\n lock.unlock();\n }\n} else {\n \u002F\u002F 获取失败，走降级逻辑\n}\n",[21,3461,3459],{"__ignoreMap":124},[192,3463,3464],{"id":3464},"超时尝试",[118,3466,3469],{"className":3467,"code":3468,"language":123},[121],"if (lock.tryLock(2, TimeUnit.SECONDS)) {\n try {\n doWork();\n } finally {\n lock.unlock();\n }\n} else {\n \u002F\u002F 两秒内未拿到锁\n}\n",[21,3470,3468],{"__ignoreMap":124},[18,3472,3473,3475],{},[21,3474,1670],{}," 一旦进入竞争，只能等待，无法直接设置超时。",[18,3477,3478],{},"这也是 ReentrantLock 在需要降级、超时控制时的重要优势。",[3168,3480],{},[10,3482,3484],{"id":3483},"七condition-比-waitnotify-更灵活","七、Condition 比 wait\u002Fnotify 更灵活",[18,3486,3487,3489],{},[21,3488,1670],{}," 的一个 Monitor 只有一个 WaitSet。",[18,3491,3492],{},"例如阻塞队列里：",[118,3494,3497],{"className":3495,"code":3496,"language":123},[121],"生产者等待 notFull\n消费者等待 notEmpty\n",[21,3498,3496],{"__ignoreMap":124},[18,3500,3501,3502,3504],{},"使用 ",[21,3503,1670],{}," 时，生产者和消费者都在同一个 WaitSet 中，通常要：",[118,3506,3509],{"className":3507,"code":3508,"language":123},[121],"notifyAll();\n",[21,3510,3508],{"__ignoreMap":124},[18,3512,3513],{},"而 ReentrantLock 可以创建多个 Condition：",[118,3515,3518],{"className":3516,"code":3517,"language":123},[121],"Condition notFull = lock.newCondition();\nCondition notEmpty = lock.newCondition();\n",[21,3519,3517],{"__ignoreMap":124},[18,3521,3522],{},"生产者等待：",[118,3524,3527],{"className":3525,"code":3526,"language":123},[121],"while (queue.size() == capacity) {\n notFull.await();\n}\n",[21,3528,3526],{"__ignoreMap":124},[18,3530,3531],{},"消费者等待：",[118,3533,3536],{"className":3534,"code":3535,"language":123},[121],"while (queue.isEmpty()) {\n notEmpty.await();\n}\n",[21,3537,3535],{"__ignoreMap":124},[18,3539,3540],{},"生产完成：",[118,3542,3545],{"className":3543,"code":3544,"language":123},[121],"notEmpty.signal();\n",[21,3546,3544],{"__ignoreMap":124},[18,3548,3549],{},"消费完成：",[118,3551,3554],{"className":3552,"code":3553,"language":123},[121],"notFull.signal();\n",[21,3555,3553],{"__ignoreMap":124},[18,3557,3558],{},"这样可以精确唤醒，减少无效唤醒。",[3168,3560],{},[10,3562,3564],{"id":3563},"八底层实现不同","八、底层实现不同",[14,3566,1670],{"id":3567},"synchronized-2",[18,3569,3570],{},"经典理解：",[118,3572,3575],{"className":3573,"code":3574,"language":123},[121],"对象头 Mark Word\n+\nMonitor\n+\nJVM 锁优化\n",[21,3576,3574],{"__ignoreMap":124},[18,3578,3579],{},"JDK 8 中可能经历：",[118,3581,3584],{"className":3582,"code":3583,"language":123},[121],"偏向锁\n→ 轻量级锁\n→ 重量级锁\n",[21,3585,3583],{"__ignoreMap":124},[18,3587,3588],{},"这是 HotSpot 的 JVM 实现优化。",[14,3590,3115],{"id":3591},"reentrantlock-2",[18,3593,3594],{},"主要基于：",[118,3596,3599],{"className":3597,"code":3598,"language":123},[121],"AbstractQueuedSynchronizer\n",[21,3600,3598],{"__ignoreMap":124},[18,3602,3603],{},"也就是 AQS。",[18,3605,3606],{},"核心状态：",[118,3608,3611],{"className":3609,"code":3610,"language":123},[121],"volatile int state;\n",[21,3612,3610],{"__ignoreMap":124},[18,3614,3615],{},"独占锁时：",[118,3617,3620],{"className":3618,"code":3619,"language":123},[121],"state = 0 未加锁\nstate = 1 第一次获取\nstate > 1 重入次数\n",[21,3621,3619],{"__ignoreMap":124},[18,3623,3624,3625,3628],{},"竞争失败的线程进入 CLH 变体同步队列，并通过 ",[21,3626,3627],{},"park\u002Funpark"," 等待和唤醒。",[3168,3630],{},[10,3632,3634],{"id":3633},"九异常情况下的差异","九、异常情况下的差异",[18,3636,3637,3639],{},[21,3638,1670],{},"：",[118,3641,3644],{"className":3642,"code":3643,"language":123},[121],"synchronized (lock) {\n throw new RuntimeException();\n}\n",[21,3645,3643],{"__ignoreMap":124},[18,3647,3648],{},"离开同步块时，JVM 自动释放锁。",[18,3650,3651],{},"ReentrantLock：",[118,3653,3656],{"className":3654,"code":3655,"language":123},[121],"lock.lock();\ndoWork();\nlock.unlock();\n",[21,3657,3655],{"__ignoreMap":124},[18,3659,3660,3661,3664],{},"如果 ",[21,3662,3663],{},"doWork()"," 抛异常：",[118,3666,3669],{"className":3667,"code":3668,"language":123},[121],"unlock 没执行\n→ 锁永久未释放\n",[21,3670,3668],{"__ignoreMap":124},[18,3672,3673],{},"所以必须写：",[118,3675,3678],{"className":3676,"code":3677,"language":123},[121],"lock.lock();\ntry {\n doWork();\n} finally {\n lock.unlock();\n}\n",[21,3679,3677],{"__ignoreMap":124},[18,3681,3682],{},"这是 ReentrantLock 最常见的编码风险。",[3168,3684],{},[10,3686,3688],{"id":3687},"十性能区别","十、性能区别",[18,3690,3691],{},"早期 JDK 中，ReentrantLock 性能常常明显优于 synchronized。",[18,3693,3694],{},"但 JDK 6 以后，JVM 对 synchronized 做了大量优化：",[99,3696,3697,3700,3702,3705,3708],{},[102,3698,3699],{},"偏向锁",[102,3701,1943],{},[102,3703,3704],{},"自旋",[102,3706,3707],{},"锁消除",[102,3709,3710],{},"锁粗化",[18,3712,3713],{},"现代 JDK 中：",[63,3715,3716],{},[18,3717,3718],{},"两者性能差异通常不是选型的首要依据。",[18,3720,3721],{},"应该根据功能需求选择，而不是简单认为 ReentrantLock 一定更快。",[3168,3723],{},[10,3725,3727],{"id":3726},"十一什么时候使用-synchronized","十一、什么时候使用 synchronized",[18,3729,3730],{},"适合：",[99,3732,3733,3736,3739,3742,3745,3748],{},[102,3734,3735],{},"临界区简单",[102,3737,3738],{},"不需要公平锁",[102,3740,3741],{},"不需要超时获取",[102,3743,3744],{},"不需要中断锁等待",[102,3746,3747],{},"只有一个等待条件",[102,3749,3750],{},"希望代码简单、自动释放锁",[18,3752,1263],{},[118,3754,3757],{"className":3755,"code":3756,"language":123},[121],"public synchronized void increment() {\n count++;\n}\n",[21,3758,3756],{"__ignoreMap":124},[18,3760,3761],{},"一般优先原则：",[63,3763,3764],{},[18,3765,3766],{},"能用 synchronized 清晰表达时，优先用 synchronized。",[3168,3768],{},[10,3770,3772],{"id":3771},"十二什么时候使用-reentrantlock","十二、什么时候使用 ReentrantLock",[18,3774,3730],{},[99,3776,3777,3780,3786,3789,3792,3795,3798],{},[102,3778,3779],{},"需要公平锁",[102,3781,3782,3783],{},"需要 ",[21,3784,3785],{},"tryLock",[102,3787,3788],{},"需要超时获取锁",[102,3790,3791],{},"需要可中断等待",[102,3793,3794],{},"需要多个 Condition",[102,3796,3797],{},"需要查询等待队列、持锁状态",[102,3799,3800],{},"需要更精细的锁控制",[18,3802,3803],{},"例如转账时避免死锁：",[118,3805,3808],{"className":3806,"code":3807,"language":123},[121],"if (accountA.lock.tryLock(100, TimeUnit.MILLISECONDS)) {\n try {\n if (accountB.lock.tryLock(100, TimeUnit.MILLISECONDS)) {\n try {\n transfer();\n } finally {\n accountB.lock.unlock();\n }\n }\n } finally {\n accountA.lock.unlock();\n }\n}\n",[21,3809,3807],{"__ignoreMap":124},[18,3811,3812],{},"使用 synchronized 很难实现这种超时退避。",[3168,3814],{},[10,3816,3818],{"id":3817},"十三waitnotify-和-awaitsignal-对应关系","十三、wait\u002Fnotify 和 await\u002Fsignal 对应关系",[341,3820,3821,3829],{},[344,3822,3823],{},[347,3824,3825,3827],{},[350,3826,1670],{},[350,3828,3115],{},[360,3830,3831,3842,3853],{},[347,3832,3833,3837],{},[365,3834,3835],{},[21,3836,2100],{},[365,3838,3839],{},[21,3840,3841],{},"Condition.await()",[347,3843,3844,3848],{},[365,3845,3846],{},[21,3847,2519],{},[365,3849,3850],{},[21,3851,3852],{},"Condition.signal()",[347,3854,3855,3859],{},[365,3856,3857],{},[21,3858,2522],{},[365,3860,3861],{},[21,3862,3863],{},"Condition.signalAll()",[18,3865,3866],{},"两者都要求：",[63,3868,3869],{},[18,3870,3871],{},"调用等待或通知方法前，必须先持有对应的锁。",[18,3873,3874,3875,3878],{},"并且等待都应该放在 ",[21,3876,3877],{},"while"," 中：",[118,3880,3883],{"className":3881,"code":3882,"language":123},[121],"while (!conditionSatisfied()) {\n condition.await();\n}\n",[21,3884,3882],{"__ignoreMap":124},[18,3886,3887],{},"防止虚假唤醒和竞争后条件失效。",[3168,3889],{},[10,3891,3893],{"id":3892},"十四常见误区","十四、常见误区",[192,3895,3897],{"id":3896},"误区一reentrantlock-才支持可重入","误区一：ReentrantLock 才支持可重入",[18,3899,3900],{},"不对。两者都可重入。",[192,3902,3904],{"id":3903},"误区二reentrantlock-一定比-synchronized-快","误区二：ReentrantLock 一定比 synchronized 快",[18,3906,3907],{},"不对。现代 JVM 下要看场景，功能差异比纯性能更重要。",[192,3909,3911],{"id":3910},"误区三synchronized-会自动释放reentrantlock-不会","误区三：synchronized 会自动释放，ReentrantLock 不会",[18,3913,3914],{},"更准确地说：",[99,3916,3917,3920],{},[102,3918,3919],{},"synchronized 离开同步块时自动释放",[102,3921,3922],{},"ReentrantLock 必须显式 unlock",[192,3924,3926],{"id":3925},"误区四公平锁一定更好","误区四：公平锁一定更好",[18,3928,3929],{},"公平锁吞吐量通常更低，只在有明确公平性需求时使用。",[192,3931,3933],{"id":3932},"误区五trylock-失败后可以直接-unlock","误区五：tryLock 失败后可以直接 unlock",[18,3935,3936],{},"不可以。只有成功获取锁后才能释放。",[18,3938,3939],{},"正确写法：",[118,3941,3944],{"className":3942,"code":3943,"language":123},[121],"boolean locked = false;\ntry {\n locked = lock.tryLock();\n if (!locked) {\n return;\n }\n\n doWork();\n} finally {\n if (locked) {\n lock.unlock();\n }\n}\n",[21,3945,3943],{"__ignoreMap":124},[3168,3947],{},[14,3949,3950],{"id":3950},"相关主题",[99,3952,3953],{},[102,3954,3955],{},[77,3956,1659],{"href":3957},"\u002Fwiki\u002Fjava\u002Fjdk8-synchronized-lock-states\u002F",{"title":124,"searchDepth":151,"depth":151,"links":3959},[3960,3961,3965,3971,3972,3979],{"id":73,"depth":151,"text":73},{"id":3129,"depth":151,"text":3130,"children":3962},[3963,3964],{"id":1670,"depth":157,"text":1670},{"id":3153,"depth":157,"text":3115},{"id":3172,"depth":151,"text":3173,"children":3966},[3967,3968,3969,3970],{"id":3343,"depth":157,"text":1670},{"id":3355,"depth":157,"text":3115},{"id":3455,"depth":157,"text":3455},{"id":3464,"depth":157,"text":3464},{"id":3567,"depth":151,"text":1670},{"id":3591,"depth":151,"text":3115,"children":3973},[3974,3975,3976,3977,3978],{"id":3896,"depth":157,"text":3897},{"id":3903,"depth":157,"text":3904},{"id":3910,"depth":157,"text":3911},{"id":3925,"depth":157,"text":3926},{"id":3932,"depth":157,"text":3933},{"id":3950,"depth":151,"text":3950},"wiki:java:synchronized-vs-reentrantlock","对比 synchronized 与 ReentrantLock 的实现、可重入、公平锁、中断、超时、Condition 和适用场景。",{},71,"\u002Fjava\u002Fsynchronized-vs-reentrantlock",{"title":3001,"description":3981},"java\u002Fsynchronized-vs-reentrantlock","2026-07-21","HvwBdM7dDk9OpIeOwtk34xX3bS9W_vivGkHtOntEom0",{"id":3990,"title":3991,"body":3992,"commentId":5166,"description":5167,"difficulty":3063,"draft":1646,"extension":1647,"meta":5168,"navigation":780,"order":5169,"path":5170,"section":1651,"seo":5171,"stem":5172,"updated":5173,"__hash__":5174},"java\u002Fjava\u002Fkafka-message-loss-prevention.md","Kafka 如何保证消息不丢失",{"type":7,"value":3993,"toc":5121},[3994,3997,3999,4016,4018,4025,4027,4036,4038,4041,4048,4051,4055,4058,4072,4075,4079,4085,4092,4147,4150,4161,4170,4174,4177,4206,4209,4212,4226,4230,4233,4242,4248,4282,4289,4293,4296,4302,4305,4308,4314,4317,4321,4325,4328,4334,4337,4340,4344,4347,4350,4356,4359,4365,4370,4376,4379,4385,4388,4393,4396,4400,4409,4415,4418,4427,4430,4436,4446,4451,4454,4458,4462,4471,4474,4480,4483,4487,4490,4496,4499,4545,4548,4552,4555,4561,4564,4581,4588,4592,4595,4601,4604,4613,4616,4619,4623,4626,4632,4636,4639,4642,4648,4651,4654,4674,4681,4684,4690,4696,4700,4703,4705,4711,4717,4720,4734,4738,4809,4812,4819,4823,4873,4876,4883,4886,4890,5000,5004,5011,5019,5023,5029,5033,5036,5040,5043,5047,5050,5054,5057,5077,5080,5082,5119],[10,3995,3991],{"id":3996},"kafka-如何保证消息不丢失",[14,3998,16],{"id":16},[63,4000,4001],{},[18,4002,4003,4004,4007,4008,4011,4012,4015],{},"Kafka 保证消息不丢失需要覆盖生产者、Broker 和消费者三段链路。生产者侧使用 ",[21,4005,4006],{},"acks=all","、开启重试和幂等生产，并检查发送回调，对最终失败进行落库、告警或补偿；Broker 侧通常设置三副本、",[21,4009,4010],{},"min.insync.replicas=2","，并关闭非同步副本选举，即配置 ",[21,4013,4014],{},"unclean.leader.election.enable=false","，保证消息在足够多的同步副本写入后才确认成功；消费者侧关闭自动提交，在业务处理成功后再提交 Offset，失败时不提交以便重新消费。这样通常实现至少一次投递，所以消费端还必须通过事件 ID、唯一索引或状态机保证幂等。涉及数据库与 Kafka 的一致性时，可以使用 Transactional Outbox；消费端需要应对重复消息时，可以使用 Inbox。Kafka 的消息不丢失是端到端保障，不是只配置一个参数。",[18,4017,61],{},[63,4019,4020],{},[18,4021,4022],{},[68,4023,4024],{},"生产者确认成功，Broker 多副本可靠保存，消费者处理成功后提交，业务端用幂等和补偿兜底。",[14,4026,73],{"id":73},[18,4028,4029],{},[77,4030,4033],{"href":4031,"target":80,"rel":4032},"\u002Fimages\u002Fwiki\u002Fjava\u002Fkafka-message-loss-prevention.svg",[82,83],[85,4034],{"src":4031,"alt":4035},"Kafka 消息不丢失的端到端保障链路",[14,4037,90],{"id":90},[18,4039,4040],{},"Kafka 消息不丢失不是靠某一个参数实现的，而是一个端到端问题：",[63,4042,4043],{},[18,4044,4045],{},[68,4046,4047],{},"生产者必须确认消息发送成功，Broker 必须把消息可靠地保存在足够多的副本中，消费者必须在业务处理成功后再提交 Offset。",[18,4049,4050],{},"其中任何一个环节处理不当，都可能出现“业务上看起来消息丢了”的情况。",[14,4052,4054],{"id":4053},"一先明确什么叫消息丢失","一、先明确什么叫“消息丢失”",[18,4056,4057],{},"常见的丢失场景主要有四类：",[708,4059,4060,4063,4066,4069],{},[102,4061,4062],{},"生产者调用发送方法后没有检查结果，实际发送失败却被业务忽略。",[102,4064,4065],{},"Leader 收到消息后就返回成功，消息还未复制到 Follower，Leader 随后故障。",[102,4067,4068],{},"消费者先提交 Offset，再执行业务；业务处理失败后，消息不会再次投递。",[102,4070,4071],{},"Kafka 中的消息没有丢，但写数据库、调用下游等业务操作失败，又没有补偿机制。",[18,4073,4074],{},"因此，Kafka 中仍能查到消息，不代表业务一定处理成功；反过来，业务没有结果，也不一定是 Broker 丢了消息。",[14,4076,4078],{"id":4077},"二生产者如何避免丢消息","二、生产者如何避免丢消息",[192,4080,4082,4083],{"id":4081},"_1-使用-acksall","1. 使用 ",[21,4084,4006],{},[18,4086,4087,4088,4091],{},"生产者的 ",[21,4089,4090],{},"acks"," 决定 Broker 在什么条件下确认发送成功：",[341,4093,4094,4107],{},[344,4095,4096],{},[347,4097,4098,4101,4104],{},[350,4099,4100],{},"配置",[350,4102,4103],{},"确认时机",[350,4105,4106],{},"风险",[360,4108,4109,4122,4135],{},[347,4110,4111,4116,4119],{},[365,4112,4113],{},[21,4114,4115],{},"acks=0",[365,4117,4118],{},"不等待 Broker 响应",[365,4120,4121],{},"发送失败也无法感知，风险最高",[347,4123,4124,4129,4132],{},[365,4125,4126],{},[21,4127,4128],{},"acks=1",[365,4130,4131],{},"Leader 写入本地日志后返回",[365,4133,4134],{},"Leader 故障且副本尚未同步时可能丢失",[347,4136,4137,4141,4144],{},[365,4138,4139],{},[21,4140,4006],{},[365,4142,4143],{},"当前 ISR 中的副本都确认后返回",[365,4145,4146],{},"Kafka 能提供的最强生产者确认保证",[18,4148,4149],{},"关键配置：",[118,4151,4155],{"className":4152,"code":4153,"language":4154,"meta":124,"style":124},"language-properties shiki shiki-themes github-light github-dark","acks=all\n","properties",[21,4156,4157],{"__ignoreMap":124},[142,4158,4159],{"class":144,"line":145},[142,4160,4153],{},[18,4162,4163,4165,4166,4169],{},[21,4164,4006],{}," 并不等于绝对不丢。它还需要与副本数和 ",[21,4167,4168],{},"min.insync.replicas"," 配合，否则 ISR 中只剩 Leader 一个副本时，依然可能成功写入。",[192,4171,4173],{"id":4172},"_2-开启重试和幂等生产","2. 开启重试和幂等生产",[18,4175,4176],{},"网络抖动、Leader 切换等临时故障可能导致发送失败，生产者需要允许重试：",[118,4178,4180],{"className":4152,"code":4179,"language":4154,"meta":124,"style":124},"enable.idempotence=true\nacks=all\nretries=2147483647\nmax.in.flight.requests.per.connection=5\ndelivery.timeout.ms=120000\n",[21,4181,4182,4187,4191,4196,4201],{"__ignoreMap":124},[142,4183,4184],{"class":144,"line":145},[142,4185,4186],{},"enable.idempotence=true\n",[142,4188,4189],{"class":144,"line":151},[142,4190,4153],{},[142,4192,4193],{"class":144,"line":157},[142,4194,4195],{},"retries=2147483647\n",[142,4197,4198],{"class":144,"line":163},[142,4199,4200],{},"max.in.flight.requests.per.connection=5\n",[142,4202,4203],{"class":144,"line":169},[142,4204,4205],{},"delivery.timeout.ms=120000\n",[18,4207,4208],{},"幂等生产者会给消息附加 Producer ID 和序列号，使 Broker 能识别同一生产会话内的重复写入，避免因重试产生重复消息。",[18,4210,4211],{},"需要注意：",[99,4213,4214,4217,4223],{},[102,4215,4216],{},"幂等生产解决的是重试导致的重复写入，不是发送失败后的业务补偿。",[102,4218,4219,4222],{},[21,4220,4221],{},"delivery.timeout.ms"," 到期后，生产者仍可能最终失败。",[102,4224,4225],{},"业务不能无限依赖客户端重试，最终失败必须记录、告警或进入补偿流程。",[192,4227,4229],{"id":4228},"_3-必须检查发送结果","3. 必须检查发送结果",[18,4231,4232],{},"下面这种“只发送、不处理结果”的写法存在风险：",[118,4234,4236],{"className":136,"code":4235,"language":138,"meta":124,"style":124},"producer.send(record);\n",[21,4237,4238],{"__ignoreMap":124},[142,4239,4240],{"class":144,"line":145},[142,4241,4235],{},[18,4243,4244,4245,4247],{},"应该检查回调或 ",[21,4246,1226],{}," 的执行结果：",[118,4249,4251],{"className":136,"code":4250,"language":138,"meta":124,"style":124},"producer.send(record, (metadata, exception) -> {\n if (exception != null) {\n \u002F\u002F 记录原始消息、告警并进入补偿流程\n handleSendFailure(record, exception);\n }\n});\n",[21,4252,4253,4258,4263,4268,4273,4277],{"__ignoreMap":124},[142,4254,4255],{"class":144,"line":145},[142,4256,4257],{},"producer.send(record, (metadata, exception) -> {\n",[142,4259,4260],{"class":144,"line":151},[142,4261,4262],{}," if (exception != null) {\n",[142,4264,4265],{"class":144,"line":157},[142,4266,4267],{}," \u002F\u002F 记录原始消息、告警并进入补偿流程\n",[142,4269,4270],{"class":144,"line":163},[142,4271,4272],{}," handleSendFailure(record, exception);\n",[142,4274,4275],{"class":144,"line":169},[142,4276,955],{},[142,4278,4279],{"class":144,"line":175},[142,4280,4281],{},"});\n",[18,4283,4284,4285,4288],{},"序列化失败、鉴权失败、消息过大和超时等错误，最终都需要业务明确处理。不能把“调用过 ",[21,4286,4287],{},"send","”当成“消息已经可靠进入 Kafka”。",[192,4290,4292],{"id":4291},"_4-数据库与-kafka-的一致性","4. 数据库与 Kafka 的一致性",[18,4294,4295],{},"如果业务流程是：",[118,4297,4300],{"className":4298,"code":4299,"language":123,"meta":124},[121],"更新数据库\n→\n发送 Kafka 消息\n",[21,4301,4299],{"__ignoreMap":124},[18,4303,4304],{},"数据库更新成功、消息发送失败时，仍然会造成业务事件丢失。",[18,4306,4307],{},"常见解决方式是本地消息表，也叫 Transactional Outbox：",[118,4309,4312],{"className":4310,"code":4311,"language":123,"meta":124},[121],"同一个数据库事务\n├── 更新业务数据\n└── 写入待发送事件表\n\n事务提交后\n→ 后台任务投递 Kafka\n→ 成功后标记事件已发送\n",[21,4313,4311],{"__ignoreMap":124},[18,4315,4316],{},"这样即使 Kafka 暂时不可用，消息也可以从本地消息表继续重试。Kafka 事务可以保证 Kafka 内部多条记录及消费 Offset 的原子性，但不会自动把外部数据库事务包含进来。",[14,4318,4320],{"id":4319},"三broker-如何保证消息可靠保存","三、Broker 如何保证消息可靠保存",[192,4322,4324],{"id":4323},"_1-合理设置副本数","1. 合理设置副本数",[18,4326,4327],{},"生产环境通常使用：",[118,4329,4332],{"className":4330,"code":4331,"language":123,"meta":124},[121],"replication.factor = 3\n",[21,4333,4331],{"__ignoreMap":124},[18,4335,4336],{},"一个分区包含一个 Leader 和多个 Follower。生产者与 Leader 交互，Follower 从 Leader 复制日志。某个 Broker 故障后，可以从仍然同步的副本中选举新 Leader。",[18,4338,4339],{},"副本数提高的是容错能力，但副本只有真正保持同步才有意义。",[192,4341,4343],{"id":4342},"_2-理解-isr","2. 理解 ISR",[18,4345,4346],{},"ISR 是 In-Sync Replicas，即当前与 Leader 保持同步的副本集合。",[18,4348,4349],{},"例如一个三副本分区：",[118,4351,4354],{"className":4352,"code":4353,"language":123,"meta":124},[121],"Leader A\nFollower B\nFollower C\n\nISR = [A, B, C]\n",[21,4355,4353],{"__ignoreMap":124},[18,4357,4358],{},"如果 C 长时间跟不上 Leader，它会被移出 ISR：",[118,4360,4363],{"className":4361,"code":4362,"language":123,"meta":124},[121],"ISR = [A, B]\n",[21,4364,4362],{"__ignoreMap":124},[18,4366,4367,4369],{},[21,4368,4006],{}," 等待的是当前 ISR 的确认，而不是永远等待所有配置副本。",[192,4371,4373,4374],{"id":4372},"_3-配置-mininsyncreplicas","3. 配置 ",[21,4375,4168],{},[18,4377,4378],{},"推荐组合：",[118,4380,4383],{"className":4381,"code":4382,"language":123,"meta":124},[121],"replication.factor = 3\nmin.insync.replicas = 2\nacks = all\n",[21,4384,4382],{"__ignoreMap":124},[18,4386,4387],{},"它表达的含义是：",[63,4389,4390],{},[18,4391,4392],{},"至少要有两个同步副本可用，写入才允许成功。",[18,4394,4395],{},"如果 ISR 只剩一个副本，Broker 会拒绝写入。此时系统牺牲部分可用性，避免在单副本状态下继续写入并承担更高的数据丢失风险。",[192,4397,4399],{"id":4398},"_4-关闭非同步副本选举","4. 关闭非同步副本选举",[118,4401,4403],{"className":4152,"code":4402,"language":4154,"meta":124,"style":124},"unclean.leader.election.enable=false\n",[21,4404,4405],{"__ignoreMap":124},[142,4406,4407],{"class":144,"line":145},[142,4408,4402],{},[18,4410,4411,4414],{},[21,4412,4413],{},"unclean leader election"," 指允许不在 ISR 中的副本被选举为 Leader。如果所有同步副本都不可用，非 ISR 副本可能缺少最新消息；将它选为 Leader 虽然能更快恢复分区服务，却可能造成日志回退和数据丢失。",[18,4416,4417],{},"因此，对数据可靠性要求较高的场景应明确配置：",[63,4419,4420],{},[18,4421,4422],{},[68,4423,4424,4425,52],{},"关闭非同步副本选举：",[21,4426,4014],{},[18,4428,4429],{},"这是一个典型的取舍：",[118,4431,4434],{"className":4432,"code":4433,"language":123,"meta":124},[121],"开启非同步副本选举：可用性更高，但可能丢失消息\n关闭非同步副本选举：数据可靠性更强，但分区可能暂时不可用\n",[21,4435,4433],{"__ignoreMap":124},[192,4437,4439,4440,4442,4443],{"id":4438},"_5-acksall-不等于每条消息都立即-fsync","5. ",[21,4441,4006],{}," 不等于每条消息都立即 ",[21,4444,4445],{},"fsync",[18,4447,4448,4449,52],{},"Kafka 的持久性主要依赖顺序写日志、操作系统页缓存和多副本机制。Broker 返回成功，并不表示每个副本都对该消息单独执行了一次物理磁盘 ",[21,4450,4445],{},[18,4452,4453],{},"实际生产中，通常通过跨 Broker 副本降低单机和单盘故障风险，而不是强制每条消息同步刷盘。若多个副本同时发生不可恢复故障，仍不存在数学意义上的绝对零丢失。",[14,4455,4457],{"id":4456},"四消费者如何避免消费丢失","四、消费者如何避免“消费丢失”",[192,4459,4461],{"id":4460},"_1-关闭自动提交-offset","1. 关闭自动提交 Offset",[118,4463,4465],{"className":4152,"code":4464,"language":4154,"meta":124,"style":124},"enable.auto.commit=false\n",[21,4466,4467],{"__ignoreMap":124},[142,4468,4469],{"class":144,"line":145},[142,4470,4464],{},[18,4472,4473],{},"自动提交可能出现以下顺序：",[118,4475,4478],{"className":4476,"code":4477,"language":123,"meta":124},[121],"拉取消息\n→ 自动提交 Offset\n→ 执行业务\n→ 进程崩溃\n",[21,4479,4477],{"__ignoreMap":124},[18,4481,4482],{},"重启后，消费者会从已提交的下一个 Offset 继续消费，刚才尚未处理成功的消息就被跳过了。",[192,4484,4486],{"id":4485},"_2-业务成功后再提交-offset","2. 业务成功后再提交 Offset",[18,4488,4489],{},"更可靠的顺序是：",[118,4491,4494],{"className":4492,"code":4493,"language":123,"meta":124},[121],"拉取消息\n→ 执行业务\n→ 业务成功\n→ 提交 Offset\n",[21,4495,4493],{"__ignoreMap":124},[18,4497,4498],{},"如果业务处理失败，就不提交 Offset，让消息后续重新消费：",[118,4500,4502],{"className":136,"code":4501,"language":138,"meta":124,"style":124},"while (true) {\n ConsumerRecords\u003CString, String> records = consumer.poll(Duration.ofSeconds(1));\n\n for (ConsumerRecord\u003CString, String> record : records) {\n process(record);\n }\n\n consumer.commitSync();\n}\n",[21,4503,4504,4509,4514,4518,4523,4528,4532,4536,4541],{"__ignoreMap":124},[142,4505,4506],{"class":144,"line":145},[142,4507,4508],{},"while (true) {\n",[142,4510,4511],{"class":144,"line":151},[142,4512,4513],{}," ConsumerRecords\u003CString, String> records = consumer.poll(Duration.ofSeconds(1));\n",[142,4515,4516],{"class":144,"line":157},[142,4517,781],{"emptyLinePlaceholder":780},[142,4519,4520],{"class":144,"line":163},[142,4521,4522],{}," for (ConsumerRecord\u003CString, String> record : records) {\n",[142,4524,4525],{"class":144,"line":169},[142,4526,4527],{}," process(record);\n",[142,4529,4530],{"class":144,"line":175},[142,4531,955],{},[142,4533,4534],{"class":144,"line":181},[142,4535,781],{"emptyLinePlaceholder":780},[142,4537,4538],{"class":144,"line":187},[142,4539,4540],{}," consumer.commitSync();\n",[142,4542,4543],{"class":144,"line":789},[142,4544,1081],{},[18,4546,4547],{},"示例表达的是基本原则。实际批量消费时，如果一批消息中只有部分成功，需要准确管理各分区可提交的 Offset，不能直接把失败消息之后的位置一起提交。",[192,4549,4551],{"id":4550},"_3-为什么还需要业务幂等","3. 为什么还需要业务幂等",[18,4553,4554],{},"“处理成功后提交”可以避免消息被跳过，但会引入重复：",[118,4556,4559],{"className":4557,"code":4558,"language":123,"meta":124},[121],"业务处理成功\n→ 提交 Offset 前进程崩溃\n→ 重启后再次消费同一条消息\n",[21,4560,4558],{"__ignoreMap":124},[18,4562,4563],{},"因此，可靠消费通常采用至少一次投递，并在业务层保证幂等。常见方式包括：",[99,4565,4566,4569,4572,4575,4578],{},[102,4567,4568],{},"使用事件 ID 建立数据库唯一索引。",[102,4570,4571],{},"建立消费去重表或 Inbox 表。",[102,4573,4574],{},"使用业务状态机，只允许合法状态转换。",[102,4576,4577],{},"更新时带版本号或业务条件。",[102,4579,4580],{},"对扣款、发券等操作使用唯一业务流水号。",[63,4582,4583],{},[18,4584,4585],{},[68,4586,4587],{},"不丢消息通常意味着允许重复，再通过幂等消除重复影响。",[192,4589,4591],{"id":4590},"_4-kafka-内部链路的-exactly-once","4. Kafka 内部链路的 Exactly Once",[18,4593,4594],{},"如果消费 Kafka 后仍然写回 Kafka，可以使用 Kafka 事务，把输出记录和消费 Offset 放进同一个事务：",[118,4596,4599],{"className":4597,"code":4598,"language":123,"meta":124},[121],"消费消息\n→ 处理\n→ 写入下游 Topic\n→ sendOffsetsToTransaction\n→ 提交事务\n",[21,4600,4598],{"__ignoreMap":124},[18,4602,4603],{},"下游消费者设置：",[118,4605,4607],{"className":4152,"code":4606,"language":4154,"meta":124,"style":124},"isolation.level=read_committed\n",[21,4608,4609],{"__ignoreMap":124},[142,4610,4611],{"class":144,"line":145},[142,4612,4606],{},[18,4614,4615],{},"这样只读取已提交事务的数据。",[18,4617,4618],{},"但如果最终写入的是 MySQL 等外部系统，Kafka 事务并不能自动保证 Kafka 与数据库的原子性。生产方可以用 Outbox 保证事件可靠发出，消费方可以用 Inbox 应对重复消费，具体区别见下一节。",[14,4620,4622],{"id":4621},"五outbox-与-inbox-分别是什么","五、Outbox 与 Inbox 分别是什么",[18,4624,4625],{},"Outbox 和 Inbox 都借助数据库本地事务解决消息链路中的一致性问题，但它们位于不同位置：",[118,4627,4630],{"className":4628,"code":4629,"language":123,"meta":124},[121],"业务生产方 → Outbox → Kafka → Inbox → 业务消费方\n",[21,4631,4629],{"__ignoreMap":124},[192,4633,4635],{"id":4634},"_1-outbox保证业务事件可靠发出","1. Outbox：保证业务事件可靠发出",[18,4637,4638],{},"Outbox 位于消息生产方，用来解决“数据库更新成功，但 Kafka 消息发送失败”的双写不一致问题。",[18,4640,4641],{},"核心流程：",[118,4643,4646],{"className":4644,"code":4645,"language":123,"meta":124},[121],"同一个数据库事务\n├── 更新业务数据\n└── 写入 Outbox 事件表\n\n事务提交\n→ 后台投递程序扫描 Outbox\n→ 发送 Kafka\n→ 收到成功确认后标记已发送\n",[21,4647,4645],{"__ignoreMap":124},[18,4649,4650],{},"例如创建订单时，不直接把“订单创建事件”的可靠性寄托在一次 Kafka 调用上，而是在创建订单的同一个数据库事务中写入一条 Outbox 记录。即使 Kafka 暂时不可用，后台任务仍可继续重试。",[18,4652,4653],{},"Outbox 的关键点：",[99,4655,4656,4659,4665,4668,4671],{},[102,4657,4658],{},"业务数据和事件记录必须写入同一个数据库事务。",[102,4660,4661,4662,52],{},"每条事件应有全局唯一的 ",[21,4663,4664],{},"eventId",[102,4666,4667],{},"投递程序可以轮询事件表，也可以通过 CDC 捕获新增事件。",[102,4669,4670],{},"“发送成功但标记失败”可能导致再次投递，因此消费者仍需幂等。",[102,4672,4673],{},"Outbox 解决的是事件可靠发出，不保证消费者一定处理成功。",[18,4675,4676,4677,4680],{},"这里的 CDC 是 ",[68,4678,4679],{},"Change Data Capture（变更数据捕获）","。它会读取数据库的变更日志，例如 MySQL Binlog，捕获数据的新增、修改和删除，再把变更发送到 Kafka。常用工具有 Debezium、Canal。",[18,4682,4683],{},"在 Outbox 场景中，它的工作链路是：",[118,4685,4688],{"className":4686,"code":4687,"language":123,"meta":124},[121],"业务事务写入业务表和 Outbox 表\n→ CDC 监听 Binlog\n→ 捕获新增的 Outbox 记录\n→ 发送到 Kafka\n",[21,4689,4687],{"__ignoreMap":124},[18,4691,4692,4693,4695],{},"相比定时扫描 Outbox 表，CDC 延迟更低，也能减少频繁查询数据库的压力。但消息链路仍可能产生重复，因此必须保留 ",[21,4694,4664],{},"，并由消费端保证幂等。",[192,4697,4699],{"id":4698},"_2-inbox保证重复消息只产生一次业务效果","2. Inbox：保证重复消息只产生一次业务效果",[18,4701,4702],{},"Inbox 位于消息消费方，用来记录已经处理过的事件，主要解决至少一次投递带来的重复消费问题。",[18,4704,4641],{},[118,4706,4709],{"className":4707,"code":4708,"language":123,"meta":124},[121],"收到 Kafka 消息\n→ 开启数据库事务\n→ 根据 eventId 写入 Inbox 记录\n→ 执行业务更新\n→ 提交数据库事务\n→ 提交 Kafka Offset\n",[21,4710,4708],{"__ignoreMap":124},[18,4712,4713,4714,4716],{},"Inbox 表通常对 ",[21,4715,4664],{}," 建立唯一索引。重复消息到达时，如果发现该事件已经存在，就不再重复执行业务逻辑。",[18,4718,4719],{},"Inbox 的关键点：",[99,4721,4722,4725,4728,4731],{},[102,4723,4724],{},"Inbox 记录和业务更新必须处于同一个数据库事务。",[102,4726,4727],{},"唯一索引负责防止同一事件被并发重复处理。",[102,4729,4730],{},"数据库事务提交后、Offset 提交前发生故障，消息仍会重投，但 Inbox 可以识别重复。",[102,4732,4733],{},"如果消费逻辑还会调用外部 HTTP 接口，Inbox 无法自动让数据库和外部接口形成原子事务；仍需下游幂等、重试或补偿。",[192,4735,4737],{"id":4736},"_3-两者的区别","3. 两者的区别",[341,4739,4740,4752],{},[344,4741,4742],{},[347,4743,4744,4746,4749],{},[350,4745,3182],{},[350,4747,4748],{},"Outbox",[350,4750,4751],{},"Inbox",[360,4753,4754,4765,4776,4787,4798],{},[347,4755,4756,4759,4762],{},[365,4757,4758],{},"所在位置",[365,4760,4761],{},"消息生产方",[365,4763,4764],{},"消息消费方",[347,4766,4767,4770,4773],{},[365,4768,4769],{},"主要目标",[365,4771,4772],{},"防止业务成功但事件未发出",[365,4774,4775],{},"防止重复消息重复产生业务效果",[347,4777,4778,4781,4784],{},[365,4779,4780],{},"本地事务内容",[365,4782,4783],{},"业务更新 + 写事件表",[365,4785,4786],{},"写消费记录 + 业务更新",[347,4788,4789,4792,4795],{},[365,4790,4791],{},"后台动作",[365,4793,4794],{},"把待发送事件投递到 Kafka",[365,4796,4797],{},"通常不需要再次投递",[347,4799,4800,4803,4806],{},[365,4801,4802],{},"仍需注意",[365,4804,4805],{},"投递过程可能产生重复消息",[365,4807,4808],{},"外部调用仍需幂等或补偿",[18,4810,4811],{},"一句话区分：",[63,4813,4814],{},[18,4815,4816],{},[68,4817,4818],{},"Outbox 保证“该发的消息最终发出去”，Inbox 保证“重复收到的消息不会重复生效”。",[14,4820,4822],{"id":4821},"六三种投递语义","六、三种投递语义",[341,4824,4825,4838],{},[344,4826,4827],{},[347,4828,4829,4832,4835],{},[350,4830,4831],{},"语义",[350,4833,4834],{},"Offset 与业务处理顺序",[350,4836,4837],{},"结果",[360,4839,4840,4851,4862],{},[347,4841,4842,4845,4848],{},[365,4843,4844],{},"At Most Once",[365,4846,4847],{},"先提交，再处理",[365,4849,4850],{},"可能丢失，通常不重复",[347,4852,4853,4856,4859],{},[365,4854,4855],{},"At Least Once",[365,4857,4858],{},"先处理，再提交",[365,4860,4861],{},"不轻易丢失，可能重复",[347,4863,4864,4867,4870],{},[365,4865,4866],{},"Exactly Once",[365,4868,4869],{},"事务或幂等机制协调",[365,4871,4872],{},"业务效果恰好一次",[18,4874,4875],{},"绝大多数业务系统采用：",[63,4877,4878],{},[18,4879,4880],{},[68,4881,4882],{},"Kafka 至少一次投递 + 消费端业务幂等。",[18,4884,4885],{},"这通常比追求所有环节的强事务更容易实现，也更便于扩展。",[14,4887,4889],{"id":4888},"七常见故障与保障措施","七、常见故障与保障措施",[341,4891,4892,4905],{},[344,4893,4894],{},[347,4895,4896,4899,4902],{},[350,4897,4898],{},"故障场景",[350,4900,4901],{},"可能后果",[350,4903,4904],{},"主要保障",[360,4906,4907,4918,4931,4944,4956,4967,4978,4989],{},[347,4908,4909,4912,4915],{},[365,4910,4911],{},"生产者网络抖动",[365,4913,4914],{},"发送失败或结果未知",[365,4916,4917],{},"重试、幂等生产、回调处理",[347,4919,4920,4923,4926],{},[365,4921,4922],{},"Leader 写入后立即故障",[365,4924,4925],{},"未同步消息丢失",[365,4927,4928,4930],{},[21,4929,4006],{},"、副本、ISR",[347,4932,4933,4936,4939],{},[365,4934,4935],{},"ISR 只剩一个副本",[365,4937,4938],{},"单点故障风险升高",[365,4940,4941,4943],{},[21,4942,4168],{}," 拒绝写入",[347,4945,4946,4949,4952],{},[365,4947,4948],{},"同步副本全部不可用",[365,4950,4951],{},"非同步副本选主后日志回退",[365,4953,4424,4954],{},[21,4955,4014],{},[347,4957,4958,4961,4964],{},[365,4959,4960],{},"消费者先提交后处理",[365,4962,4963],{},"业务消息被跳过",[365,4965,4966],{},"关闭自动提交，成功后提交",[347,4968,4969,4972,4975],{},[365,4970,4971],{},"处理成功但提交前崩溃",[365,4973,4974],{},"重复消费",[365,4976,4977],{},"业务幂等、唯一流水号",[347,4979,4980,4983,4986],{},[365,4981,4982],{},"数据库成功、Kafka 失败",[365,4984,4985],{},"业务事件未发出",[365,4987,4988],{},"Transactional Outbox",[347,4990,4991,4994,4997],{},[365,4992,4993],{},"Kafka 成功、下游失败",[365,4995,4996],{},"业务结果缺失",[365,4998,4999],{},"重试、死信、补偿、告警",[14,5001,5003],{"id":5002},"八常见误区","八、常见误区",[192,5005,5007,5008,5010],{"id":5006},"误区一配置-acksall-就绝对不会丢","误区一：配置 ",[21,5009,4006],{}," 就绝对不会丢",[18,5012,5013,5015,5016,5018],{},[21,5014,4006],{}," 只解决生产者到 Broker 的确认强度，还要配合副本数、",[21,5017,4168],{},"、正确选主和消费者提交策略。",[192,5020,5022],{"id":5021},"误区二配置无限重试就不会丢","误区二：配置无限重试就不会丢",[18,5024,5025,5026,5028],{},"重试仍然受 ",[21,5027,4221],{}," 等条件限制，而且权限错误、序列化错误等问题无法靠盲目重试解决。最终失败必须被业务感知和补偿。",[192,5030,5032],{"id":5031},"误区三手动提交-offset-就是-exactly-once","误区三：手动提交 Offset 就是 Exactly Once",[18,5034,5035],{},"手动提交只能帮助建立“处理成功后提交”的顺序，崩溃窗口仍可能造成重复消费，因此还需要业务幂等。",[192,5037,5039],{"id":5038},"误区四kafka-事务可以自动覆盖数据库","误区四：Kafka 事务可以自动覆盖数据库",[18,5041,5042],{},"Kafka 事务主要协调 Kafka 内部的消息与 Offset，不会自动与 MySQL 等外部数据库形成同一个原子事务。",[192,5044,5046],{"id":5045},"误区五broker-返回成功就等于所有副本已经物理刷盘","误区五：Broker 返回成功就等于所有副本已经物理刷盘",[18,5048,5049],{},"Kafka 的确认、副本复制和磁盘刷盘是不同概念。高可靠主要依靠多副本和同步副本约束，而不是把每条消息都单独同步刷盘。",[14,5051,5053],{"id":5052},"九监控和运维同样重要","九、监控和运维同样重要",[18,5055,5056],{},"配置正确后，还应持续监控：",[99,5058,5059,5062,5065,5068,5071,5074],{},[102,5060,5061],{},"发送失败率、重试次数和发送延迟。",[102,5063,5064],{},"ISR 收缩、未充分复制分区和离线分区。",[102,5066,5067],{},"Broker 磁盘空间、磁盘延迟和网络异常。",[102,5069,5070],{},"消费积压、消费失败、重平衡次数。",[102,5072,5073],{},"死信消息和补偿任务堆积。",[102,5075,5076],{},"业务事件与最终结果的对账差异。",[18,5078,5079],{},"没有监控和对账，即使消息已经丢失，系统也可能长期无法发现。",[14,5081,1570],{"id":1570},[99,5083,5084,5091,5098,5105,5112],{},[102,5085,5086],{},[77,5087,5090],{"href":5088,"rel":5089},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fconfiguration\u002Fproducer-configs\u002F",[1579],"Apache Kafka Producer Configs",[102,5092,5093],{},[77,5094,5097],{"href":5095,"rel":5096},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fconfiguration\u002Fbroker-configs\u002F",[1579],"Apache Kafka Broker Configs",[102,5099,5100],{},[77,5101,5104],{"href":5102,"rel":5103},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fconfiguration\u002Fconsumer-configs\u002F",[1579],"Apache Kafka Consumer Configs",[102,5106,5107],{},[77,5108,5111],{"href":5109,"rel":5110},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fdesign\u002Fdesign\u002F",[1579],"Apache Kafka Design：Message Delivery Semantics",[102,5113,5114],{},[77,5115,5118],{"href":5116,"rel":5117},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fjavadoc\u002Forg\u002Fapache\u002Fkafka\u002Fclients\u002Fconsumer\u002FKafkaConsumer.html",[1579],"Apache KafkaConsumer JavaDoc",[1596,5120,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":5122},[5123,5124,5125,5126,5127,5134,5143,5149,5154,5155,5156,5164,5165],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":4053,"depth":151,"text":4054},{"id":4077,"depth":151,"text":4078,"children":5128},[5129,5131,5132,5133],{"id":4081,"depth":157,"text":5130},"1. 使用 acks=all",{"id":4172,"depth":157,"text":4173},{"id":4228,"depth":157,"text":4229},{"id":4291,"depth":157,"text":4292},{"id":4319,"depth":151,"text":4320,"children":5135},[5136,5137,5138,5140,5141],{"id":4323,"depth":157,"text":4324},{"id":4342,"depth":157,"text":4343},{"id":4372,"depth":157,"text":5139},"3. 配置 min.insync.replicas",{"id":4398,"depth":157,"text":4399},{"id":4438,"depth":157,"text":5142},"5. acks=all 不等于每条消息都立即 fsync",{"id":4456,"depth":151,"text":4457,"children":5144},[5145,5146,5147,5148],{"id":4460,"depth":157,"text":4461},{"id":4485,"depth":157,"text":4486},{"id":4550,"depth":157,"text":4551},{"id":4590,"depth":157,"text":4591},{"id":4621,"depth":151,"text":4622,"children":5150},[5151,5152,5153],{"id":4634,"depth":157,"text":4635},{"id":4698,"depth":157,"text":4699},{"id":4736,"depth":157,"text":4737},{"id":4821,"depth":151,"text":4822},{"id":4888,"depth":151,"text":4889},{"id":5002,"depth":151,"text":5003,"children":5157},[5158,5160,5161,5162,5163],{"id":5006,"depth":157,"text":5159},"误区一：配置 acks=all 就绝对不会丢",{"id":5021,"depth":157,"text":5022},{"id":5031,"depth":157,"text":5032},{"id":5038,"depth":157,"text":5039},{"id":5045,"depth":157,"text":5046},{"id":5052,"depth":151,"text":5053},{"id":1570,"depth":151,"text":1570},"wiki:java:kafka-message-loss-prevention","从生产者、Broker 和消费者三段链路分析 Kafka 消息丢失的原因，以及 acks、ISR、副本、手动提交 Offset 和业务幂等的完整保障方案。",{},72,"\u002Fjava\u002Fkafka-message-loss-prevention",{"title":3991,"description":5167},"java\u002Fkafka-message-loss-prevention","2026-07-24","3f0HtflG-t8Ejs1I4PaPFqW8UqAizA0ZOhF0kJToSBs",{"id":5176,"title":5177,"body":5178,"commentId":6184,"description":6185,"difficulty":3063,"draft":1646,"extension":1647,"meta":6186,"navigation":780,"order":6187,"path":6188,"section":1651,"seo":6189,"stem":6190,"updated":5173,"__hash__":6191},"java\u002Fjava\u002Fkafka-high-concurrency-performance-availability.md","Kafka 是如何实现高并发、高性能、高可用的",{"type":7,"value":5179,"toc":6140},[5180,5183,5185,5200,5202,5209,5211,5220,5222,5225,5239,5243,5247,5250,5256,5259,5266,5270,5273,5276,5287,5290,5294,5297,5299,5305,5308,5312,5315,5318,5322,5326,5329,5335,5338,5342,5345,5351,5371,5374,5378,5381,5387,5390,5404,5410,5414,5417,5423,5426,5443,5450,5456,5459,5462,5469,5472,5492,5501,5505,5508,5511,5525,5541,5545,5548,5554,5560,5566,5569,5578,5584,5587,5594,5600,5604,5607,5610,5616,5618,5624,5627,5633,5636,5639,5642,5657,5660,5664,5668,5671,5677,5680,5683,5687,5690,5696,5699,5708,5711,5716,5719,5722,5726,5731,5742,5745,5759,5762,5765,5771,5774,5778,5785,5791,5794,5797,5845,5848,5854,5857,5861,5864,5867,5873,5876,5880,5942,5945,5951,5955,5958,5978,5981,5984,5990,5993,5997,6001,6004,6008,6014,6018,6021,6025,6028,6035,6042,6046,6049,6060,6064,6077,6080,6094,6096,6138],[10,5181,5177],{"id":5182},"kafka-是如何实现高并发高性能高可用的",[14,5184,16],{"id":16},[63,5186,5187],{},[18,5188,5189,5190,5193,5194,5196,5197,5199],{},"Kafka 的高并发主要依靠分区实现横向扩展：一个 Topic 被拆成多个 Partition，分区 Leader 分散在不同 Broker 上，生产者可以并行写入，消费者组也可以按分区并行消费。高性能主要来自追加写和顺序 I\u002FO、操作系统 Page Cache、生产与消费两端的批处理、批量压缩，以及通过 ",[21,5191,5192],{},"sendfile"," 实现的零拷贝传输。高可用则依靠多副本、Leader\u002FFollower、ISR、故障选主和 KRaft Controller Quorum；生产端再配合 ",[21,5195,4006],{},"、",[21,5198,4168],{}," 和幂等生产，消费端通过 Consumer Group、Offset 与重新分配实现故障恢复。Kafka 的核心设计是在分区粒度上并行，在单分区内部维持有序日志，再用副本机制保障故障后的连续服务。",[18,5201,61],{},[63,5203,5204],{},[18,5205,5206],{},[68,5207,5208],{},"分区提供并行度，顺序日志、批处理和零拷贝提供吞吐量，副本、ISR 与故障选主提供可用性。",[14,5210,73],{"id":73},[18,5212,5213],{},[77,5214,5217],{"href":5215,"target":80,"rel":5216},"\u002Fimages\u002Fwiki\u002Fjava\u002Fkafka-high-concurrency-performance-availability.svg",[82,83],[85,5218],{"src":5215,"alt":5219},"Kafka 高并发、高性能和高可用实现机制总览",[14,5221,90],{"id":90},[18,5223,5224],{},"Kafka 的三个能力不是彼此孤立的：",[99,5226,5227,5230,5233,5236],{},[102,5228,5229],{},"分区既是并发执行和横向扩展的单位，也是副本复制与故障恢复的单位。",[102,5231,5232],{},"批处理既减少网络请求，也把大量小写入转化为更高效的顺序写。",[102,5234,5235],{},"Page Cache 既提升读写性能，也能配合副本机制避免为了可靠性而对每条消息执行同步刷盘。",[102,5237,5238],{},"副本增强了可靠性，但同时会增加网络、磁盘与确认延迟，因此需要在吞吐、延迟和可靠性之间取舍。",[14,5240,5242],{"id":5241},"一高并发通过分区横向扩展","一、高并发：通过分区横向扩展",[192,5244,5246],{"id":5245},"_1-partition-是-kafka-的并行单元","1. Partition 是 Kafka 的并行单元",[18,5248,5249],{},"一个 Topic 可以拆成多个 Partition：",[118,5251,5254],{"className":5252,"code":5253,"language":123,"meta":124},[121],"Topic: order-events\n├── Partition 0 → Leader 在 Broker A\n├── Partition 1 → Leader 在 Broker B\n└── Partition 2 → Leader 在 Broker C\n",[21,5255,5253],{"__ignoreMap":124},[18,5257,5258],{},"不同分区可以由不同 Broker 同时处理，因此整体吞吐不再受限于单台机器。增加 Broker 并合理增加分区后，存储容量、网络带宽和读写能力都可以横向扩展。",[18,5260,5261,5262,5265],{},"Kafka 只保证",[68,5263,5264],{},"单分区内有序","，不保证一个 Topic 的所有分区之间全局有序。这是它获得并行能力的重要前提。",[192,5267,5269],{"id":5268},"_2-生产者直接找到分区-leader","2. 生产者直接找到分区 Leader",[18,5271,5272],{},"生产者会缓存集群元数据，根据消息 Key、显式分区或默认分区策略选择 Partition，然后直接向该分区的 Leader 发送数据，中间不需要额外的统一路由节点。",[18,5274,5275],{},"常见分区方式：",[99,5277,5278,5281,5284],{},[102,5279,5280],{},"指定 Key：相同 Key 通常进入同一分区，适合保证同一订单、用户或账户内的消息顺序。",[102,5282,5283],{},"不指定 Key：默认分区策略会在适当时机选择分区，并尽量形成较大的批次。",[102,5285,5286],{},"自定义分区器：按租户、地区或业务规则路由。",[18,5288,5289],{},"如果 Key 分布不均，大量消息集中到少数分区，就会出现热点分区。此时即使 Broker 很多，整体吞吐仍会被热点 Leader 限制。",[192,5291,5293],{"id":5292},"_3-consumer-group-按分区并行消费","3. Consumer Group 按分区并行消费",[18,5295,5296],{},"同一个 Consumer Group 中，一个 Partition 在同一时刻只分配给一个 Consumer；一个 Consumer 可以负责多个 Partition。",[18,5298,1263],{},[118,5300,5303],{"className":5301,"code":5302,"language":123,"meta":124},[121],"4 个 Partition + 2 个 Consumer\n→ 每个 Consumer 负责约 2 个 Partition\n\n4 个 Partition + 4 个 Consumer\n→ 每个 Consumer 负责约 1 个 Partition\n\n4 个 Partition + 6 个 Consumer\n→ 最多只有 4 个 Consumer 能获得 Partition\n",[21,5304,5302],{"__ignoreMap":124},[18,5306,5307],{},"因此，一个消费组的有效并行度上限通常受 Partition 数量约束。简单增加 Consumer，而不增加 Partition，不一定能提高吞吐量。",[192,5309,5311],{"id":5310},"_4-broker-内部通过线程分工处理请求","4. Broker 内部通过线程分工处理请求",[18,5313,5314],{},"Broker 不会用一个线程串行完成所有网络和磁盘工作。网络线程负责接收请求、解析协议和返回响应，请求处理线程负责执行 Produce、Fetch 等具体逻辑，后台线程负责日志清理、副本同步等任务。",[18,5316,5317],{},"这种职责分离让网络连接管理、业务请求处理和后台维护能够并行执行，避免某类工作完全阻塞其他工作。",[14,5319,5321],{"id":5320},"二高性能把随机小操作变成顺序批量操作","二、高性能：把随机小操作变成顺序批量操作",[192,5323,5325],{"id":5324},"_1-顺序追加写","1. 顺序追加写",[18,5327,5328],{},"Kafka 的 Partition 本质上是一条只追加的日志。新消息写到日志末尾，不需要像通用数据库那样频繁进行随机位置更新。",[118,5330,5333],{"className":5331,"code":5332,"language":123,"meta":124},[121],"旧数据 ────────────────→ 日志末尾追加新批次\noffset 0 1 2 3 4 5 6 ...\n",[21,5334,5332],{"__ignoreMap":124},[18,5336,5337],{},"顺序 I\u002FO 能充分利用磁盘和操作系统的预读、合并写能力。日志达到一定大小或时间后会切分为新的 Segment，旧 Segment 可以按保留策略清理或压缩，不影响当前日志继续追加。",[192,5339,5341],{"id":5340},"_2-分段日志与稀疏索引","2. 分段日志与稀疏索引",[18,5343,5344],{},"每个 Partition 由多个日志 Segment 组成，常见文件包括：",[118,5346,5349],{"className":5347,"code":5348,"language":123,"meta":124},[121],"00000000000000000000.log\n00000000000000000000.index\n00000000000000000000.timeindex\n",[21,5350,5348],{"__ignoreMap":124},[99,5352,5353,5359,5365],{},[102,5354,5355,5358],{},[21,5356,5357],{},".log"," 保存消息批次。",[102,5360,5361,5364],{},[21,5362,5363],{},".index"," 保存相对 Offset 到日志物理位置的稀疏映射。",[102,5366,5367,5370],{},[21,5368,5369],{},".timeindex"," 保存时间戳到相对 Offset 的稀疏映射。",[18,5372,5373],{},"查找消息时，Kafka 先定位 Segment，再通过稀疏索引找到接近目标的位置，最后在日志中继续顺序查找。索引不需要记录每一条消息，因此能控制索引体积和内存占用。",[192,5375,5377],{"id":5376},"_3-充分利用-page-cache","3. 充分利用 Page Cache",[18,5379,5380],{},"Kafka 不把全部消息封装成大量 Java 堆对象长期缓存，而是依赖操作系统 Page Cache：",[118,5382,5385],{"className":5383,"code":5384,"language":123,"meta":124},[121],"Producer\n→ Broker 写日志文件\n→ 数据先进入 Page Cache\n→ 操作系统异步回写磁盘\n",[21,5386,5384],{"__ignoreMap":124},[18,5388,5389],{},"这样做有几个好处：",[99,5391,5392,5395,5398,5401],{},[102,5393,5394],{},"利用操作系统成熟的预读和回写机制。",[102,5396,5397],{},"减少 JVM 堆内存占用和 GC 压力。",[102,5399,5400],{},"热数据可以直接从 Page Cache 读取。",[102,5402,5403],{},"Broker 重启后，操作系统缓存仍可能保留部分热数据，不必完全重新构建 JVM 内缓存。",[18,5405,5406,5407,5409],{},"Kafka 的可靠性主要依赖多副本，而不是对每条消息都执行一次同步 ",[21,5408,4445],{},"。如果强制每条消息同步刷盘，吞吐和延迟都会明显恶化。",[192,5411,5413],{"id":5412},"_4-端到端批处理","4. 端到端批处理",[18,5415,5416],{},"批处理贯穿生产、Broker 存储和消费三段链路：",[118,5418,5421],{"className":5419,"code":5420,"language":123,"meta":124},[121],"多条消息\n→ Producer 聚合成 Record Batch\n→ 一次网络请求发送\n→ Broker 将 Record Batch 连续追加到分区日志\n→ Consumer 一次 Fetch 多条消息\n",[21,5422,5420],{"__ignoreMap":124},[18,5424,5425],{},"它可以摊薄：",[99,5427,5428,5431,5434,5437,5440],{},[102,5429,5430],{},"网络往返成本。",[102,5432,5433],{},"系统调用成本。",[102,5435,5436],{},"协议头和请求头开销。",[102,5438,5439],{},"磁盘写入次数。",[102,5441,5442],{},"消息压缩成本。",[18,5444,5445,5446,5449],{},"这里的“Broker 追加批次”不是把多条消息合并成一条业务消息，也不承诺底层一定只发生一次系统调用。它表示 Kafka 的生产者和存储格式都以 ",[68,5447,5448],{},"Record Batch"," 为基本单位：",[118,5451,5454],{"className":5452,"code":5453,"language":123,"meta":124},[121],"Record Batch\n├── 批次头：baseOffset、长度、时间戳、压缩类型、CRC 等\n├── Record 1\n├── Record 2\n└── Record 3\n",[21,5455,5453],{"__ignoreMap":124},[18,5457,5458],{},"Producer 会先按 Partition 在内存中积累消息，形成 Record Batch。Broker 收到后，对批次进行校验，为其中的消息确定 Offset，然后把整段连续数据追加到对应 Partition 的当前日志 Segment 末尾。相比每条消息都单独发请求、单独写日志，批次追加可以用更少的请求和更大的连续 I\u002FO 摊薄固定开销。",[18,5460,5461],{},"一个 ProduceRequest 还可以携带多个 Partition 的 Record Batch，但 Broker 最终仍然分别追加到各个 Partition 的日志中。因此：",[63,5463,5464],{},[18,5465,5466],{},[68,5467,5468],{},"批次是网络传输和日志写入的基本单位，Partition 才是日志组织、顺序保证和副本复制的基本单位。",[18,5470,5471],{},"生产者常见相关参数：",[118,5473,5475],{"className":4152,"code":5474,"language":4154,"meta":124,"style":124},"batch.size=16384\nlinger.ms=5\ncompression.type=lz4\n",[21,5476,5477,5482,5487],{"__ignoreMap":124},[142,5478,5479],{"class":144,"line":145},[142,5480,5481],{},"batch.size=16384\n",[142,5483,5484],{"class":144,"line":151},[142,5485,5486],{},"linger.ms=5\n",[142,5488,5489],{"class":144,"line":157},[142,5490,5491],{},"compression.type=lz4\n",[18,5493,5494,1441,5497,5500],{},[21,5495,5496],{},"batch.size",[21,5498,5499],{},"linger.ms"," 体现的是吞吐与延迟之间的取舍：适度等待可以积累更大的批次，但等待过长会增加低流量场景的发送延迟。参数值应根据消息大小、流量和延迟目标压测确定，不能机械照搬示例。",[192,5502,5504],{"id":5503},"_5-批量压缩","5. 批量压缩",[18,5506,5507],{},"Kafka 对一个 Record Batch 进行整体压缩，而不是分别压缩每条消息。相似消息中的字段名和公共内容可以获得更好的压缩率。",[18,5509,5510],{},"压缩后的批次会以压缩形式写入日志并传输给消费者，从而降低：",[99,5512,5513,5516,5519,5522],{},[102,5514,5515],{},"Broker 磁盘占用。",[102,5517,5518],{},"生产者到 Broker 的网络流量。",[102,5520,5521],{},"副本复制流量。",[102,5523,5524],{},"Broker 到消费者的网络流量。",[18,5526,5527,5528,5196,5531,5196,5534,1217,5537,5540],{},"压缩会消耗 CPU，因此需要根据资源瓶颈选择 ",[21,5529,5530],{},"lz4",[21,5532,5533],{},"zstd",[21,5535,5536],{},"snappy",[21,5538,5539],{},"gzip"," 等算法。网络或磁盘是瓶颈时，压缩往往能换取更高吞吐。",[192,5542,5544],{"id":5543},"_6-零拷贝","6. 零拷贝",[18,5546,5547],{},"消费者拉取日志数据时，普通路径可能需要：",[118,5549,5552],{"className":5550,"code":5551,"language":123,"meta":124},[121],"磁盘 → Page Cache → 用户空间 → Socket Buffer → 网卡\n",[21,5553,5551],{"__ignoreMap":124},[18,5555,5556,5557,5559],{},"Kafka 在适用条件下利用 Linux ",[21,5558,5192],{},"，让数据从 Page Cache 直接进入网络发送路径，减少用户态和内核态之间的复制与上下文切换：",[118,5561,5564],{"className":5562,"code":5563,"language":123,"meta":124},[121],"Page Cache → Socket \u002F 网卡\n",[21,5565,5563],{"__ignoreMap":124},[18,5567,5568],{},"这就是常说的零拷贝。它主要优化 Broker 向消费者传输已有日志数据的过程。",[18,5570,5571],{},[77,5572,5575],{"href":5573,"target":80,"rel":5574},"\u002Fimages\u002Fwiki\u002Fjava\u002Fkafka-sendfile-vs-traditional-io.svg",[82,83],[85,5576],{"src":5573,"alt":5577},"Kafka sendfile 零拷贝与传统文件传输路径对比",[18,5579,5580,5581,5583],{},"传统路径需要先把数据从内核 Page Cache 复制到 Broker 的用户空间，再从用户空间写回内核 Socket Buffer；",[21,5582,5192],{}," 让内核直接组织 Page Cache 到网络 Socket 的传输，Broker 不再把消息内容完整搬入 JVM 用户空间。",[18,5585,5586],{},"所以“零拷贝”更准确的含义是：",[63,5588,5589],{},[18,5590,5591],{},[68,5592,5593],{},"减少或绕过 Page Cache 与用户空间之间不必要的数据复制，而不是数据在磁盘、内存和网卡之间一次都不移动。",[18,5595,5596,5597,5599],{},"需要注意，Kafka 官方文档明确说明，启用 SSL 时数据要经过用户态 TLS 处理，当前不会使用这条 ",[21,5598,5192],{}," 路径。因此不能笼统地说所有 Kafka 网络传输都一定是零拷贝。",[192,5601,5603],{"id":5602},"_7-consumer-pull-与长轮询","7. Consumer Pull 与长轮询",[18,5605,5606],{},"Kafka 由消费者主动 Pull 数据。消费者可以根据自己的处理能力决定拉取速度，处理不过来时，未消费消息会暂时保留在 Kafka 中，并表现为 Consumer Lag 增长，而不是由 Broker 持续 Push 直至压垮消费者。",[18,5608,5609],{},"Consumer Lag 表示消费者的消费进度落后于 Partition 最新位置的程度。监控消费组时，通常可以近似理解为：",[118,5611,5614],{"className":5612,"code":5613,"language":123,"meta":124},[121],"Consumer Lag\n= Partition Log End Offset\n- Consumer Group 已提交 Offset\n",[21,5615,5613],{"__ignoreMap":124},[18,5617,1263],{},[118,5619,5622],{"className":5620,"code":5621,"language":123,"meta":124},[121],"Partition 下一条待写位置：10000\n消费组下一条待消费位置：9400\n\nLag = 10000 - 9400 = 600\n",[21,5623,5621],{"__ignoreMap":124},[18,5625,5626],{},"这表示当前大约还有 600 个 Offset 的数据尚未被该消费组处理。Lag 不是消息丢失，而是消费积压：",[118,5628,5631],{"className":5629,"code":5630,"language":123,"meta":124},[121],"生产速度 > 消费速度\n→ Lag 持续增大\n\n消费速度 > 生产速度\n→ Consumer 逐步追赶\n→ Lag 逐步减小\n",[21,5632,5630],{"__ignoreMap":124},[18,5634,5635],{},"Lag 不能只看某一时刻的绝对值，还要观察增长趋势、积压持续时间和业务允许的最大延迟。同样数量的 Lag，在每秒几条和每秒几十万条的 Topic 中代表的时间延迟完全不同。",[18,5637,5638],{},"如果 Lag 长期增长，可能是消费者处理变慢、下游故障、分区热点、Consumer 数量不足或频繁重平衡。若积压时间超过 Topic 的数据保留期限，旧消息可能已经被清理，消费者就不能再依靠 Kafka 把这部分数据完整追回。",[18,5640,5641],{},"Fetch 请求支持批量拉取和长轮询：",[118,5643,5645],{"className":4152,"code":5644,"language":4154,"meta":124,"style":124},"fetch.min.bytes=1\nfetch.max.wait.ms=500\n",[21,5646,5647,5652],{"__ignoreMap":124},[142,5648,5649],{"class":144,"line":145},[142,5650,5651],{},"fetch.min.bytes=1\n",[142,5653,5654],{"class":144,"line":151},[142,5655,5656],{},"fetch.max.wait.ms=500\n",[18,5658,5659],{},"Broker 暂时没有足够数据时，可以等待一段时间再响应，避免消费者无数据时频繁空轮询；流量较高时，又可以一次返回较大的批次。",[14,5661,5663],{"id":5662},"三高可用副本isr-与故障转移","三、高可用：副本、ISR 与故障转移",[192,5665,5667],{"id":5666},"_1-每个-partition-可以有多个副本","1. 每个 Partition 可以有多个副本",[18,5669,5670],{},"假设副本因子为 3：",[118,5672,5675],{"className":5673,"code":5674,"language":123,"meta":124},[121],"Partition 0\n├── Leader：Broker A\n├── Follower：Broker B\n└── Follower：Broker C\n",[21,5676,5674],{"__ignoreMap":124},[18,5678,5679],{},"生产和普通消费请求由 Leader 处理，Follower 分别从 Leader 拉取并复制日志。多个 Follower 的同步是彼此独立的，不存在先同步 B、再由 B 同步 C 的固定顺序。",[18,5681,5682],{},"副本应尽量分散在不同 Broker；具备机架感知配置时，还可以跨机架放置，降低单机或单机架故障带来的影响。",[192,5684,5686],{"id":5685},"_2-isr-维护可安全选主的副本集合","2. ISR 维护可安全选主的副本集合",[18,5688,5689],{},"ISR 是 In-Sync Replicas，即当前与 Leader 保持同步的副本集合。Follower 故障或长时间落后时会被移出 ISR，重新追上后可以再次加入。",[118,5691,5694],{"className":5692,"code":5693,"language":123,"meta":124},[121],"正常：ISR = [A, B, C]\nC 落后：ISR = [A, B]\n",[21,5695,5693],{"__ignoreMap":124},[18,5697,5698],{},"Leader 故障后，Controller 会从符合条件的副本中选择新的 Leader。以 ISR 为基础进行选主，可以避免把明显缺少最新日志的副本直接作为新的数据源。",[192,5700,5702,5703,5705,5706],{"id":5701},"_3-acks-与-mininsyncreplicas","3. ",[21,5704,4090],{}," 与 ",[21,5707,4168],{},[18,5709,5710],{},"常见的高可靠组合是：",[118,5712,5714],{"className":5713,"code":4382,"language":123,"meta":124},[121],[21,5715,4382],{"__ignoreMap":124},[18,5717,5718],{},"含义是生产者等待当前 ISR 的确认，并且 ISR 至少要有两个副本，否则 Broker 拒绝写入。",[18,5720,5721],{},"这个配置体现了 CAP 取舍：副本不足时拒绝写入，会降低部分可用性，但可以避免在只剩单副本时继续写入并承担更高的数据丢失风险。",[192,5723,5725],{"id":5724},"_4-kraft-controller-quorum-保证控制面可用","4. KRaft Controller Quorum 保证控制面可用",[5727,5728,5730],"h4",{"id":5729},"kraft-controller-quorum-是什么","KRaft Controller Quorum 是什么",[18,5732,5733,5734,5737,5738,5741],{},"KRaft 是 Kafka 自己实现的元数据管理机制，用来替代早期依赖的 ZooKeeper。集群中会有若干个承担 ",[21,5735,5736],{},"controller"," 角色的节点，这些 Controller 组成一个基于 Raft 共识协议的 ",[68,5739,5740],{},"Controller Quorum","，即控制器仲裁组。",[18,5743,5744],{},"它们维护的是集群元数据，而不是普通 Topic 的业务消息：",[99,5746,5747,5750,5753,5756],{},[102,5748,5749],{},"Broker 注册、存活状态和节点信息。",[102,5751,5752],{},"Topic 与 Partition 的定义。",[102,5754,5755],{},"每个 Partition 的副本分配、Leader 和 ISR。",[102,5757,5758],{},"配置、配额以及其他集群级元数据。",[18,5760,5761],{},"这些变化会写入 KRaft 的集群元数据日志，并复制给 Quorum 中的其他 Controller。一次元数据变更获得多数 Controller 确认后才算提交，因此单个 Controller 故障不会导致已提交元数据丢失。",[18,5763,5764],{},"常见部署是 3 个或 5 个 Controller：",[118,5766,5769],{"className":5767,"code":5768,"language":123,"meta":124},[121],"3 个 Controller → 多数派为 2，可容忍 1 个故障\n5 个 Controller → 多数派为 3，可容忍 2 个故障\n",[21,5770,5768],{"__ignoreMap":124},[18,5772,5773],{},"如果存活 Controller 失去多数派，集群不能安全提交新的元数据变更。此时已有数据读写是否还能短暂继续，取决于具体操作和现有元数据状态，但创建 Topic、Partition Leader 调度等控制面操作会受到影响。",[5727,5775,5777],{"id":5776},"active-controller-是什么","Active Controller 是什么",[18,5779,5780,5781,5784],{},"Controller Quorum 在同一时刻会选出一个 Leader，Kafka 的文档和运行语境中通常称它为 ",[68,5782,5783],{},"Active Controller","。其他 Controller 作为 Follower 复制元数据日志，随时准备接管。",[118,5786,5789],{"className":5787,"code":5788,"language":123,"meta":124},[121],"Controller A：Active Controller\n├── 接收和处理元数据变更\n├── 管理 Broker 注册与故障\n├── 触发 Partition Leader 选举\n└── 把变更写入元数据日志\n\nController B、C：Follower Controllers\n├── 复制元数据日志\n└── Active Controller 故障后参与重新选举\n",[21,5790,5788],{"__ignoreMap":124},[18,5792,5793],{},"Active Controller 不是所有业务消息的入口，也不负责替 Broker 保存普通 Topic 数据。生产者和消费者仍然直接与 Partition Leader 所在的 Broker 通信。",[18,5795,5796],{},"需要明确区分两个层面：",[341,5798,5799,5815],{},[344,5800,5801],{},[347,5802,5803,5806,5809,5812],{},[350,5804,5805],{},"层面",[350,5807,5808],{},"主要角色",[350,5810,5811],{},"保存什么",[350,5813,5814],{},"负责什么",[360,5816,5817,5831],{},[347,5818,5819,5822,5825,5828],{},[365,5820,5821],{},"数据面",[365,5823,5824],{},"Broker、Partition Leader\u002FFollower",[365,5826,5827],{},"普通 Topic 的业务消息",[365,5829,5830],{},"生产、消费、副本复制",[347,5832,5833,5836,5839,5842],{},[365,5834,5835],{},"控制面",[365,5837,5838],{},"KRaft Controller Quorum",[365,5840,5841],{},"集群元数据日志",[365,5843,5844],{},"节点管理、元数据变更、Leader 调度",[18,5846,5847],{},"例如 Broker A 突然故障：",[118,5849,5852],{"className":5850,"code":5851,"language":123,"meta":124},[121],"Active Controller 感知 Broker A 失联\n→ 找出受影响的 Partition\n→ 从符合条件的副本中选择新 Leader\n→ 将选举结果写入元数据日志\n→ 多数 Controller 确认提交\n→ 向相关 Broker 发布新元数据\n→ 客户端刷新元数据并访问新 Leader\n",[21,5853,5851],{"__ignoreMap":124},[18,5855,5856],{},"如果 Active Controller 自身故障，剩余 Controller 会通过 Raft 重新选出新的 Active Controller。新节点已经复制了已提交的元数据日志，因此可以继续管理集群。",[192,5858,5860],{"id":5859},"_5-consumer-group-自动接管故障消费者的分区","5. Consumer Group 自动接管故障消费者的分区",[18,5862,5863],{},"消费者通过心跳维持组成员身份。如果某个 Consumer 崩溃或超时，Consumer Group 会重新分配它原来负责的 Partition，让其他 Consumer 接管。",[18,5865,5866],{},"消费进度保存在已提交的 Offset 中，因此新 Consumer 可以从相应位置继续处理：",[118,5868,5871],{"className":5869,"code":5870,"language":123,"meta":124},[121],"Consumer A 故障\n→ 触发重新分配\n→ Partition 交给 Consumer B\n→ B 从已提交 Offset 继续消费\n",[21,5872,5870],{"__ignoreMap":124},[18,5874,5875],{},"重平衡期间可能产生短暂停顿，所以高可用不等于无感切换。合理设置会话、心跳、处理时长，并避免频繁扩缩容，有助于减少重平衡影响。",[14,5877,5879],{"id":5878},"四三种能力如何协同","四、三种能力如何协同",[341,5881,5882,5898],{},[344,5883,5884],{},[347,5885,5886,5889,5892,5895],{},[350,5887,5888],{},"目标",[350,5890,5891],{},"核心机制",[350,5893,5894],{},"解决的问题",[350,5896,5897],{},"主要代价",[360,5899,5900,5914,5928],{},[347,5901,5902,5905,5908,5911],{},[365,5903,5904],{},"高并发",[365,5906,5907],{},"多 Partition、多 Broker、Consumer Group",[365,5909,5910],{},"并行生产、存储和消费",[365,5912,5913],{},"分区与元数据管理成本",[347,5915,5916,5919,5922,5925],{},[365,5917,5918],{},"高性能",[365,5920,5921],{},"顺序写、Page Cache、批处理、压缩、零拷贝",[365,5923,5924],{},"降低 I\u002FO、复制和网络开销",[365,5926,5927],{},"批处理延迟与 CPU 消耗",[347,5929,5930,5933,5936,5939],{},[365,5931,5932],{},"高可用",[365,5934,5935],{},"多副本、ISR、Controller Quorum、故障转移",[365,5937,5938],{},"节点故障后继续提供服务",[365,5940,5941],{},"副本存储、网络与确认延迟",[18,5943,5944],{},"可以把整个链路理解为：",[118,5946,5949],{"className":5947,"code":5948,"language":123,"meta":124},[121],"消息按 Partition 分流\n→ Producer 批量发送\n→ Leader 顺序追加到日志\n→ Follower 并行复制\n→ 满足确认条件后返回\n→ Consumer Group 按 Partition 批量拉取\n",[21,5950,5948],{"__ignoreMap":124},[14,5952,5954],{"id":5953},"五为什么不能只靠增加分区提升性能","五、为什么不能只靠增加分区提升性能",[18,5956,5957],{},"分区是扩展能力的基础，但分区不是越多越好。分区数量增加会同时带来：",[99,5959,5960,5963,5966,5969,5972,5975],{},[102,5961,5962],{},"更多日志目录、Segment 和文件句柄。",[102,5964,5965],{},"更多副本复制任务。",[102,5967,5968],{},"更大的集群元数据。",[102,5970,5971],{},"更高的 Leader 选举和故障恢复成本。",[102,5973,5974],{},"Consumer Group 重平衡开销。",[102,5976,5977],{},"单 Key 顺序范围更难调整。",[18,5979,5980],{},"合理做法是根据目标吞吐量、单分区压测能力、消费者并行度、副本数和未来增长空间估算，而不是一次创建大量分区。",[18,5982,5983],{},"一个简化估算思路：",[118,5985,5988],{"className":5986,"code":5987,"language":123,"meta":124},[121],"分区数 ≥ max(\n 目标生产吞吐 \u002F 单分区生产吞吐,\n 目标消费吞吐 \u002F 单消费者单分区吞吐,\n 期望消费并行度\n)\n",[21,5989,5987],{"__ignoreMap":124},[18,5991,5992],{},"最终仍需要在接近生产环境的机器、网络、副本配置和消息大小下进行压测。",[14,5994,5996],{"id":5995},"六常见误区","六、常见误区",[192,5998,6000],{"id":5999},"误区一kafka-使用磁盘所以一定比内存消息队列慢","误区一：Kafka 使用磁盘，所以一定比内存消息队列慢",[18,6002,6003],{},"Kafka 采用顺序追加、Page Cache 和批处理，大量读写实际在操作系统缓存中完成。性能取决于访问模式，而不是简单由“使用磁盘”决定。",[192,6005,6007],{"id":6006},"误区二零拷贝让数据完全不发生复制","误区二：零拷贝让数据完全不发生复制",[18,6009,6010,6011,6013],{},"零拷贝是减少不必要的用户态复制，并非物理意义上的一次复制都没有；而且启用 SSL 时不会走 Kafka 文档描述的 ",[21,6012,5192],{}," 路径。",[192,6015,6017],{"id":6016},"误区三消费者越多消费速度一定越快","误区三：消费者越多，消费速度一定越快",[18,6019,6020],{},"同一消费组内，一个 Partition 同时只能交给一个 Consumer。Consumer 数超过 Partition 数后，多出的 Consumer 不会获得分区。",[192,6022,6024],{"id":6023},"误区四副本越多高可用越高且没有代价","误区四：副本越多，高可用越高且没有代价",[18,6026,6027],{},"更多副本会增加存储、网络复制和写确认成本。副本数应根据故障域和可靠性目标确定，常见三副本不代表所有场景都必须相同。",[192,6029,6031,6032,6034],{"id":6030},"误区五acksall-就代表所有配置副本都已写入","误区五：",[21,6033,4006],{}," 就代表所有配置副本都已写入",[18,6036,6037,6039,6040,52],{},[21,6038,4006],{}," 等待的是当前 ISR，而不是所有配置副本。要避免 ISR 只剩一个副本时仍然成功写入，需要配合 ",[21,6041,4168],{},[14,6043,6045],{"id":6044},"七排查性能和可用性问题时看什么","七、排查性能和可用性问题时看什么",[192,6047,6048],{"id":6048},"生产端",[99,6050,6051,6054,6057],{},[102,6052,6053],{},"发送吞吐、请求延迟、错误率和重试次数。",[102,6055,6056],{},"批次大小、压缩率和缓冲区等待。",[102,6058,6059],{},"消息 Key 是否造成分区流量倾斜。",[192,6061,6063],{"id":6062},"broker","Broker",[99,6065,6066,6069,6072,6074],{},[102,6067,6068],{},"各 Broker、Partition 和 Leader 的流量是否均衡。",[102,6070,6071],{},"磁盘利用率、磁盘延迟、网络带宽和请求队列。",[102,6073,5064],{},[102,6075,6076],{},"Page Cache 命中效果和系统是否发生 Swap。",[192,6078,6079],{"id":6079},"消费端",[99,6081,6082,6085,6088,6091],{},[102,6083,6084],{},"Consumer Lag 及其增长速度。",[102,6086,6087],{},"单条消息处理耗时和批次处理耗时。",[102,6089,6090],{},"Consumer 数量与 Partition 数量是否匹配。",[102,6092,6093],{},"重平衡次数、心跳超时和 Offset 提交失败。",[14,6095,1570],{"id":1570},[99,6097,6098,6104,6111,6118,6123,6128,6133],{},[102,6099,6100],{},[77,6101,6103],{"href":5109,"rel":6102},[1579],"Apache Kafka Design",[102,6105,6106],{},[77,6107,6110],{"href":6108,"rel":6109},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Foperations\u002Fkraft\u002F",[1579],"Apache Kafka KRaft",[102,6112,6113],{},[77,6114,6117],{"href":6115,"rel":6116},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Fimplementation\u002Fmessage-format\u002F",[1579],"Apache Kafka Message Format",[102,6119,6120],{},[77,6121,5090],{"href":5088,"rel":6122},[1579],[102,6124,6125],{},[77,6126,5104],{"href":5102,"rel":6127},[1579],[102,6129,6130],{},[77,6131,5097],{"href":5095,"rel":6132},[1579],[102,6134,6135],{},[77,6136,5118],{"href":5116,"rel":6137},[1579],[1596,6139,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":6141},[6142,6143,6144,6145,6151,6160,6168,6169,6170,6178,6183],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":5241,"depth":151,"text":5242,"children":6146},[6147,6148,6149,6150],{"id":5245,"depth":157,"text":5246},{"id":5268,"depth":157,"text":5269},{"id":5292,"depth":157,"text":5293},{"id":5310,"depth":157,"text":5311},{"id":5320,"depth":151,"text":5321,"children":6152},[6153,6154,6155,6156,6157,6158,6159],{"id":5324,"depth":157,"text":5325},{"id":5340,"depth":157,"text":5341},{"id":5376,"depth":157,"text":5377},{"id":5412,"depth":157,"text":5413},{"id":5503,"depth":157,"text":5504},{"id":5543,"depth":157,"text":5544},{"id":5602,"depth":157,"text":5603},{"id":5662,"depth":151,"text":5663,"children":6161},[6162,6163,6164,6166,6167],{"id":5666,"depth":157,"text":5667},{"id":5685,"depth":157,"text":5686},{"id":5701,"depth":157,"text":6165},"3. acks 与 min.insync.replicas",{"id":5724,"depth":157,"text":5725},{"id":5859,"depth":157,"text":5860},{"id":5878,"depth":151,"text":5879},{"id":5953,"depth":151,"text":5954},{"id":5995,"depth":151,"text":5996,"children":6171},[6172,6173,6174,6175,6176],{"id":5999,"depth":157,"text":6000},{"id":6006,"depth":157,"text":6007},{"id":6016,"depth":157,"text":6017},{"id":6023,"depth":157,"text":6024},{"id":6030,"depth":157,"text":6177},"误区五：acks=all 就代表所有配置副本都已写入",{"id":6044,"depth":151,"text":6045,"children":6179},[6180,6181,6182],{"id":6048,"depth":157,"text":6048},{"id":6062,"depth":157,"text":6063},{"id":6079,"depth":157,"text":6079},{"id":1570,"depth":151,"text":1570},"wiki:java:kafka-high-concurrency-performance-availability","从分区并行、顺序写、Page Cache、批处理、零拷贝、副本与 ISR 等机制，系统理解 Kafka 高吞吐与高可用架构。",{},73,"\u002Fjava\u002Fkafka-high-concurrency-performance-availability",{"title":5177,"description":6185},"java\u002Fkafka-high-concurrency-performance-availability","7w2j1CaPDOxbjhwQCuQIpbyFqqVZ88ZfOwjhHG_Yqbc",{"id":6193,"title":6194,"body":6195,"commentId":7527,"description":7528,"difficulty":3063,"draft":1646,"extension":1647,"meta":7529,"navigation":780,"order":7530,"path":7531,"section":1651,"seo":7532,"stem":7533,"updated":5173,"__hash__":7534},"java\u002Fjava\u002Fkafka-message-backlog-handling.md","Kafka 消息积压如何处理",{"type":7,"value":6196,"toc":7481},[6197,6200,6202,6207,6209,6216,6218,6227,6229,6232,6238,6241,6245,6248,6251,6256,6258,6264,6267,6270,6340,6343,6346,6352,6355,6361,6364,6367,6371,6375,6381,6384,6388,6391,6414,6421,6425,6428,6448,6451,6457,6460,6464,6467,6470,6476,6479,6483,6486,6503,6506,6510,6514,6517,6523,6526,6530,6533,6547,6550,6553,6559,6562,6566,6569,6572,6575,6579,6583,6586,6589,6595,6598,6602,6605,6628,6630,6636,6641,6644,6650,6653,6656,6673,6676,6680,6683,6711,6714,6742,6746,6749,6755,6758,6764,6767,6777,6780,6786,6789,6797,6811,6820,6824,6837,6840,6846,6850,6853,6859,6862,6868,6871,6874,6877,6880,6883,6914,6917,6921,6925,6928,6931,6938,6941,6945,6948,6951,6957,6960,6966,6969,6972,6977,6980,6983,6987,6993,6996,7000,7006,7012,7015,7018,7032,7036,7039,7045,7048,7052,7055,7058,7064,7067,7087,7090,7094,7097,7103,7106,7120,7123,7127,7130,7136,7139,7145,7148,7154,7156,7162,7165,7171,7175,7178,7185,7188,7205,7208,7212,7215,7218,7278,7285,7338,7341,7344,7350,7356,7359,7362,7368,7371,7375,7378,7401,7405,7409,7412,7419,7422,7426,7429,7433,7440,7443,7447,7450,7452,7478],[10,6198,6194],{"id":6199},"kafka-消息积压如何处理",[14,6201,16],{"id":16},[63,6203,6204],{},[18,6205,6206],{},"Kafka 消息积压不能一上来就盲目增加消费者，首先要确认积压范围和原因：观察各 Partition 的 Consumer Lag、生产速率、消费速率、消费者存活状态、重平衡、处理耗时和下游依赖。如果消费实例异常或下游故障，应先恢复服务；如果生产速度持续大于消费速度，需要对非核心生产流量限流，同时扩容消费者，但同一消费组的有效并行度不会超过 Partition 数量。如果单条处理过慢，应通过批量写库、减少同步 RPC、优化慢 SQL 或使用受控的异步处理提高单实例吞吐；如果只有个别 Partition 积压，要检查消息 Key 是否造成热点；如果被异常消息反复阻塞，需要有限重试后进入死信或人工补偿。恢复时间可以用“积压量 ÷（消费速率－生产速率）”估算，只有消费能力大于生产速度，积压才会真正下降。Offset 跳到最新只能在业务明确同意丢弃旧消息时使用，不能作为常规解决方案。",[18,6208,61],{},[63,6210,6211],{},[18,6212,6213],{},[68,6214,6215],{},"先判断为什么消费速度落后，再从减少流入、恢复异常、提升单实例吞吐和增加有效并行度四个方向处理。",[14,6217,73],{"id":73},[18,6219,6220],{},[77,6221,6224],{"href":6222,"target":80,"rel":6223},"\u002Fimages\u002Fwiki\u002Fjava\u002Fkafka-message-backlog-handling.svg",[82,83],[85,6225],{"src":6222,"alt":6226},"Kafka 消息积压排查与处理流程",[14,6228,90],{"id":90},[18,6230,6231],{},"Kafka 消息积压的本质是：",[118,6233,6236],{"className":6234,"code":6235,"language":123,"meta":124},[121],"一段时间内的生产速度\n>\n一段时间内的有效消费速度\n",[21,6237,6235],{"__ignoreMap":124},[18,6239,6240],{},"积压不是单一故障类型，它可能由突发流量、消费者异常、下游变慢、分区热点或异常消息阻塞引起。不同原因的处理方式完全不同。",[14,6242,6244],{"id":6243},"一什么是-kafka-消息积压","一、什么是 Kafka 消息积压",[18,6246,6247],{},"每个 Partition 中的消息都有 Offset。生产者持续向日志末尾写入，消费组通过已提交 Offset 记录自己的处理进度。",[18,6249,6250],{},"监控消费组时，Consumer Lag 通常可以近似理解为：",[118,6252,6254],{"className":6253,"code":5613,"language":123,"meta":124},[121],[21,6255,5613],{"__ignoreMap":124},[18,6257,1263],{},[118,6259,6262],{"className":6260,"code":6261,"language":123,"meta":124},[121],"Partition Log End Offset：120000\n消费组已提交 Offset：95000\n\nLag = 120000 - 95000 = 25000\n",[21,6263,6261],{"__ignoreMap":124},[18,6265,6266],{},"表示这个消费组在该 Partition 上大约落后 25000 个 Offset。",[18,6268,6269],{},"需要同时观察三类指标：",[341,6271,6272,6283],{},[344,6273,6274],{},[347,6275,6276,6278,6280],{},[350,6277,1308],{},[350,6279,2050],{},[350,6281,6282],{},"判断价值",[360,6284,6285,6296,6307,6318,6329],{},[347,6286,6287,6290,6293],{},[365,6288,6289],{},"当前 Lag",[365,6291,6292],{},"还落后多少 Offset",[365,6294,6295],{},"反映积压规模",[347,6297,6298,6301,6304],{},[365,6299,6300],{},"Lag 增长速度",[365,6302,6303],{},"单位时间新增多少积压",[365,6305,6306],{},"判断问题是否正在恶化",[347,6308,6309,6312,6315],{},[365,6310,6311],{},"最老未处理消息年龄",[365,6313,6314],{},"最老待处理消息的时间戳距现在多久",[365,6316,6317],{},"反映业务已经延迟多久",[347,6319,6320,6323,6326],{},[365,6321,6322],{},"积压字节量",[365,6324,6325],{},"待处理消息占用的总字节数",[365,6327,6328],{},"反映网络、磁盘和反序列化压力",[347,6330,6331,6334,6337],{},[365,6332,6333],{},"单条处理耗时",[365,6335,6336],{},"处理一条或一批消息实际需要多久",[365,6338,6339],{},"用于估算积压清空速度",[18,6341,6342],{},"只看 Lag 绝对值容易误判。例如同样积压 10 万条，在每秒消费 20 万条的系统里可能很快恢复，在每秒只消费 100 条的系统里则非常严重。",[18,6344,6345],{},"Lag 是 Offset 数量差，本身只表示“落后多少条记录”，不能直接等同于时间延迟。对于相同的 10 万 Lag，消费者处理速度越快，处理完现有积压所需的时间越短：",[118,6347,6350],{"className":6348,"code":6349,"language":123,"meta":124},[121],"处理现有积压所需时间\n≈ Lag ÷ 消费速度\n",[21,6351,6349],{"__ignoreMap":124},[18,6353,6354],{},"如果生产者仍在持续写入，要估算 Lag 整体降为 0 的时间，则应扣除生产速度：",[118,6356,6359],{"className":6357,"code":6358,"language":123,"meta":124},[121],"Lag 归零时间\n≈ Lag ÷（消费速度－生产速度）\n",[21,6360,6358],{"__ignoreMap":124},[18,6362,6363],{},"只有消费速度大于生产速度，Lag 才会持续下降。至于当前业务已经延迟多久，应直接查看最老未处理消息的时间戳，而不是只根据 Lag 推算。",[18,6365,6366],{},"消息大小影响的是积压字节量、网络传输和反序列化成本；单条处理复杂度影响的是消费速度。它们都很重要，但不能与 Lag 条数或消息年龄混为同一个指标。",[14,6368,6370],{"id":6369},"二先判断积压发生在哪里","二、先判断积压发生在哪里",[192,6372,6374],{"id":6373},"_1-是所有-partition-积压还是少数-partition-积压","1. 是所有 Partition 积压，还是少数 Partition 积压",[118,6376,6379],{"className":6377,"code":6378,"language":123,"meta":124},[121],"所有 Partition 的 Lag 都增长\n→ 更可能是整体消费能力不足、消费者异常或下游故障\n\n只有少数 Partition 的 Lag 很高\n→ 更可能是 Key 倾斜、热点业务或个别异常消息\n",[21,6380,6378],{"__ignoreMap":124},[18,6382,6383],{},"不能只看 Topic 的总 Lag。总数会掩盖单个热点 Partition，应同时查看每个 Partition 的 Lag、生产速率和消费速率。",[192,6385,6387],{"id":6386},"_2-消费者是否正常工作","2. 消费者是否正常工作",[18,6389,6390],{},"先检查：",[99,6392,6393,6396,6399,6402,6408,6411],{},[102,6394,6395],{},"消费实例是否存活，是否频繁重启。",[102,6397,6398],{},"Consumer Group 中是否存在空闲或反复加入、退出的成员。",[102,6400,6401],{},"是否频繁发生重平衡。",[102,6403,6404,6407],{},[21,6405,6406],{},"poll()"," 是否长时间没有被调用。",[102,6409,6410],{},"Offset 是否持续推进。",[102,6412,6413],{},"消费日志中是否存在反序列化、鉴权、提交 Offset 或业务异常。",[18,6415,6416,6417,6420],{},"如果业务处理时间超过 ",[21,6418,6419],{},"max.poll.interval.ms","，消费者会被认为没有正常推进消费，Partition 可能被重新分配。消费者不断处理、超时、重平衡，又可能造成更严重的积压。",[192,6422,6424],{"id":6423},"_3-单条消息处理是否变慢","3. 单条消息处理是否变慢",[18,6426,6427],{},"Kafka 消费本身往往不是最慢的部分，真正瓶颈通常在业务逻辑：",[99,6429,6430,6433,6436,6439,6442,6445],{},[102,6431,6432],{},"数据库慢 SQL、锁等待或连接池耗尽。",[102,6434,6435],{},"调用外部 RPC 超时。",[102,6437,6438],{},"每条消息单独写库，缺少批处理。",[102,6440,6441],{},"序列化、解压或大对象处理消耗 CPU。",[102,6443,6444],{},"消费逻辑加了粒度过大的锁。",[102,6446,6447],{},"下游 Elasticsearch、Redis 或第三方接口限流。",[18,6449,6450],{},"应把消费耗时拆分为：",[118,6452,6455],{"className":6453,"code":6454,"language":123,"meta":124},[121],"拉取耗时\n+ 反序列化耗时\n+ 业务计算耗时\n+ 数据库 \u002F RPC \u002F 下游写入耗时\n+ Offset 提交耗时\n",[21,6456,6454],{"__ignoreMap":124},[18,6458,6459],{},"只有找到主要耗时，优化才有方向。",[192,6461,6463],{"id":6462},"_4-是否被毒消息阻塞","4. 是否被“毒消息”阻塞",[18,6465,6466],{},"毒消息是指某条数据因为格式错误、业务状态异常或下游约束问题，每次消费都会失败。",[18,6468,6469],{},"如果代码采用无限重试：",[118,6471,6474],{"className":6472,"code":6473,"language":123,"meta":124},[121],"消费失败\n→ 立即重试\n→ 再次失败\n→ 一直占住当前 Partition\n",[21,6475,6473],{"__ignoreMap":124},[18,6477,6478],{},"该 Partition 后续所有消息都可能无法继续处理，表现为单分区 Lag 持续增大。",[192,6480,6482],{"id":6481},"_5-broker-或基础设施是否成为瓶颈","5. Broker 或基础设施是否成为瓶颈",[18,6484,6485],{},"还要检查：",[99,6487,6488,6491,6494,6497,6500],{},[102,6489,6490],{},"Broker 磁盘延迟、网络带宽和 CPU。",[102,6492,6493],{},"Fetch 请求延迟和错误率。",[102,6495,6496],{},"ISR 收缩、离线分区和副本同步异常。",[102,6498,6499],{},"消费者所在机器的 CPU、内存、GC 和网络。",[102,6501,6502],{},"是否发生跨机房访问或网络抖动。",[18,6504,6505],{},"如果 Broker 或网络已经饱和，单纯增加 Consumer 可能只会制造更多请求和竞争。",[14,6507,6509],{"id":6508},"三紧急处理先止住-lag-增长","三、紧急处理：先止住 Lag 增长",[192,6511,6513],{"id":6512},"_1-恢复异常消费者和下游","1. 恢复异常消费者和下游",[18,6515,6516],{},"如果积压源于实例宕机、数据库故障或下游超时，应优先恢复根因：",[118,6518,6521],{"className":6519,"code":6520,"language":123,"meta":124},[121],"恢复消费实例\n→ 恢复数据库 \u002F RPC \u002F 下游\n→ 确认 Offset 开始推进\n→ 再评估是否需要扩容\n",[21,6522,6520],{"__ignoreMap":124},[18,6524,6525],{},"下游仍不可用时强行增加消费者，只会放大连接数、重试和超时流量。",[192,6527,6529],{"id":6528},"_2-对非核心生产流量限流或降级","2. 对非核心生产流量限流或降级",[18,6531,6532],{},"如果生产速度仍在持续上升，而消费端已经满负荷，可以在业务允许时：",[99,6534,6535,6538,6541,6544],{},[102,6536,6537],{},"限制非核心事件的生产速率。",[102,6539,6540],{},"暂停可延迟的定时任务和批量导入。",[102,6542,6543],{},"合并低价值事件。",[102,6545,6546],{},"对非核心功能降级。",[18,6548,6549],{},"这不是最终解决方案，但能降低流入速度，给消费端争取恢复窗口。",[18,6551,6552],{},"这里的“合并低价值事件”，不是随意删除消息，而是对业务允许只保留最终状态或聚合结果的事件进行压缩。例如：",[118,6554,6557],{"className":6555,"code":6556,"language":123,"meta":124},[121],"同一个商品在 1 秒内连续产生 20 次缓存刷新通知\n→ 只保留一次刷新通知\n\n同一设备连续上报多次进度：10%、20%、30%\n→ 如果业务只关心最新进度，可以只发送 30%\n\n大量指标增量事件\n→ 在生产端按时间窗口汇总后，发送一条聚合结果\n",[21,6558,6556],{"__ignoreMap":124},[18,6560,6561],{},"合并前必须先定义清楚业务语义，包括按什么 Key 合并、合并时间窗口多长、保留最新值还是累计值，以及异常时如何补偿。订单状态流转、支付、账户流水、库存扣减、审计日志等每条事件都具有独立业务意义，不能使用这种方式合并。",[192,6563,6565],{"id":6564},"_3-确认消息保留时间是否足够","3. 确认消息保留时间是否足够",[18,6567,6568],{},"积压消息依赖 Kafka 的日志保留策略。如果预计追赶需要数小时或数天，应确认 Topic 的保留时间和磁盘空间是否足够。",[18,6570,6571],{},"如果最老未消费消息超过保留期限，旧日志可能被清理。此时即使消费者恢复，也无法从 Kafka 读取已经删除的数据。",[18,6573,6574],{},"紧急情况下可以评估临时延长保留时间，但必须同步评估 Broker 磁盘容量，避免积压尚未解决又触发磁盘告警。",[14,6576,6578],{"id":6577},"四提升消费能力","四、提升消费能力",[192,6580,6582],{"id":6581},"_1-增加-consumer-实例","1. 增加 Consumer 实例",[18,6584,6585],{},"增加同一 Consumer Group 中的实例，可以让更多 Partition 并行消费。",[18,6587,6588],{},"但有效并行度受 Partition 数量限制：",[118,6590,6593],{"className":6591,"code":6592,"language":123,"meta":124},[121],"8 个 Partition + 4 个 Consumer\n→ 可以继续扩容\n\n8 个 Partition + 8 个 Consumer\n→ 已接近分区级并行上限\n\n8 个 Partition + 12 个 Consumer\n→ 约 4 个 Consumer 无 Partition 可处理\n",[21,6594,6592],{"__ignoreMap":124},[18,6596,6597],{},"因此扩容前要同时查看当前 Partition 数量、消费者数量和分配情况。",[192,6599,6601],{"id":6600},"_2-优化单实例处理吞吐","2. 优化单实例处理吞吐",[18,6603,6604],{},"常见优化方式：",[99,6606,6607,6610,6613,6616,6619,6622,6625],{},[102,6608,6609],{},"把逐条写数据库改为批量写入。",[102,6611,6612],{},"合并相同业务 Key 的重复更新。",[102,6614,6615],{},"优化 SQL、索引和事务范围。",[102,6617,6618],{},"减少消费线程中的同步远程调用。",[102,6620,6621],{},"对可并行步骤使用有界线程池。",[102,6623,6624],{},"复用连接和客户端，避免每条消息重复创建。",[102,6626,6627],{},"降低无必要的日志和对象序列化开销。",[18,6629,1263],{},[118,6631,6634],{"className":6632,"code":6633,"language":123,"meta":124},[121],"原方案：\n每条消息 → 一次数据库事务\n\n优化后：\n一批消息 → 分组校验 → 批量写入 → 提交对应 Offset\n",[21,6635,6633],{"__ignoreMap":124},[18,6637,6638,6639,52],{},"批量越大不一定越好。批次过大会增加内存占用、事务时间和失败重试成本，还可能让一次处理时间超过 ",[21,6640,6419],{},[18,6642,6643],{},"这里的“同步远程调用”，是指消费线程发送 RPC 或 HTTP 请求后，必须等待对方返回才能继续处理下一条消息：",[118,6645,6648],{"className":6646,"code":6647,"language":123,"meta":124},[121],"消费一条消息\n→ 调用远程库存服务\n→ 阻塞等待 50 ms\n→ 收到结果\n→ 再处理下一条消息\n",[21,6649,6647],{"__ignoreMap":124},[18,6651,6652],{},"即使本地计算只需要 1 ms，线程的大部分时间也消耗在网络等待上。如果每条消息都串行调用一次远程服务，单线程理论吞吐很容易被远程调用耗时限制。",[18,6654,6655],{},"“减少同步 RPC”可以从以下方向处理：",[99,6657,6658,6661,6664,6667,6670],{},[102,6659,6660],{},"把逐条调用改为批量接口，例如一次查询或提交 100 条。",[102,6662,6663],{},"对可复用且允许短时间不一致的数据使用本地缓存，减少重复查询。",[102,6665,6666],{},"把互不依赖的调用改成受控并发，但必须限制并发数，避免压垮下游。",[102,6668,6669],{},"将通知、埋点等非核心副作用发送到下游 Topic，由独立消费者异步执行。",[102,6671,6672],{},"合理设置超时、熔断和连接池，避免故障调用长期占住消费线程。",[18,6674,6675],{},"如果必须拿到远程结果才能保证当前消息处理正确，就不能为了吞吐简单删除该 RPC。此时更重要的是批量化、限制并发、幂等和下游容量治理。",[192,6677,6679],{"id":6678},"_3-谨慎调整消费参数","3. 谨慎调整消费参数",[18,6681,6682],{},"常见参数包括：",[118,6684,6686],{"className":4152,"code":6685,"language":4154,"meta":124,"style":124},"max.poll.records=500\nmax.poll.interval.ms=300000\nfetch.min.bytes=1\nfetch.max.wait.ms=500\nmax.partition.fetch.bytes=1048576\n",[21,6687,6688,6693,6698,6702,6706],{"__ignoreMap":124},[142,6689,6690],{"class":144,"line":145},[142,6691,6692],{},"max.poll.records=500\n",[142,6694,6695],{"class":144,"line":151},[142,6696,6697],{},"max.poll.interval.ms=300000\n",[142,6699,6700],{"class":144,"line":157},[142,6701,5651],{},[142,6703,6704],{"class":144,"line":163},[142,6705,5656],{},[142,6707,6708],{"class":144,"line":169},[142,6709,6710],{},"max.partition.fetch.bytes=1048576\n",[18,6712,6713],{},"调整原则：",[99,6715,6716,6726,6733,6739],{},[102,6717,6718,6719,6722,6723,6725],{},"如果一批消息处理不完，应适当减小 ",[21,6720,6721],{},"max.poll.records","，或优化处理速度，而不是只把 ",[21,6724,6419],{}," 调得无限大。",[102,6727,6728,6729,6732],{},"增大 ",[21,6730,6731],{},"fetch.min.bytes"," 可以提高批量拉取效率，但会增加低流量时的等待延迟。",[102,6734,6735,6738],{},[21,6736,6737],{},"max.partition.fetch.bytes"," 过小可能限制大批次拉取，但调大后要评估客户端内存。",[102,6740,6741],{},"参数优化只能降低 Kafka 拉取开销，无法解决数据库或 RPC 本身处理缓慢。",[192,6743,6745],{"id":6744},"_4-异步处理必须有边界","4. 异步处理必须有边界",[18,6747,6748],{},"一种常见设计是由 Poll 线程负责拉取，再把消息交给工作线程池处理：",[118,6750,6753],{"className":6751,"code":6752,"language":123,"meta":124},[121],"Poll 线程\n→ 有界队列\n→ 工作线程池\n→ 处理完成\n→ 按 Partition 推进可安全提交的 Offset\n",[21,6754,6752],{"__ignoreMap":124},[18,6756,6757],{},"为什么必须使用有界队列？假设 Kafka 已经积压 100 万条，Poll 线程仍然高速拉取并塞入无界队列，而工作线程每秒只能处理 100 条，那么积压只是从 Kafka 的磁盘日志转移到了 JVM 堆内存。结果可能是：",[118,6759,6762],{"className":6760,"code":6761,"language":123,"meta":124},[121],"队列持续增长\n→ 堆内存占用上升\n→ Full GC 频繁\n→ 消费进程响应变慢甚至 OOM\n→ 未提交的内存任务随进程退出而丢失并被重新投递\n",[21,6763,6761],{"__ignoreMap":124},[18,6765,6766],{},"Kafka 本身就是持久化队列，没有必要把尚未具备处理能力的消息提前搬进易失的 JVM 内存。",[5727,6768,6770,6771,1441,6774],{"id":6769},"使用高低水位控制-pause-和-resume","使用高、低水位控制 ",[21,6772,6773],{},"pause()",[21,6775,6776],{},"resume()",[18,6778,6779],{},"可以为队列设置容量和两个阈值。例如队列容量为 10000：",[118,6781,6784],{"className":6782,"code":6783,"language":123,"meta":124},[121],"高水位：8000\n队列达到高水位\n→ Poll 线程对相关 Partition 调用 pause()\n→ 后续 poll() 暂停返回这些 Partition 的新消息\n\n低水位：3000\n工作线程处理后，队列下降到低水位\n→ Poll 线程调用 resume()\n→ 后续 poll() 重新拉取这些 Partition\n",[21,6785,6783],{"__ignoreMap":124},[18,6787,6788],{},"使用两个不同阈值是为了避免队列在一个临界值附近反复暂停、恢复。阈值不能照搬固定数字，应根据单条消息大小、堆内存、工作线程数和峰值处理耗时进行容量评估。",[18,6790,6791,6793,6794,6796],{},[21,6792,6773],{}," 的含义是暂停指定 Partition 在后续 ",[21,6795,6406],{}," 中返回新记录，它不会：",[99,6798,6799,6802,6805,6808],{},[102,6800,6801],{},"取消当前 Partition 的分配。",[102,6803,6804],{},"自动提交 Offset。",[102,6806,6807],{},"主动触发 Consumer Group 重平衡。",[102,6809,6810],{},"清除已经拉取并放入本地队列的消息。",[18,6812,6813,6814,6816,6817,6819],{},"暂停期间仍然必须持续调用 ",[21,6815,6406],{},"，让 Consumer 处理心跳、协调和重平衡事件。不能因为所有分区都已暂停，就让 Poll 线程长时间睡眠或等待队列清空，否则仍可能超过 ",[21,6818,6419],{}," 并失去分区。",[5727,6821,6823],{"id":6822},"只能由-consumer-所在线程控制拉取","只能由 Consumer 所在线程控制拉取",[18,6825,6826,6829,6830,5196,6832,5196,6834,6836],{},[21,6827,6828],{},"KafkaConsumer"," 不是线程安全的。通常由唯一的 Poll 线程持有并调用 ",[21,6831,6406],{},[21,6833,6773],{},[21,6835,6776],{}," 和提交 Offset；工作线程只处理业务，并把“完成结果”写回一个线程安全的完成队列。工作线程不能直接操作同一个 Consumer。",[18,6838,6839],{},"伪代码可以理解为：",[118,6841,6844],{"className":6842,"code":6843,"language":123,"meta":124},[121],"Poll 线程循环：\n 读取工作线程上报的完成结果\n 推进每个 Partition 的连续成功 Offset\n 根据队列水位执行 pause \u002F resume\n poll() 拉取允许继续消费的 Partition\n 把记录投递到对应的有界工作队列\n\n工作线程：\n 处理业务\n 成功或失败结果写回完成队列\n 不直接调用 KafkaConsumer\n",[21,6845,6843],{"__ignoreMap":124},[5727,6847,6849],{"id":6848},"为什么要按-partition-提交连续成功区间","为什么要按 Partition 提交“连续成功区间”",[18,6851,6852],{},"假设同一 Partition 拉取到：",[118,6854,6857],{"className":6855,"code":6856,"language":123,"meta":124},[121],"Offset 100、101、102\n",[21,6858,6856],{"__ignoreMap":124},[18,6860,6861],{},"并发处理结果是：",[118,6863,6866],{"className":6864,"code":6865,"language":123,"meta":124},[121],"100 成功\n101 仍在处理\n102 成功\n",[21,6867,6865],{"__ignoreMap":124},[18,6869,6870],{},"此时最多只能提交 101，也就是声明 100 已处理完成；不能提交 103。否则进程在 101 完成前崩溃，重启后会从 103 开始，101 就可能被永久跳过。",[18,6872,6873],{},"只有 101 也成功后，100～102 形成连续成功区间，才能提交 103。若业务要求同一 Partition 严格有序，最简单的方式是同一 Partition 串行处理，不要并发执行。",[5727,6875,6876],{"id":6876},"重平衡时还要处理本地未完成任务",[18,6878,6879],{},"发生 Partition 撤销时，应停止向被撤销 Partition 的队列继续投递，并在回调允许的时间内提交已经连续处理成功的 Offset。尚未完成或来不及安全提交的任务，应允许新 Consumer 从旧 Offset 重新消费，因此业务处理必须具备幂等性。",[18,6881,6882],{},"需要共同遵守的约束包括：",[99,6884,6885,6890,6893,6900,6905,6908,6911],{},[102,6886,6887,6889],{},[21,6888,6828],{}," 本身不是线程安全的，不能让多个工作线程同时操作同一个 Consumer。",[102,6891,6892],{},"队列必须有界，不能把 Kafka 的积压无上限转移到 JVM 内存。",[102,6894,6895,5705,6897,6899],{},[21,6896,6773],{},[21,6898,6776],{}," 应由 Poll 线程执行，工作线程通过控制信号提出请求。",[102,6901,6902,6903,52],{},"即使 Partition 已暂停，Poll 线程也要持续执行 ",[21,6904,6406],{},[102,6906,6907],{},"Offset 必须在消息真正处理成功后提交。",[102,6909,6910],{},"同一 Partition 如果要求严格顺序，不能让后面的消息先于前面的消息产生业务效果。",[102,6912,6913],{},"并发完成后只能提交“连续成功区间”的下一个 Offset，不能跨过尚未完成或失败的消息。",[18,6915,6916],{},"异步化能提高吞吐，但会显著增加 Offset、顺序和失败处理的复杂度。",[14,6918,6920],{"id":6919},"五partition-不够时怎么办","五、Partition 不够时怎么办",[192,6922,6924],{"id":6923},"_1-增加-partition-主要提升未来并行度","1. 增加 Partition 主要提升未来并行度",[18,6926,6927],{},"如果 Consumer 数量已经等于 Partition 数量，且单分区处理能力也接近上限，可以评估增加 Partition。",[18,6929,6930],{},"但要明确：",[63,6932,6933],{},[18,6934,6935],{},[68,6936,6937],{},"给 Topic 新增 Partition，不会把旧 Partition 中已经积压的消息自动重新分布到新 Partition。",[18,6939,6940],{},"新 Partition 主要承接之后产生的新消息。旧积压仍然留在原来的 Partition 中，仍需由对应消费者追赶。",[192,6942,6944],{"id":6943},"_2-增加-partition-可能改变-key-路由","2. 增加 Partition 可能改变 Key 路由",[18,6946,6947],{},"默认的 Key 哈希结果通常与 Partition 数量有关。增加 Partition 后，同一个 Key 的新消息可能进入不同于历史消息的 Partition，从而影响跨扩容时点的顺序假设。",[18,6949,6950],{},"例如为了便于理解，假设某个分区规则可以简化为：",[118,6952,6955],{"className":6953,"code":6954,"language":123,"meta":124},[121],"目标分区 = hash(key) % Partition 数量\n",[21,6956,6954],{"__ignoreMap":124},[18,6958,6959],{},"同一个 Key 的哈希值为 13：",[118,6961,6964],{"className":6962,"code":6963,"language":123,"meta":124},[121],"原来 4 个 Partition：13 % 4 = 1，写入 P1\n扩容到 8 个 Partition：13 % 8 = 5，新消息写入 P5\n",[21,6965,6963],{"__ignoreMap":124},[18,6967,6968],{},"扩容前已经写入 P1 的旧消息不会被搬到 P5。P1 和 P5 又可能由不同 Consumer 并行处理，因此 P5 中的新消息可能先于 P1 中的旧消息完成。这个风险不只是“扩容瞬间”存在，而是会持续到旧分区中的相关历史消息全部处理完毕。",[18,6970,6971],{},"所谓“消费端能否接受跨分区处理”，实际是在问：",[63,6973,6974],{},[18,6975,6976],{},"同一个业务 Key 的旧消息和新消息同时位于不同 Partition，并可能并行、乱序完成时，业务是否仍然正确？",[18,6978,6979],{},"如果事件是独立日志或幂等的最终状态覆盖，业务可能可以接受；如果事件依赖严格顺序，例如“创建订单 → 支付成功 → 关闭订单”，就不能直接接受。",[18,6981,6982],{},"如果业务依赖同一 Key 的严格顺序，常见选择有：",[5727,6984,6986],{"id":6985},"方案一排空旧消息后再扩分区","方案一：排空旧消息后再扩分区",[118,6988,6991],{"className":6989,"code":6990,"language":123,"meta":124},[121],"限制或暂停生产\n→ 等待旧 Topic 的相关消息处理完成\n→ 增加 Partition\n→ 恢复生产\n",[21,6992,6990],{"__ignoreMap":124},[18,6994,6995],{},"这种方式逻辑最清楚，但需要维护窗口，而且在高流量系统中可能很难完全停写。",[5727,6997,6999],{"id":6998},"方案二新建-topic-并进行受控切换","方案二：新建 Topic 并进行受控切换",[18,7001,7002,7003,3639],{},"例如创建具有目标分区数和新路由规则的 ",[21,7004,7005],{},"order-events-v2",[118,7007,7010],{"className":7008,"code":7009,"language":123,"meta":124},[121],"1. 创建并验证新 Topic\n2. 定义明确的切换时间、版本号或业务水位\n3. 新消息从切换点开始写入 v2\n4. v1 消费者继续处理切换点以前的旧消息\n5. 确认某个 Key 或全部旧消息越过安全水位后，再允许 v2 对应消息生效\n6. 完成核对后停止 v1，并保留回滚方案\n",[21,7011,7009],{"__ignoreMap":124},[18,7013,7014],{},"新建 Topic 的价值是把新旧路由、配置和消费组隔离开，便于验证与回滚；代价是必须设计双 Topic 切换、重复消息、遗漏检查和新旧 Offset 衔接。它不是 Kafka 自动迁移，而是业务自己完成的版本化切换。",[18,7016,7017],{},"因此扩分区前应明确回答：",[99,7019,7020,7023,7026,7029],{},[102,7021,7022],{},"分区器如何计算目标 Partition。",[102,7024,7025],{},"旧消息是否已经处理完成。",[102,7027,7028],{},"同一 Key 跨新旧 Partition 并行处理是否会破坏业务顺序。",[102,7030,7031],{},"是选择维护窗口排空旧消息，还是新建 Topic 做受控切换。",[192,7033,7035],{"id":7034},"_3-极端情况下建立临时加速链路","3. 极端情况下建立临时加速链路",[18,7037,7038],{},"当原 Topic 分区数严重不足、积压量巨大时，可以设计经过评审的临时方案：",[118,7040,7043],{"className":7041,"code":7042,"language":123,"meta":124},[121],"原 Topic\n→ 临时搬运程序\n→ 更高分区数的中转 Topic\n→ 临时扩容后的消费组\n→ 业务处理\n",[21,7044,7042],{"__ignoreMap":124},[18,7046,7047],{},"这会引入顺序、重复、Offset 衔接和回切问题，只适合经过完整设计和演练的场景，不能在生产事故中临时拍脑袋执行。",[14,7049,7051],{"id":7050},"六热点-partition-如何处理","六、热点 Partition 如何处理",[18,7053,7054],{},"如果只有少数 Partition 积压，需要检查消息 Key 分布。",[18,7056,7057],{},"例如所有消息都使用同一个固定 Key：",[118,7059,7062],{"className":7060,"code":7061,"language":123,"meta":124},[121],"key = \"default\"\n→ 所有消息进入同一 Partition\n→ 其他 Partition 空闲\n→ 单分区成为瓶颈\n",[21,7063,7061],{"__ignoreMap":124},[18,7065,7066],{},"解决方向包括：",[99,7068,7069,7072,7075,7081,7084],{},[102,7070,7071],{},"选择分布更均匀的业务 Key。",[102,7073,7074],{},"对非顺序场景取消固定 Key。",[102,7076,7077,7078,52],{},"对热点业务 Key 做可控分片，例如 ",[21,7079,7080],{},"userId + shardNo",[102,7082,7083],{},"单独拆分热点租户或热点业务到独立 Topic。",[102,7085,7086],{},"优化该 Partition 对应消费者的单条处理耗时。",[18,7088,7089],{},"Key 拆分会改变顺序语义。原来同一 Key 的全局顺序，拆分后通常只能保证每个子 Key 内部有序。",[14,7091,7093],{"id":7092},"七毒消息和重试如何处理","七、毒消息和重试如何处理",[18,7095,7096],{},"不要让一条永远失败的消息无限阻塞 Partition。常见处理策略是：",[118,7098,7101],{"className":7099,"code":7100,"language":123,"meta":124},[121],"第一次失败\n→ 记录错误并有限重试\n→ 仍然失败\n→ 进入重试 Topic \u002F 死信 Topic\n→ 主消费链路继续\n→ 告警和人工补偿\n",[21,7102,7100],{"__ignoreMap":124},[18,7104,7105],{},"需要保留：",[99,7107,7108,7111,7114,7117],{},[102,7109,7110],{},"原始 Topic、Partition 和 Offset。",[102,7112,7113],{},"消息 Key、事件 ID 和原始内容。",[102,7115,7116],{},"异常原因和重试次数。",[102,7118,7119],{},"首次失败和最后失败时间。",[18,7121,7122],{},"如果业务要求同一 Key 严格顺序，就不能简单跳过失败消息继续处理后续消息。此时应暂停对应 Partition，优先修复或补偿该消息；这是吞吐与顺序之间的业务取舍。",[14,7124,7126],{"id":7125},"八如何估算多久能消化完积压","八、如何估算多久能消化完积压",[18,7128,7129],{},"设：",[118,7131,7134],{"className":7132,"code":7133,"language":123,"meta":124},[121],"B = 当前积压消息数\nP = 当前生产速度（条\u002F秒）\nC = 扩容后的稳定消费速度（条\u002F秒）\n",[21,7135,7133],{"__ignoreMap":124},[18,7137,7138],{},"只有：",[118,7140,7143],{"className":7141,"code":7142,"language":123,"meta":124},[121],"C > P\n",[21,7144,7142],{"__ignoreMap":124},[18,7146,7147],{},"积压才会下降。理论恢复时间约为：",[118,7149,7152],{"className":7150,"code":7151,"language":123,"meta":124},[121],"恢复时间 T = B \u002F (C - P)\n",[21,7153,7151],{"__ignoreMap":124},[18,7155,1263],{},[118,7157,7160],{"className":7158,"code":7159,"language":123,"meta":124},[121],"当前积压 B = 360 万条\n生产速度 P = 2000 条\u002F秒\n消费速度 C = 5000 条\u002F秒\n\n净消化速度 = 5000 - 2000 = 3000 条\u002F秒\n理论恢复时间 = 3600000 \u002F 3000 = 1200 秒\n≈ 20 分钟\n",[21,7161,7159],{"__ignoreMap":124},[18,7163,7164],{},"实际还要为重平衡、失败重试、下游波动和流量峰值预留余量。",[18,7166,3660,7167,7170],{},[21,7168,7169],{},"C \u003C= P","，无论运行多久都追不上，必须降低生产速率或提高有效消费能力。",[14,7172,7174],{"id":7173},"九offset-跳到最新为什么不是常规方案","九、Offset 跳到最新为什么不是常规方案",[18,7176,7177],{},"把消费组 Offset 重置到最新位置，确实可以让 Lag 迅速变成 0，但其本质是：",[63,7179,7180],{},[18,7181,7182],{},[68,7183,7184],{},"主动放弃尚未消费的历史消息。",[18,7186,7187],{},"只有同时满足以下条件才可以考虑：",[99,7189,7190,7193,7196,7199,7202],{},[102,7191,7192],{},"业务明确确认旧消息可以丢弃。",[102,7194,7195],{},"已评估对账、状态和下游影响。",[102,7197,7198],{},"已保留必要的审计或补偿数据。",[102,7200,7201],{},"操作前进行了 Dry Run，并确认 Topic、Consumer Group 和目标 Offset。",[102,7203,7204],{},"操作期间停止相关消费者，避免 Offset 并发变化。",[18,7206,7207],{},"资金、订单、库存等关键链路不能把重置 Offset 当作普通清积压手段。",[192,7209,7211],{"id":7210},"什么是-dry-run","什么是 Dry Run",[18,7213,7214],{},"Dry Run 就是“只预演，不执行”。它先计算并展示每个 Partition 将从哪个 Offset 调整到哪个 Offset，供操作人员核对 Topic、消费组、分区范围和目标位置，但不真正修改已提交 Offset。",[18,7216,7217],{},"例如将消费组预演重置到最新位置：",[118,7219,7223],{"className":7220,"code":7221,"language":7222,"meta":124,"style":124},"language-bash shiki shiki-themes github-light github-dark","bin\u002Fkafka-consumer-groups.sh \\\n --bootstrap-server kafka.example.com:9092 \\\n --group order-consumer-group \\\n --topic order-events \\\n --reset-offsets \\\n --to-latest\n","bash",[21,7224,7225,7235,7246,7256,7266,7273],{"__ignoreMap":124},[142,7226,7227,7231],{"class":144,"line":145},[142,7228,7230],{"class":7229},"sScJk","bin\u002Fkafka-consumer-groups.sh",[142,7232,7234],{"class":7233},"sj4cs"," \\\n",[142,7236,7237,7240,7244],{"class":144,"line":151},[142,7238,7239],{"class":7233}," --bootstrap-server",[142,7241,7243],{"class":7242},"sZZnC"," kafka.example.com:9092",[142,7245,7234],{"class":7233},[142,7247,7248,7251,7254],{"class":144,"line":157},[142,7249,7250],{"class":7233}," --group",[142,7252,7253],{"class":7242}," order-consumer-group",[142,7255,7234],{"class":7233},[142,7257,7258,7261,7264],{"class":144,"line":163},[142,7259,7260],{"class":7233}," --topic",[142,7262,7263],{"class":7242}," order-events",[142,7265,7234],{"class":7233},[142,7267,7268,7271],{"class":144,"line":169},[142,7269,7270],{"class":7233}," --reset-offsets",[142,7272,7234],{"class":7233},[142,7274,7275],{"class":144,"line":175},[142,7276,7277],{"class":7233}," --to-latest\n",[18,7279,7280,7281,7284],{},"Kafka 4.1 的消费组工具默认只展示重置计划；确认结果无误后，显式增加 ",[21,7282,7283],{},"--execute"," 才会真正执行：",[118,7286,7288],{"className":7220,"code":7287,"language":7222,"meta":124,"style":124},"bin\u002Fkafka-consumer-groups.sh \\\n --bootstrap-server kafka.example.com:9092 \\\n --group order-consumer-group \\\n --topic order-events \\\n --reset-offsets \\\n --to-latest \\\n --execute\n",[21,7289,7290,7296,7304,7312,7320,7326,7333],{"__ignoreMap":124},[142,7291,7292,7294],{"class":144,"line":145},[142,7293,7230],{"class":7229},[142,7295,7234],{"class":7233},[142,7297,7298,7300,7302],{"class":144,"line":151},[142,7299,7239],{"class":7233},[142,7301,7243],{"class":7242},[142,7303,7234],{"class":7233},[142,7305,7306,7308,7310],{"class":144,"line":157},[142,7307,7250],{"class":7233},[142,7309,7253],{"class":7242},[142,7311,7234],{"class":7233},[142,7313,7314,7316,7318],{"class":144,"line":163},[142,7315,7260],{"class":7233},[142,7317,7263],{"class":7242},[142,7319,7234],{"class":7233},[142,7321,7322,7324],{"class":144,"line":169},[142,7323,7270],{"class":7233},[142,7325,7234],{"class":7233},[142,7327,7328,7331],{"class":144,"line":175},[142,7329,7330],{"class":7233}," --to-latest",[142,7332,7234],{"class":7233},[142,7334,7335],{"class":144,"line":181},[142,7336,7337],{"class":7233}," --execute\n",[18,7339,7340],{},"不同 Kafka 版本的工具参数可能略有差异，生产操作前应以实际部署版本的命令帮助和官方文档为准。",[192,7342,7343],{"id":7343},"为什么操作期间要停止消费者",[18,7345,7346,7347,7349],{},"活动消费者会继续执行 ",[21,7348,6406],{},"、处理消息并提交 Offset。如果管理人员同时重置 Offset，就可能发生竞态：",[118,7351,7354],{"className":7352,"code":7353,"language":123,"meta":124},[121],"管理员把 Offset 从 1000 重置到 5000\n→ 仍在运行的消费者随后提交自己内存中的旧进度 1200\n→ 重置结果被旧提交覆盖\n",[21,7355,7353],{"__ignoreMap":124},[18,7357,7358],{},"反过来也可能是消费者刚处理到 1300，管理员基于稍早看到的状态执行重置，导致已处理消息重复消费或尚未处理消息被跳过。活动成员还可能触发重平衡，使操作时看到的分区归属和 Offset 继续变化。",[18,7360,7361],{},"因此安全流程应是：",[118,7363,7366],{"className":7364,"code":7365,"language":123,"meta":124},[121],"停止该消费组的所有消费者\n→ 确认消费组已无活动成员\n→ 记录操作前 Offset\n→ 执行 Dry Run 并双人核对\n→ 使用 --execute 修改 Offset\n→ 再次查询并确认结果\n→ 启动消费者并观察消费位置\n",[21,7367,7365],{"__ignoreMap":124},[18,7369,7370],{},"这不仅是避免并发覆盖。Kafka 官方的消费组 Offset 重置说明也明确要求先确保消费实例处于非活动状态。",[14,7372,7374],{"id":7373},"十恢复后要做什么","十、恢复后要做什么",[18,7376,7377],{},"积压恢复不代表问题结束，还应完成：",[708,7379,7380,7383,7386,7389,7392,7395,7398],{},[102,7381,7382],{},"复盘根因和时间线。",[102,7384,7385],{},"补充总 Lag、最大分区 Lag、时间 Lag 和增长率告警。",[102,7387,7388],{},"建立生产速度、消费速度和预计恢复时间看板。",[102,7390,7391],{},"对热点 Partition、毒消息和下游耗时建立专项监控。",[102,7393,7394],{},"按峰值流量进行容量压测，保留消费冗余。",[102,7396,7397],{},"演练消费者扩容、下游故障、重平衡和死信补偿。",[102,7399,7400],{},"核对积压期间是否发生消息过期、重复处理或业务遗漏。",[14,7402,7404],{"id":7403},"十一常见误区","十一、常见误区",[192,7406,7408],{"id":7407},"误区一积压就直接增加-consumer","误区一：积压就直接增加 Consumer",[18,7410,7411],{},"如果 Partition 数量不足、多数 Consumer 已空闲，或者瓶颈实际在数据库，增加 Consumer 不会解决问题，反而可能加剧下游压力。",[192,7413,7415,7416,7418],{"id":7414},"误区二把-maxpollrecords-调大就能提升吞吐","误区二：把 ",[21,7417,6721],{}," 调大就能提升吞吐",[18,7420,7421],{},"拉取更多消息不等于处理更快。批次过大还可能导致处理超时、重平衡和更高的失败重试成本。",[192,7423,7425],{"id":7424},"误区三增加-partition-会重新分配旧积压","误区三：增加 Partition 会重新分配旧积压",[18,7427,7428],{},"新增 Partition 不会迁移旧 Partition 中已有的消息，只能为后续消息提供更多并行空间。",[192,7430,7432],{"id":7431},"误区四lag-等于业务延迟","误区四：Lag 等于业务延迟",[18,7434,7435,7436,7439],{},"Lag 是 Offset 数量差，只表示还落后多少条记录，不等于时间延迟。相同 Lag 下，消费者处理速度越快，处理完现有积压所需的时间越短；如果生产仍在继续，则应使用 ",[21,7437,7438],{},"Lag ÷（消费速度－生产速度）"," 估算 Lag 归零时间。",[18,7441,7442],{},"当前业务已经延迟多久，应通过最老未处理消息的时间戳判断。消息大小影响积压字节量、网络与反序列化成本，单条处理耗时影响消费速度。因此排查时应把 Lag 条数、最老消息年龄、积压字节量和实际处理吞吐分开观察，不能混成一个指标。",[192,7444,7446],{"id":7445},"误区五把-offset-跳到最新就是清理积压","误区五：把 Offset 跳到最新就是清理积压",[18,7448,7449],{},"这不是“处理了积压”，而是“丢弃了积压”。必须经过明确的业务授权和风险评估。",[14,7451,1570],{"id":1570},[99,7453,7454,7459,7464,7471],{},[102,7455,7456],{},[77,7457,5104],{"href":5102,"rel":7458},[1579],[102,7460,7461],{},[77,7462,5118],{"href":5116,"rel":7463},[1579],[102,7465,7466],{},[77,7467,7470],{"href":7468,"rel":7469},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Foperations\u002Fconsumer-rebalance-protocol\u002F",[1579],"Apache Kafka Consumer Rebalance Protocol",[102,7472,7473],{},[77,7474,7477],{"href":7475,"rel":7476},"https:\u002F\u002Fkafka.apache.org\u002F41\u002Foperations\u002Fbasic-kafka-operations\u002F",[1579],"Apache Kafka Basic Operations",[1596,7479,7480],{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}",{"title":124,"searchDepth":151,"depth":151,"links":7482},[7483,7484,7485,7486,7487,7494,7499,7505,7510,7511,7512,7513,7517,7518,7526],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":6243,"depth":151,"text":6244},{"id":6369,"depth":151,"text":6370,"children":7488},[7489,7490,7491,7492,7493],{"id":6373,"depth":157,"text":6374},{"id":6386,"depth":157,"text":6387},{"id":6423,"depth":157,"text":6424},{"id":6462,"depth":157,"text":6463},{"id":6481,"depth":157,"text":6482},{"id":6508,"depth":151,"text":6509,"children":7495},[7496,7497,7498],{"id":6512,"depth":157,"text":6513},{"id":6528,"depth":157,"text":6529},{"id":6564,"depth":157,"text":6565},{"id":6577,"depth":151,"text":6578,"children":7500},[7501,7502,7503,7504],{"id":6581,"depth":157,"text":6582},{"id":6600,"depth":157,"text":6601},{"id":6678,"depth":157,"text":6679},{"id":6744,"depth":157,"text":6745},{"id":6919,"depth":151,"text":6920,"children":7506},[7507,7508,7509],{"id":6923,"depth":157,"text":6924},{"id":6943,"depth":157,"text":6944},{"id":7034,"depth":157,"text":7035},{"id":7050,"depth":151,"text":7051},{"id":7092,"depth":151,"text":7093},{"id":7125,"depth":151,"text":7126},{"id":7173,"depth":151,"text":7174,"children":7514},[7515,7516],{"id":7210,"depth":157,"text":7211},{"id":7343,"depth":157,"text":7343},{"id":7373,"depth":151,"text":7374},{"id":7403,"depth":151,"text":7404,"children":7519},[7520,7521,7523,7524,7525],{"id":7407,"depth":157,"text":7408},{"id":7414,"depth":157,"text":7522},"误区二：把 max.poll.records 调大就能提升吞吐",{"id":7424,"depth":157,"text":7425},{"id":7431,"depth":157,"text":7432},{"id":7445,"depth":157,"text":7446},{"id":1570,"depth":151,"text":1570},"wiki:java:kafka-message-backlog-handling","从 Consumer Lag 识别、瓶颈定位、限流止血、消费者扩容、批量处理、热点分区和毒消息治理等方面，系统讲解 Kafka 消息积压处理方案。",{},74,"\u002Fjava\u002Fkafka-message-backlog-handling",{"title":6194,"description":7528},"java\u002Fkafka-message-backlog-handling","JV6UjzzTuFU1AgBQpyXiVtkOWs_5BYokwcLCeslmZRA",{"id":7536,"title":7537,"body":7538,"commentId":8967,"description":8968,"difficulty":3063,"draft":1646,"extension":1647,"meta":8969,"navigation":780,"order":8970,"path":8971,"section":1651,"seo":8972,"stem":8973,"updated":5173,"__hash__":8974},"java\u002Fjava\u002Fmysql-transaction-isolation-and-phantom-read.md","MySQL 的隔离级别都有哪些？如何避免幻读？",{"type":7,"value":7539,"toc":8918},[7540,7542,7545,7584,7587,7601,7604,7607,7612,7614,7623,7625,7629,7632,7637,7640,7643,7724,7726,7731,7735,7739,7742,7748,7754,7758,7761,7767,7770,7775,7779,7782,7788,7791,7794,7799,7802,7810,7814,7818,7821,7832,7835,7839,7842,7845,7851,7854,7860,7868,7872,7875,7881,7887,7890,7893,7897,7900,7906,7917,7920,7923,7927,7930,7934,7940,7949,7952,7963,7966,7970,7973,7997,8000,8003,8007,8010,8034,8041,8065,8068,8081,8084,8087,8092,8095,8099,8102,8129,8136,8145,8148,8151,8164,8171,8174,8179,8183,8187,8190,8192,8210,8216,8220,8223,8226,8232,8235,8241,8244,8248,8251,8257,8260,8266,8269,8275,8295,8298,8303,8306,8324,8337,8343,8346,8352,8355,8358,8382,8389,8392,8410,8414,8417,8420,8437,8440,8443,8446,8451,8453,8458,8461,8478,8482,8485,8505,8508,8511,8514,8528,8531,8546,8549,8553,8559,8562,8568,8571,8583,8586,8589,8593,8596,8604,8607,8615,8618,8632,8636,8640,8642,8656,8660,8662,8676,8680,8682,8696,8699,8719,8723,8726,8735,8738,8747,8750,8759,8762,8771,8774,8782,8785,8800,8811,8814,8822,8825,8827,8831,8834,8838,8841,8849,8853,8856,8860,8863,8867,8870,8874,8877,8879,8916],[14,7541,16],{"id":16},[18,7543,7544],{},"MySQL InnoDB 支持四种事务隔离级别：读未提交、读已提交、可重复读和串行化。",[99,7546,7547,7553,7559,7578],{},[102,7548,7549,7552],{},[68,7550,7551],{},"读未提交（READ UNCOMMITTED）","：可能发生脏读、不可重复读和幻读。",[102,7554,7555,7558],{},[68,7556,7557],{},"读已提交（READ COMMITTED）","：只能读取已经提交的数据，但每次普通查询都会创建新的 Read View，因此可能发生不可重复读和幻读。",[102,7560,7561,7564,7565,5196,7568,5196,7571,1441,7574,7577],{},[68,7562,7563],{},"可重复读（REPEATABLE READ）","：MySQL InnoDB 的默认隔离级别。同一事务中的普通快照读复用第一次查询建立的 Read View，避免不可重复读，并通过一致性快照避免看到后来插入的幻影行；对于 ",[21,7566,7567],{},"SELECT ... FOR UPDATE",[21,7569,7570],{},"SELECT ... FOR SHARE",[21,7572,7573],{},"UPDATE",[21,7575,7576],{},"DELETE"," 等当前读，则通过 Next-Key Lock 锁住索引记录及其前面的间隙，阻止其他事务在查询范围内插入新记录。",[102,7579,7580,7583],{},[68,7581,7582],{},"串行化（SERIALIZABLE）","：隔离性最强，事务近似串行执行，可以避免脏读、不可重复读和幻读，但并发能力最低。",[18,7585,7586],{},"因此，回答“InnoDB 如何避免幻读”时，需要区分两类读取：",[708,7588,7589,7596],{},[102,7590,7591,7592,7595],{},"普通 ",[21,7593,7594],{},"SELECT"," 属于快照读，REPEATABLE READ 通过 MVCC 和同一个 Read View，让事务始终读取同一份一致性快照。",[102,7597,7598,7600],{},[21,7599,7567],{}," 等属于当前读，REPEATABLE READ 通过 Gap Lock 和 Next-Key Lock 阻止其他事务向锁定范围插入新记录。",[18,7602,7603],{},"如果业务逻辑是“先查询是否存在，再决定是否插入或更新”，仅依赖快照读通常不够，应在 REPEATABLE READ 下使用合适索引和锁定读，并通过唯一索引等数据库约束作为最终兜底。",[192,7605,7606],{"id":7606},"一句话总结",[63,7608,7609],{},[18,7610,7611],{},"InnoDB 默认使用 REPEATABLE READ：普通查询靠 MVCC 的一致性快照避免看见幻影行，当前读靠 Next-Key Lock 锁住记录和间隙，阻止幻影行被插入。",[14,7613,73],{"id":73},[18,7615,7616],{},[77,7617,7620],{"href":7618,"target":80,"rel":7619},"\u002Fimages\u002Fwiki\u002Fjava\u002Fmysql-transaction-isolation-and-phantom-read.svg",[82,83],[85,7621],{"src":7618,"alt":7622},"MySQL 四种事务隔离级别与 InnoDB 避免幻读的机制",[14,7624,90],{"id":90},[14,7626,7628],{"id":7627},"一事务隔离级别解决什么问题","一、事务隔离级别解决什么问题",[18,7630,7631],{},"多个事务并发执行时，一个事务的写入可能影响另一个事务的读取。隔离级别用于规定：",[63,7633,7634],{},[18,7635,7636],{},"一个事务能够看到其他事务的哪些修改，以及什么时候能够看到这些修改。",[18,7638,7639],{},"隔离级别越高，事务之间的影响越小，但加锁和等待通常越多，并发能力也可能越低。",[18,7641,7642],{},"MySQL InnoDB 支持 SQL 标准定义的四种隔离级别：",[341,7644,7645,7665],{},[344,7646,7647],{},[347,7648,7649,7652,7656,7659,7662],{},[350,7650,7651],{},"隔离级别",[350,7653,7655],{"align":7654},"right","脏读",[350,7657,7658],{"align":7654},"不可重复读",[350,7660,7661],{"align":7654},"幻读",[350,7663,7664],{"align":7654},"并发能力",[360,7666,7667,7682,7696,7710],{},[347,7668,7669,7672,7675,7677,7679],{},[365,7670,7671],{},"READ UNCOMMITTED",[365,7673,7674],{"align":7654},"可能",[365,7676,7674],{"align":7654},[365,7678,7674],{"align":7654},[365,7680,7681],{"align":7654},"最高",[347,7683,7684,7687,7690,7692,7694],{},[365,7685,7686],{},"READ COMMITTED",[365,7688,7689],{"align":7654},"避免",[365,7691,7674],{"align":7654},[365,7693,7674],{"align":7654},[365,7695,3315],{"align":7654},[347,7697,7698,7701,7703,7705,7708],{},[365,7699,7700],{},"REPEATABLE READ",[365,7702,7689],{"align":7654},[365,7704,7689],{"align":7654},[365,7706,7707],{"align":7654},"InnoDB 通过 MVCC 和 Next-Key Lock 处理",[365,7709,3315],{"align":7654},[347,7711,7712,7715,7717,7719,7721],{},[365,7713,7714],{},"SERIALIZABLE",[365,7716,7689],{"align":7654},[365,7718,7689],{"align":7654},[365,7720,7689],{"align":7654},[365,7722,7723],{"align":7654},"最低",[18,7725,4211],{},[63,7727,7728],{},[18,7729,7730],{},"“REPEATABLE READ 可能发生幻读”是 SQL 标准层面的常见结论；MySQL InnoDB 在该级别上又实现了 MVCC 和 Next-Key Lock，对快照读和当前读分别处理幻读问题。",[14,7732,7734],{"id":7733},"二三种并发读取问题","二、三种并发读取问题",[192,7736,7738],{"id":7737},"_1-脏读","1. 脏读",[18,7740,7741],{},"事务 A 读取了事务 B 尚未提交的数据。如果事务 B 最后回滚，事务 A 读到的就是从未真正生效的数据。",[118,7743,7746],{"className":7744,"code":7745,"language":123,"meta":124},[121],"事务 A 事务 B\n 修改余额 100 → 0\n读取余额，得到 0\n ROLLBACK\n",[21,7747,7745],{"__ignoreMap":124},[18,7749,7750,7751,7753],{},"这里的 ",[21,7752,1909],{}," 就是脏数据。",[192,7755,7757],{"id":7756},"_2-不可重复读","2. 不可重复读",[18,7759,7760],{},"同一事务两次读取同一行，得到的字段值不同。",[118,7762,7765],{"className":7763,"code":7764,"language":123,"meta":124},[121],"事务 A 事务 B\n读取 id=1，余额为 100\n 修改余额为 80\n COMMIT\n再次读取 id=1，余额为 80\n",[21,7766,7764],{"__ignoreMap":124},[18,7768,7769],{},"不可重复读关注的是：",[63,7771,7772],{},[18,7773,7774],{},"同一行记录的内容发生了变化。",[192,7776,7778],{"id":7777},"_3-幻读","3. 幻读",[18,7780,7781],{},"同一事务使用相同查询条件执行两次查询，第二次返回的结果集合中出现了第一次不存在的记录，或者原有记录消失。",[118,7783,7786],{"className":7784,"code":7785,"language":123,"meta":124},[121],"事务 A 事务 B\n查询 amount > 100，返回 3 行\n 插入一条 amount=150 的记录\n COMMIT\n再次查询 amount > 100，返回 4 行\n",[21,7787,7785],{"__ignoreMap":124},[18,7789,7790],{},"新增的第 4 行就是幻影行。",[18,7792,7793],{},"幻读关注的是：",[63,7795,7796],{},[18,7797,7798],{},"满足查询条件的记录集合发生了变化。",[18,7800,7801],{},"所以，不可重复读和幻读的区别可以记为：",[99,7803,7804,7807],{},[102,7805,7806],{},"不可重复读：同一行的值变了。",[102,7808,7809],{},"幻读：符合条件的行数或记录集合变了。",[14,7811,7813],{"id":7812},"三四种隔离级别","三、四种隔离级别",[192,7815,7817],{"id":7816},"_1-read-uncommitted读未提交","1. READ UNCOMMITTED：读未提交",[18,7819,7820],{},"事务可以读取其他事务尚未提交的修改，因此可能发生：",[99,7822,7823,7826,7829],{},[102,7824,7825],{},"脏读；",[102,7827,7828],{},"不可重复读；",[102,7830,7831],{},"幻读。",[18,7833,7834],{},"它的隔离性最低，实际业务系统很少使用。",[192,7836,7838],{"id":7837},"_2-read-committed读已提交","2. READ COMMITTED：读已提交",[18,7840,7841],{},"事务只能读取已经提交的数据，因此不会发生脏读。",[18,7843,7844],{},"但在 InnoDB 中，每一次普通一致性读都会创建一个新的 Read View：",[118,7846,7849],{"className":7847,"code":7848,"language":123,"meta":124},[121],"第一次 SELECT → Read View 1\n第二次 SELECT → Read View 2\n第三次 SELECT → Read View 3\n",[21,7850,7848],{"__ignoreMap":124},[18,7852,7853],{},"如果其他事务在两次查询之间提交了修改，后一次查询就可能看到新数据，因此可能发生：",[99,7855,7856,7858],{},[102,7857,7828],{},[102,7859,7831],{},[18,7861,7862,7863,1441,7865,7867],{},"另外，在 READ COMMITTED 下，锁定读、",[21,7864,7573],{},[21,7866,7576],{}," 通常只锁索引记录，不锁记录前面的间隙。除了外键约束检查和重复键检查等情况外，Gap Lock 被禁用，因此其他事务仍可能向间隙插入新记录。",[192,7869,7871],{"id":7870},"_3-repeatable-read可重复读","3. REPEATABLE READ：可重复读",[18,7873,7874],{},"这是 InnoDB 的默认隔离级别。",[18,7876,7877,7878,7880],{},"对于普通 ",[21,7879,7594],{},"，事务中的第一次一致性读会建立 Read View，之后的普通一致性读继续使用该快照：",[118,7882,7885],{"className":7883,"code":7884,"language":123,"meta":124},[121],"第一次普通 SELECT → 创建 Read View\n第二次普通 SELECT → 复用同一个 Read View\n第三次普通 SELECT → 复用同一个 Read View\n",[21,7886,7884],{"__ignoreMap":124},[18,7888,7889],{},"因此，其他事务之后提交的更新、删除或插入不会出现在当前事务的旧快照中。",[18,7891,7892],{},"对于锁定读和数据修改语句，InnoDB 会读取最新可用数据，并根据查询使用的索引范围加锁。范围条件通常会使用 Gap Lock 或 Next-Key Lock，阻止其他事务向被锁定的范围插入新记录。",[192,7894,7896],{"id":7895},"_4-serializable串行化","4. SERIALIZABLE：串行化",[18,7898,7899],{},"SERIALIZABLE 是隔离性最强的级别。",[18,7901,7902,7903,7905],{},"在关闭自动提交的情况下，InnoDB 会把普通 ",[21,7904,7594],{}," 隐式转换为共享锁定读，效果类似：",[118,7907,7911],{"className":7908,"code":7909,"language":7910,"meta":124,"style":124},"language-sql shiki shiki-themes github-light github-dark","SELECT ... FOR SHARE;\n","sql",[21,7912,7913],{"__ignoreMap":124},[142,7914,7915],{"class":144,"line":145},[142,7916,7909],{},[18,7918,7919],{},"这样事务之间会产生更多锁等待，能够避免脏读、不可重复读和幻读，但吞吐量通常明显下降。",[18,7921,7922],{},"它适合一致性要求极高、并发量较低，或者确实需要事务串行执行的场景。",[14,7924,7926],{"id":7925},"四快照读与当前读","四、快照读与当前读",[18,7928,7929],{},"理解 InnoDB 如何处理幻读，必须先区分快照读和当前读。",[192,7931,7933],{"id":7932},"_1-快照读","1. 快照读",[18,7935,7936,7937,7939],{},"在 READ COMMITTED 和 REPEATABLE READ 下，普通 ",[21,7938,7594],{}," 通常属于快照读：",[118,7941,7943],{"className":7908,"code":7942,"language":7910,"meta":124,"style":124},"SELECT * FROM orders WHERE amount BETWEEN 100 AND 200;\n",[21,7944,7945],{"__ignoreMap":124},[142,7946,7947],{"class":144,"line":145},[142,7948,7942],{},[18,7950,7951],{},"快照读：",[99,7953,7954,7957,7960],{},[102,7955,7956],{},"不对查询记录加行锁；",[102,7958,7959],{},"通过 MVCC 读取某个时间点的一致性数据；",[102,7961,7962],{},"其他事务可以继续修改、删除或插入数据。",[18,7964,7965],{},"REPEATABLE READ 下，同一事务中的普通快照读复用同一个 Read View，所以后来提交的记录对当前快照不可见。",[192,7967,7969],{"id":7968},"_2-当前读","2. 当前读",[18,7971,7972],{},"下面这些操作需要读取最新可用的数据，并对数据加锁：",[118,7974,7976],{"className":7908,"code":7975,"language":7910,"meta":124,"style":124},"SELECT ... FOR UPDATE;\nSELECT ... FOR SHARE;\nUPDATE ...;\nDELETE ...;\n",[21,7977,7978,7983,7987,7992],{"__ignoreMap":124},[142,7979,7980],{"class":144,"line":145},[142,7981,7982],{},"SELECT ... FOR UPDATE;\n",[142,7984,7985],{"class":144,"line":151},[142,7986,7909],{},[142,7988,7989],{"class":144,"line":157},[142,7990,7991],{},"UPDATE ...;\n",[142,7993,7994],{"class":144,"line":163},[142,7995,7996],{},"DELETE ...;\n",[18,7998,7999],{},"它们通常被称为当前读或锁定读。",[18,8001,8002],{},"当前读不能只依靠旧快照，因为业务接下来可能要修改数据。它必须在最新数据状态上进行判断，并锁住相关记录或范围，避免判断完成后数据立即被并发事务改变。",[14,8004,8006],{"id":8005},"五快照读如何避免幻读","五、快照读如何避免幻读",[18,8008,8009],{},"假设当前使用 REPEATABLE READ：",[118,8011,8013],{"className":7908,"code":8012,"language":7910,"meta":124,"style":124},"START TRANSACTION;\n\nSELECT * FROM orders\nWHERE amount BETWEEN 100 AND 200;\n",[21,8014,8015,8020,8024,8029],{"__ignoreMap":124},[142,8016,8017],{"class":144,"line":145},[142,8018,8019],{},"START TRANSACTION;\n",[142,8021,8022],{"class":144,"line":151},[142,8023,781],{"emptyLinePlaceholder":780},[142,8025,8026],{"class":144,"line":157},[142,8027,8028],{},"SELECT * FROM orders\n",[142,8030,8031],{"class":144,"line":163},[142,8032,8033],{},"WHERE amount BETWEEN 100 AND 200;\n",[18,8035,8036,8037,8040],{},"第一次普通查询建立 Read View。此后事务 B 插入一条 ",[21,8038,8039],{},"amount=150"," 的记录并提交：",[118,8042,8044],{"className":7908,"code":8043,"language":7910,"meta":124,"style":124},"INSERT INTO orders(user_id, amount)\nVALUES (10, 150);\n\nCOMMIT;\n",[21,8045,8046,8051,8056,8060],{"__ignoreMap":124},[142,8047,8048],{"class":144,"line":145},[142,8049,8050],{},"INSERT INTO orders(user_id, amount)\n",[142,8052,8053],{"class":144,"line":151},[142,8054,8055],{},"VALUES (10, 150);\n",[142,8057,8058],{"class":144,"line":157},[142,8059,781],{"emptyLinePlaceholder":780},[142,8061,8062],{"class":144,"line":163},[142,8063,8064],{},"COMMIT;\n",[18,8066,8067],{},"事务 A 再次执行相同的普通查询：",[118,8069,8071],{"className":7908,"code":8070,"language":7910,"meta":124,"style":124},"SELECT * FROM orders\nWHERE amount BETWEEN 100 AND 200;\n",[21,8072,8073,8077],{"__ignoreMap":124},[142,8074,8075],{"class":144,"line":145},[142,8076,8028],{},[142,8078,8079],{"class":144,"line":151},[142,8080,8033],{},[18,8082,8083],{},"由于事务 A 仍然使用原来的 Read View，新插入的记录不在该快照的可见范围内，因此第二次查询不会看到它。",[18,8085,8086],{},"这里需要准确理解：",[63,8088,8089],{},[18,8090,8091],{},"MVCC 没有阻止事务 B 插入记录，只是让这条后来提交的记录对事务 A 的旧快照不可见。",[18,8093,8094],{},"因此，快照读解决的是“当前事务看到什么”，而不是“其他事务能不能写入”。",[14,8096,8098],{"id":8097},"六当前读如何避免幻读","六、当前读如何避免幻读",[18,8100,8101],{},"如果业务需要先锁定一个范围，再根据查询结果修改数据，可以使用：",[118,8103,8105],{"className":7908,"code":8104,"language":7910,"meta":124,"style":124},"START TRANSACTION;\n\nSELECT * FROM orders\nWHERE amount BETWEEN 100 AND 200\nFOR UPDATE;\n",[21,8106,8107,8111,8115,8119,8124],{"__ignoreMap":124},[142,8108,8109],{"class":144,"line":145},[142,8110,8019],{},[142,8112,8113],{"class":144,"line":151},[142,8114,781],{"emptyLinePlaceholder":780},[142,8116,8117],{"class":144,"line":157},[142,8118,8028],{},[142,8120,8121],{"class":144,"line":163},[142,8122,8123],{},"WHERE amount BETWEEN 100 AND 200\n",[142,8125,8126],{"class":144,"line":169},[142,8127,8128],{},"FOR UPDATE;\n",[18,8130,8131,8132,8135],{},"假设 ",[21,8133,8134],{},"amount"," 上存在普通索引：",[118,8137,8139],{"className":7908,"code":8138,"language":7910,"meta":124,"style":124},"CREATE INDEX idx_orders_amount ON orders(amount);\n",[21,8140,8141],{"__ignoreMap":124},[142,8142,8143],{"class":144,"line":145},[142,8144,8138],{},[18,8146,8147],{},"在 REPEATABLE READ 下，InnoDB 扫描这个索引范围时，通常会对索引记录及其间隙加 Next-Key Lock。",[18,8149,8150],{},"此时另一个事务尝试插入：",[118,8152,8154],{"className":7908,"code":8153,"language":7910,"meta":124,"style":124},"INSERT INTO orders(user_id, amount)\nVALUES (10, 150);\n",[21,8155,8156,8160],{"__ignoreMap":124},[142,8157,8158],{"class":144,"line":145},[142,8159,8050],{},[142,8161,8162],{"class":144,"line":151},[142,8163,8055],{},[18,8165,8166,8167,8170],{},"由于 ",[21,8168,8169],{},"150"," 落在已经锁定的索引范围内，该插入通常会被阻塞，直到前一个事务提交或回滚。",[18,8172,8173],{},"这次不是“让新记录不可见”，而是：",[63,8175,8176],{},[18,8177,8178],{},"阻止新记录进入已经锁定的查询范围。",[14,8180,8182],{"id":8181},"七record-lockgap-lock-与-next-key-lock","七、Record Lock、Gap Lock 与 Next-Key Lock",[192,8184,8186],{"id":8185},"_1-record-lock","1. Record Lock",[18,8188,8189],{},"Record Lock 锁住的是索引记录。",[18,8191,1263],{},[118,8193,8195],{"className":7908,"code":8194,"language":7910,"meta":124,"style":124},"SELECT * FROM orders\nWHERE id = 100\nFOR UPDATE;\n",[21,8196,8197,8201,8206],{"__ignoreMap":124},[142,8198,8199],{"class":144,"line":145},[142,8200,8028],{},[142,8202,8203],{"class":144,"line":151},[142,8204,8205],{},"WHERE id = 100\n",[142,8207,8208],{"class":144,"line":157},[142,8209,8128],{},[18,8211,3660,8212,8215],{},[21,8213,8214],{},"id"," 是唯一索引，并且使用唯一等值条件准确定位一条记录，InnoDB 通常只锁找到的索引记录，不需要锁前面的间隙。",[192,8217,8219],{"id":8218},"_2-gap-lock","2. Gap Lock",[18,8221,8222],{},"Gap Lock 锁住的是两个索引记录之间的间隙，而不是某一条已经存在的记录。",[18,8224,8225],{},"假设索引中已有：",[118,8227,8230],{"className":8228,"code":8229,"language":123,"meta":124},[121],"100\n200\n300\n",[21,8231,8229],{"__ignoreMap":124},[18,8233,8234],{},"那么其中存在：",[118,8236,8239],{"className":8237,"code":8238,"language":123,"meta":124},[121],"(-∞, 100)\n(100, 200)\n(200, 300)\n(300, +∞)\n",[21,8240,8238],{"__ignoreMap":124},[18,8242,8243],{},"Gap Lock 的主要作用是限制其他事务在对应间隙插入新索引记录。",[192,8245,8247],{"id":8246},"_3-next-key-lock","3. Next-Key Lock",[18,8249,8250],{},"Next-Key Lock 的准确定义是：",[118,8252,8255],{"className":8253,"code":8254,"language":123,"meta":124},[121],"Next-Key Lock = Record Lock + 该记录前面的 Gap Lock\n",[21,8256,8254],{"__ignoreMap":124},[18,8258,8259],{},"这里的“前面”是指索引排序中的前一个间隙。假设索引值为：",[118,8261,8264],{"className":8262,"code":8263,"language":123,"meta":124},[121],"3\n5\n8\n",[21,8265,8263],{"__ignoreMap":124},[18,8267,8268],{},"可能形成的 Next-Key Lock 区间是：",[118,8270,8273],{"className":8271,"code":8272,"language":123,"meta":124},[121],"(-∞, 3]\n(3, 5]\n(5, 8]\n(8, +∞)\n",[21,8274,8272],{"__ignoreMap":124},[18,8276,8277,8278,8281,8282,8285,8286,8288,8289,5705,8292,8294],{},"例如，对索引记录 ",[21,8279,8280],{},"5"," 加 Next-Key Lock，可以概念性地理解为锁住 ",[21,8283,8284],{},"(3, 5]","：既保护记录 ",[21,8287,8280],{},"，又阻止其他事务向 ",[21,8290,8291],{},"3",[21,8293,8280],{}," 之间插入新索引记录。",[18,8296,8297],{},"这里需要区分单个 Next-Key Lock 和一条 SQL 最终获得的整组锁：",[63,8299,8300],{},[18,8301,8302],{},"一个 Next-Key Lock 只包含当前记录和它前面的间隙，但一条 SQL 可能同时获得多个 Record Lock、Gap Lock 和 Next-Key Lock，最终覆盖查询记录前后的整个范围。",[18,8304,8305],{},"例如，在 REPEATABLE READ 下执行：",[118,8307,8309],{"className":7908,"code":8308,"language":7910,"meta":124,"style":124},"SELECT * FROM orders\nWHERE amount = 5\nFOR UPDATE;\n",[21,8310,8311,8315,8320],{"__ignoreMap":124},[142,8312,8313],{"class":144,"line":145},[142,8314,8028],{},[142,8316,8317],{"class":144,"line":151},[142,8318,8319],{},"WHERE amount = 5\n",[142,8321,8322],{"class":144,"line":157},[142,8323,8128],{},[18,8325,3660,8326,8328,8329,8332,8333,8336],{},[21,8327,8134],{}," 是普通非唯一索引，并且相邻索引值为 ",[21,8330,8331],{},"3、5、8","，为了防止其他事务再次插入 ",[21,8334,8335],{},"amount=5"," 的记录，最终需要保护：",[118,8338,8341],{"className":8339,"code":8340,"language":123,"meta":124},[121],"记录 5\n记录 5 前面的间隙：(3, 5)\n记录 5 后面的间隙：(5, 8)\n",[21,8342,8340],{"__ignoreMap":124},[18,8344,8345],{},"可以概念性地理解为：",[118,8347,8350],{"className":8348,"code":8349,"language":123,"meta":124},[121],"(3, 5] → 记录 5 的 Next-Key Lock\n(5, 8) → 查询范围结束位置的 Gap Lock\n",[21,8351,8349],{"__ignoreMap":124},[18,8353,8354],{},"所以，“等值查询可能锁住匹配记录及其前后间隙”是对一条 SQL 最终锁定范围的描述；它不代表单个 Next-Key Lock 同时包含记录前后两个间隙。",[18,8356,8357],{},"还要区分以下情况：",[99,8359,8360,8365,8376,8379],{},[102,8361,7591,8362,8364],{},[21,8363,7594],{}," 是快照读，不会因为这个查询条件加 Next-Key Lock。",[102,8366,8367,5196,8369,5196,8371,1441,8373,8375],{},[21,8368,7567],{},[21,8370,7570],{},[21,8372,7573],{},[21,8374,7576],{}," 才属于锁定读或当前读。",[102,8377,8378],{},"如果使用唯一索引和唯一等值条件，并且准确找到已有记录，InnoDB 通常只加 Record Lock，不需要锁前后间隙。",[102,8380,8381],{},"如果查询条件没有命中唯一记录，或者使用普通非唯一索引，InnoDB 会根据实际扫描范围使用 Gap Lock 或 Next-Key Lock。",[18,8383,8384,8385,8388],{},"具体获得哪些锁，最终还取决于隔离级别、索引类型、查询条件和实际执行计划，不能只根据 ",[21,8386,8387],{},"WHERE"," 条件判断。",[18,8390,8391],{},"InnoDB 还可以锁住最后一条记录之后的间隙，从而保护开放区间查询：",[118,8393,8395],{"className":7908,"code":8394,"language":7910,"meta":124,"style":124},"SELECT * FROM orders\nWHERE amount > 200\nFOR UPDATE;\n",[21,8396,8397,8401,8406],{"__ignoreMap":124},[142,8398,8399],{"class":144,"line":145},[142,8400,8028],{},[142,8402,8403],{"class":144,"line":151},[142,8404,8405],{},"WHERE amount > 200\n",[142,8407,8408],{"class":144,"line":157},[142,8409,8128],{},[14,8411,8413],{"id":8412},"八索引为什么很重要","八、索引为什么很重要",[18,8415,8416],{},"InnoDB 的行锁本质上是索引记录锁，Next-Key Lock 也是围绕索引扫描范围建立的。",[18,8418,8419],{},"如果查询能够使用合适索引：",[118,8421,8423],{"className":7908,"code":8422,"language":7910,"meta":124,"style":124},"SELECT * FROM orders\nWHERE amount BETWEEN 100 AND 200\nFOR UPDATE;\n",[21,8424,8425,8429,8433],{"__ignoreMap":124},[142,8426,8427],{"class":144,"line":145},[142,8428,8028],{},[142,8430,8431],{"class":144,"line":151},[142,8432,8123],{},[142,8434,8435],{"class":144,"line":157},[142,8436,8128],{},[18,8438,8439],{},"InnoDB 可以更准确地锁定相关索引范围。",[18,8441,8442],{},"如果缺少合适索引，InnoDB 可能需要扫描并锁定大量索引记录，锁的范围会变大，并发能力明显下降。",[18,8444,8445],{},"这里不要简单表述为：",[63,8447,8448],{},[18,8449,8450],{},"没有索引就一定加表锁。",[18,8452,2164],{},[63,8454,8455],{},[18,8456,8457],{},"InnoDB 仍然基于索引记录加锁；缺少可用业务索引时，可能扫描并锁住大量记录，使效果接近大范围锁定。",[18,8459,8460],{},"因此，使用锁定读避免幻读时，需要同时关注：",[99,8462,8463,8466,8469,8472,8475],{},[102,8464,8465],{},"查询条件是否命中索引；",[102,8467,8468],{},"实际执行计划选择了哪个索引；",[102,8470,8471],{},"锁定范围是否超出预期；",[102,8473,8474],{},"事务是否足够短；",[102,8476,8477],{},"是否可能形成死锁。",[14,8479,8481],{"id":8480},"九为什么不能只依赖快照读完成先查后写","九、为什么不能只依赖快照读完成“先查后写”",[18,8483,8484],{},"假设业务要求同一用户只能存在一条有效申请：",[118,8486,8488],{"className":7908,"code":8487,"language":7910,"meta":124,"style":124},"SELECT * FROM applications\nWHERE user_id = 100\n AND status = 'ACTIVE';\n",[21,8489,8490,8495,8500],{"__ignoreMap":124},[142,8491,8492],{"class":144,"line":145},[142,8493,8494],{},"SELECT * FROM applications\n",[142,8496,8497],{"class":144,"line":151},[142,8498,8499],{},"WHERE user_id = 100\n",[142,8501,8502],{"class":144,"line":157},[142,8503,8504],{}," AND status = 'ACTIVE';\n",[18,8506,8507],{},"两个事务可能同时通过快照读发现“记录不存在”，然后各自插入一条有效申请。",[18,8509,8510],{},"REPEATABLE READ 虽然让两个事务各自的查询结果保持一致，但没有阻止另一个事务执行插入。",[18,8512,8513],{},"因此，业务不变量不能只依赖普通快照读。常见方案是：",[708,8515,8516,8519,8522,8525],{},[102,8517,8518],{},"建立能够表达业务规则的唯一索引；",[102,8520,8521],{},"在 REPEATABLE READ 下使用合适的锁定读；",[102,8523,8524],{},"捕获重复键或死锁异常，并进行有限重试；",[102,8526,8527],{},"缩短事务时间，避免锁范围长期占用。",[18,8529,8530],{},"例如业务规则能够转换为唯一键时，优先让数据库约束兜底：",[118,8532,8534],{"className":7908,"code":8533,"language":7910,"meta":124,"style":124},"CREATE UNIQUE INDEX uk_user_active\nON applications(user_id, active_flag);\n",[21,8535,8536,8541],{"__ignoreMap":124},[142,8537,8538],{"class":144,"line":145},[142,8539,8540],{},"CREATE UNIQUE INDEX uk_user_active\n",[142,8542,8543],{"class":144,"line":151},[142,8544,8545],{},"ON applications(user_id, active_flag);\n",[18,8547,8548],{},"具体索引设计仍要根据数据模型确定，不能为了唯一约束直接照搬示例。",[14,8550,8552],{"id":8551},"十混用快照读和当前读为什么容易困惑","十、混用快照读和当前读为什么容易困惑",[18,8554,8555,8556,8558],{},"在 REPEATABLE READ 事务中，普通 ",[21,8557,7594],{}," 使用旧快照，而锁定读读取最新可用的数据。",[18,8560,8561],{},"可能出现：",[118,8563,8566],{"className":8564,"code":8565,"language":123,"meta":124},[121],"1. 普通 SELECT 没看到某条新记录\n2. 另一个事务插入该记录并提交\n3. SELECT ... FOR UPDATE 却看到了这条记录\n",[21,8567,8565],{"__ignoreMap":124},[18,8569,8570],{},"原因不是隔离级别突然失效，而是两条语句使用了不同的读取机制：",[99,8572,8573,8578],{},[102,8574,7591,8575,8577],{},[21,8576,7594],{},"：读取 Read View 中的一致性快照；",[102,8579,8580,8582],{},[21,8581,7567],{},"：读取最新可用数据并加锁。",[18,8584,8585],{},"MySQL 官方文档也不建议在同一个 REPEATABLE READ 事务中随意混用锁定语句和非锁定查询，因为它们可能呈现两个不同时间状态的数据。",[18,8587,8588],{},"如果业务必须基于最新结果做写入判断，应统一使用锁定读；如果必须获得更严格、容易理解的串行语义，可以评估 SERIALIZABLE，但要接受更高的锁竞争。",[14,8590,8592],{"id":8591},"十一read-committed-下加-for-update-能否避免幻读","十一、READ COMMITTED 下加 FOR UPDATE 能否避免幻读",[18,8594,8595],{},"不能笼统地说可以。",[18,8597,8598,8599,1441,8601,8603],{},"在 READ COMMITTED 下，InnoDB 对锁定读、",[21,8600,7573],{},[21,8602,7576],{}," 通常只锁索引记录，不锁前面的间隙。其他事务仍可以向记录间隙插入新行，因此范围查询仍可能出现幻读。",[18,8605,8606],{},"Gap Lock 在该级别主要保留给：",[99,8608,8609,8612],{},[102,8610,8611],{},"外键约束检查；",[102,8613,8614],{},"重复键检查。",[18,8616,8617],{},"如果业务需要锁住一个尚不存在的范围，应评估：",[99,8619,8620,8623,8626,8629],{},[102,8621,8622],{},"使用 REPEATABLE READ，并通过合适索引和 Next-Key Lock 锁定范围；",[102,8624,8625],{},"使用 SERIALIZABLE；",[102,8627,8628],{},"把业务不变量转换为唯一约束；",[102,8630,8631],{},"调整数据模型，避免依赖无法锁定的“空结果”。",[14,8633,8635],{"id":8634},"十二如何选择隔离级别","十二、如何选择隔离级别",[192,8637,8639],{"id":8638},"选择-read-committed","选择 READ COMMITTED",[18,8641,3730],{},[99,8643,8644,8647,8650,8653],{},[102,8645,8646],{},"希望每次查询都看到最新已提交数据；",[102,8648,8649],{},"可以接受同一事务内两次读取结果不同；",[102,8651,8652],{},"希望减少 Gap Lock 和锁冲突；",[102,8654,8655],{},"业务通过版本号、唯一约束或其他机制保证并发正确性。",[192,8657,8659],{"id":8658},"选择-repeatable-read","选择 REPEATABLE READ",[18,8661,3730],{},[99,8663,8664,8667,8670,8673],{},[102,8665,8666],{},"希望事务中的普通查询保持一致视图；",[102,8668,8669],{},"需要使用 Next-Key Lock 保护范围；",[102,8671,8672],{},"能够控制索引、锁顺序和事务时长；",[102,8674,8675],{},"接受 InnoDB 默认隔离级别。",[192,8677,8679],{"id":8678},"选择-serializable","选择 SERIALIZABLE",[18,8681,3730],{},[99,8683,8684,8687,8690,8693],{},[102,8685,8686],{},"并发量较低；",[102,8688,8689],{},"一致性要求极高；",[102,8691,8692],{},"业务逻辑难以通过更细粒度约束实现；",[102,8694,8695],{},"能够接受更多阻塞、超时和死锁重试。",[18,8697,8698],{},"隔离级别不是越高越好。选择时需要综合评估：",[99,8700,8701,8704,8707,8710,8713,8716],{},[102,8702,8703],{},"一致性要求；",[102,8705,8706],{},"读写比例；",[102,8708,8709],{},"热点数据；",[102,8711,8712],{},"事务持续时间；",[102,8714,8715],{},"可接受的锁等待；",[102,8717,8718],{},"数据库吞吐量。",[14,8720,8722],{"id":8721},"十三查看和设置隔离级别","十三、查看和设置隔离级别",[18,8724,8725],{},"查看当前会话隔离级别：",[118,8727,8729],{"className":7908,"code":8728,"language":7910,"meta":124,"style":124},"SELECT @@SESSION.transaction_isolation;\n",[21,8730,8731],{"__ignoreMap":124},[142,8732,8733],{"class":144,"line":145},[142,8734,8728],{},[18,8736,8737],{},"查看全局默认隔离级别：",[118,8739,8741],{"className":7908,"code":8740,"language":7910,"meta":124,"style":124},"SELECT @@GLOBAL.transaction_isolation;\n",[21,8742,8743],{"__ignoreMap":124},[142,8744,8745],{"class":144,"line":145},[142,8746,8740],{},[18,8748,8749],{},"修改当前会话后续事务的隔离级别：",[118,8751,8753],{"className":7908,"code":8752,"language":7910,"meta":124,"style":124},"SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;\n",[21,8754,8755],{"__ignoreMap":124},[142,8756,8757],{"class":144,"line":145},[142,8758,8752],{},[18,8760,8761],{},"设置下一个事务的隔离级别：",[118,8763,8765],{"className":7908,"code":8764,"language":7910,"meta":124,"style":124},"SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;\n",[21,8766,8767],{"__ignoreMap":124},[142,8768,8769],{"class":144,"line":145},[142,8770,8764],{},[18,8772,8773],{},"开始事务：",[118,8775,8776],{"className":7908,"code":8019,"language":7910,"meta":124,"style":124},[21,8777,8778],{"__ignoreMap":124},[142,8779,8780],{"class":144,"line":145},[142,8781,8019],{},[18,8783,8784],{},"线上修改隔离级别前，需要：",[99,8786,8787,8790,8797],{},[102,8788,8789],{},"验证依赖一致性快照、锁定范围和“先查后写”的业务逻辑；",[102,8791,8792,8793,8796],{},"确认 ",[21,8794,8795],{},"binlog_format"," 与目标隔离级别兼容；",[102,8798,8799],{},"观察切换前后的锁等待、死锁率、事务时延和数据库吞吐量。",[18,8801,8802,8803,8806,8807,8810],{},"这里需要确认的不是笼统的“复制方式”，而是二进制日志格式的兼容性。例如 MySQL 的 READ COMMITTED 只支持 Row-Based Logging；如果配置为 ",[21,8804,8805],{},"MIXED","，MySQL 会自动使用行格式记录。系统原本已经使用 ",[21,8808,8809],{},"ROW"," 时，通常不需要为此额外调整。",[18,8812,8813],{},"监控指标也不是选择隔离级别的前置条件，而是用于验证切换产生的实际影响：",[99,8815,8816,8819],{},[102,8817,8818],{},"从 REPEATABLE READ 切换到 READ COMMITTED，Gap Lock 通常减少，锁等待和死锁概率可能下降，但业务会失去事务级固定快照；",[102,8820,8821],{},"切换到更高隔离级别时，锁范围和等待时间可能增加，事务耗时及吞吐量可能受到影响。",[18,8823,8824],{},"因此，不能只根据理论吞吐量直接切换隔离级别。",[14,8826,3893],{"id":3892},[192,8828,8830],{"id":8829},"误区-1mvcc-会阻止其他事务插入","误区 1：MVCC 会阻止其他事务插入",[18,8832,8833],{},"不会。MVCC 主要决定一条记录对当前 Read View 是否可见，不会因为快照读而阻塞其他事务写入。",[192,8835,8837],{"id":8836},"误区-2repeatable-read-只靠-mvcc-避免所有幻读","误区 2：REPEATABLE READ 只靠 MVCC 避免所有幻读",[18,8839,8840],{},"不完整。",[99,8842,8843,8846],{},[102,8844,8845],{},"快照读靠 MVCC 和固定 Read View；",[102,8847,8848],{},"当前读靠 Gap Lock 和 Next-Key Lock。",[192,8850,8852],{"id":8851},"误区-3只要加-for-update-就一定不会幻读","误区 3：只要加 FOR UPDATE 就一定不会幻读",[18,8854,8855],{},"不一定。是否锁住间隙与隔离级别、查询条件、索引类型和实际扫描范围有关。READ COMMITTED 下通常不会为普通范围查询使用 Gap Lock。",[192,8857,8859],{"id":8858},"误区-4next-key-lock-锁的是数据页","误区 4：Next-Key Lock 锁的是数据页",[18,8861,8862],{},"不是。它围绕索引记录和索引记录之间的间隙建立。",[192,8864,8866],{"id":8865},"误区-5没有索引就一定升级为表锁","误区 5：没有索引就一定升级为表锁",[18,8868,8869],{},"这个表述不准确。InnoDB 仍然基于索引进行记录锁定，但缺少合适索引可能导致扫描和锁定大量记录，使并发效果接近大范围锁定。",[192,8871,8873],{"id":8872},"误区-6serializable-一定是最好的选择","误区 6：SERIALIZABLE 一定是最好的选择",[18,8875,8876],{},"它的隔离性最强，但会显著增加锁等待，降低并发能力。多数业务更适合通过合理隔离级别、索引、锁定读和数据库约束共同保证正确性。",[14,8878,1570],{"id":1570},[99,8880,8881,8888,8895,8902,8909],{},[102,8882,8883],{},[77,8884,8887],{"href":8885,"rel":8886},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-transaction-isolation-levels.html",[1579],"MySQL 8.4 Reference Manual：Transaction Isolation Levels",[102,8889,8890],{},[77,8891,8894],{"href":8892,"rel":8893},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-consistent-read.html",[1579],"MySQL 8.4 Reference Manual：Consistent Nonlocking Reads",[102,8896,8897],{},[77,8898,8901],{"href":8899,"rel":8900},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-next-key-locking.html",[1579],"MySQL 8.4 Reference Manual：Phantom Rows",[102,8903,8904],{},[77,8905,8908],{"href":8906,"rel":8907},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-locking-reads.html",[1579],"MySQL 8.4 Reference Manual：Locking Reads",[102,8910,8911],{},[77,8912,8915],{"href":8913,"rel":8914},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Fset-transaction.html",[1579],"MySQL 8.4 Reference Manual：SET TRANSACTION Statement",[1596,8917,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":8919},[8920,8923,8924,8925,8926,8931,8937,8941,8942,8943,8948,8949,8950,8951,8952,8957,8958,8966],{"id":16,"depth":151,"text":16,"children":8921},[8922],{"id":7606,"depth":157,"text":7606},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":7627,"depth":151,"text":7628},{"id":7733,"depth":151,"text":7734,"children":8927},[8928,8929,8930],{"id":7737,"depth":157,"text":7738},{"id":7756,"depth":157,"text":7757},{"id":7777,"depth":157,"text":7778},{"id":7812,"depth":151,"text":7813,"children":8932},[8933,8934,8935,8936],{"id":7816,"depth":157,"text":7817},{"id":7837,"depth":157,"text":7838},{"id":7870,"depth":157,"text":7871},{"id":7895,"depth":157,"text":7896},{"id":7925,"depth":151,"text":7926,"children":8938},[8939,8940],{"id":7932,"depth":157,"text":7933},{"id":7968,"depth":157,"text":7969},{"id":8005,"depth":151,"text":8006},{"id":8097,"depth":151,"text":8098},{"id":8181,"depth":151,"text":8182,"children":8944},[8945,8946,8947],{"id":8185,"depth":157,"text":8186},{"id":8218,"depth":157,"text":8219},{"id":8246,"depth":157,"text":8247},{"id":8412,"depth":151,"text":8413},{"id":8480,"depth":151,"text":8481},{"id":8551,"depth":151,"text":8552},{"id":8591,"depth":151,"text":8592},{"id":8634,"depth":151,"text":8635,"children":8953},[8954,8955,8956],{"id":8638,"depth":157,"text":8639},{"id":8658,"depth":157,"text":8659},{"id":8678,"depth":157,"text":8679},{"id":8721,"depth":151,"text":8722},{"id":3892,"depth":151,"text":3893,"children":8959},[8960,8961,8962,8963,8964,8965],{"id":8829,"depth":157,"text":8830},{"id":8836,"depth":157,"text":8837},{"id":8851,"depth":157,"text":8852},{"id":8858,"depth":157,"text":8859},{"id":8865,"depth":157,"text":8866},{"id":8872,"depth":157,"text":8873},{"id":1570,"depth":151,"text":1570},"wiki:java:mysql-transaction-isolation-and-phantom-read","梳理 MySQL InnoDB 的四种事务隔离级别，解释脏读、不可重复读和幻读，并说明 MVCC、Read View、Gap Lock 与 Next-Key Lock 如何共同避免幻读。",{},75,"\u002Fjava\u002Fmysql-transaction-isolation-and-phantom-read",{"title":7537,"description":8968},"java\u002Fmysql-transaction-isolation-and-phantom-read","sTjUvqr3aDsCis_rj0ygbjCxuvyf9jFgLpnBBrvGgZw",{"id":8976,"title":8977,"body":8978,"commentId":10010,"description":10011,"difficulty":3063,"draft":1646,"extension":1647,"meta":10012,"navigation":780,"order":10013,"path":10014,"section":1651,"seo":10015,"stem":10016,"updated":10017,"__hash__":10018},"java\u002Fjava\u002Fmysql-bplus-tree-vs-btree.md","MySQL 为何采用 B+ 树？B+ 树与 B 树的区别是什么？",{"type":7,"value":8979,"toc":9979},[8980,8982,8985,8988,9002,9005,9008,9010,9015,9017,9026,9028,9032,9039,9059,9062,9064,9078,9082,9085,9088,9091,9097,9100,9117,9124,9128,9131,9134,9140,9143,9159,9162,9176,9180,9284,9287,9290,9294,9297,9300,9303,9309,9312,9319,9324,9328,9333,9336,9341,9344,9350,9353,9359,9362,9368,9371,9375,9378,9381,9387,9390,9393,9396,9402,9405,9411,9414,9419,9428,9432,9435,9455,9462,9468,9471,9477,9480,9483,9528,9531,9535,9538,9541,9547,9550,9557,9561,9564,9572,9575,9578,9603,9606,9609,9626,9629,9632,9636,9639,9642,9657,9660,9666,9669,9678,9681,9684,9688,9691,9697,9700,9709,9712,9732,9737,9743,9746,9749,9767,9770,9779,9783,9786,9789,9795,9798,9801,9805,9808,9825,9828,9832,9835,9838,9844,9847,9850,9864,9867,9871,9875,9878,9882,9885,9889,9892,9896,9899,9903,9914,9918,9921,9927,9933,9938,9940,9977],[14,8981,16],{"id":16},[18,8983,8984],{},"MySQL InnoDB 的普通索引采用通常所说的 B+ 树结构，核心原因是数据库索引需要同时兼顾磁盘或页访问次数、等值查询、范围查询和顺序遍历。",[18,8986,8987],{},"B+ 树与 B 树的主要区别是：",[99,8989,8990,8993,8996,8999],{},[102,8991,8992],{},"B 树的非叶子节点和叶子节点都可以保存数据记录；",[102,8994,8995],{},"B+ 树的非叶子节点主要保存索引键和子页面指针，完整索引记录集中在叶子节点；",[102,8997,8998],{},"B+ 树的叶子节点按照键值顺序连接，适合范围扫描；",[102,9000,9001],{},"由于非叶子节点不保存完整数据，同样大小的页面能够容纳更多目录项，树的扇出更大、高度更低。",[18,9003,9004],{},"InnoDB 默认索引页大小为 16KB。一次读取通常以页为单位，而不是只读取一个键。B+ 树通过较大的扇出，把大量数据组织在较少的层级中，查询通常只需要访问少量页面；定位到范围起点后，还可以沿叶子页顺序扫描，不必反复从根节点查找。",[18,9006,9007],{},"InnoDB 的聚簇索引叶子节点保存完整行数据，二级索引叶子节点保存二级索引键和主键值。通过二级索引查询非覆盖列时，需要先取得主键，再回到聚簇索引查找完整行，这就是常说的回表。",[192,9009,7606],{"id":7606},[63,9011,9012],{},[18,9013,9014],{},"B+ 树让非叶子节点专注于导航，以更大的扇出降低树高，并把有序数据集中在相连的叶子节点中，因此既能减少页面访问，又适合范围查询和顺序扫描。",[14,9016,73],{"id":73},[18,9018,9019],{},[77,9020,9023],{"href":9021,"target":80,"rel":9022},"\u002Fimages\u002Fwiki\u002Fjava\u002Fmysql-btree-vs-bplus-tree.svg",[82,83],[85,9024],{"src":9021,"alt":9025},"B 树与 B+ 树结构对比",[14,9027,90],{"id":90},[14,9029,9031],{"id":9030},"一先明确mysql-文档中的-b-tree-与-b-树","一、先明确：MySQL 文档中的 B-tree 与 B+ 树",[18,9033,9034,9035,9038],{},"MySQL 官方文档通常把 InnoDB 的普通索引统称为 ",[21,9036,9037],{},"B-tree"," 索引。在数据库实现和面试语境中，InnoDB 的这种索引组织通常被称为 B+ 树：",[99,9040,9041,9044,9047,9050,9053,9056],{},[102,9042,9043],{},"索引记录存放在叶子页；",[102,9045,9046],{},"非叶子页负责索引导航；",[102,9048,9049],{},"聚簇索引的叶子页保存行数据；",[102,9051,9052],{},"二级索引的叶子记录保存索引列和主键；",[102,9054,9055],{},"InnoDB 同一层的索引页通过前后页指针双向连接；",[102,9057,9058],{},"叶子页中的索引记录有序，能够进行范围扫描。",[18,9060,9061],{},"因此，“MySQL 使用 B+ 树”通常是在描述 InnoDB 普通索引的具体组织特征；它不代表 MySQL 中所有索引都使用 B+ 树。",[18,9063,1263],{},[99,9065,9066,9069,9072,9075],{},[102,9067,9068],{},"InnoDB 普通索引使用 B-tree 类结构；",[102,9070,9071],{},"空间索引使用 R-tree；",[102,9073,9074],{},"全文索引有独立的倒排索引设计；",[102,9076,9077],{},"InnoDB 还可能使用自适应哈希索引加速部分热点等值访问。",[14,9079,9081],{"id":9080},"二b-树是什么","二、B 树是什么",[18,9083,9084],{},"B 树是一种多路平衡查找树。",[18,9086,9087],{},"“多路”表示一个节点可以拥有多个子节点，而不是像二叉查找树那样最多只有两个子节点。",[18,9089,9090],{},"一个简化的 B 树可以表示为：",[118,9092,9095],{"className":9093,"code":9094,"language":123,"meta":124},[121]," [20 | 50]\n \u002F | \\\n [5 | 10] [30 | 40] [60 | 80]\n",[21,9096,9094],{"__ignoreMap":124},[18,9098,9099],{},"B 树具有以下特点：",[99,9101,9102,9105,9108,9111,9114],{},[102,9103,9104],{},"节点中的键有序；",[102,9106,9107],{},"一个节点可以保存多个键和数据记录；",[102,9109,9110],{},"非叶子节点也可以直接保存数据；",[102,9112,9113],{},"所有叶子节点通常处于同一层；",[102,9115,9116],{},"插入和删除后通过分裂、合并或旋转维持平衡。",[18,9118,9119,9120,9123],{},"查询 ",[21,9121,9122],{},"20"," 时，可能在根节点直接找到数据，不一定需要访问叶子节点。",[14,9125,9127],{"id":9126},"三b-树是什么","三、B+ 树是什么",[18,9129,9130],{},"B+ 树也是多路平衡查找树，但它把导航结构和数据记录进一步分离。",[18,9132,9133],{},"一个简化的 B+ 树可以表示为：",[118,9135,9138],{"className":9136,"code":9137,"language":123,"meta":124},[121]," [20 | 50]\n \u002F | \\\n \u002F | \\\n [5 | 10 | 20] [30 | 40 | 50] [60 | 80]\n ↔ ↔\n 叶子页通过前后页指针双向连接\n",[21,9139,9137],{"__ignoreMap":124},[18,9141,9142],{},"B+ 树具有以下典型特点：",[99,9144,9145,9148,9151,9154,9156],{},[102,9146,9147],{},"非叶子节点主要保存键和子节点指针；",[102,9149,9150],{},"完整的数据记录集中在叶子节点；",[102,9152,9153],{},"所有查询最终都会到达叶子节点；",[102,9155,9055],{},[102,9157,9158],{},"适合从某个键开始连续读取一段数据。",[18,9160,9161],{},"需要注意，示意图中的分隔键可能同时出现在非叶子节点和叶子节点中。非叶子节点中的键用于导航，叶子节点中的索引记录才承载最终数据定位信息。",[18,9163,9164,9165,9168,9169,5196,9172,9175],{},"这里的双向链表连接的是",[68,9166,9167],{},"索引页","，并不是说整棵 B+ 树本身就是双向链表。整体结构仍然是一棵多路平衡树：树结构负责快速定位目标页；页面头中的 ",[21,9170,9171],{},"FIL_PAGE_PREV",[21,9173,9174],{},"FIL_PAGE_NEXT"," 字段保存前后页的页号，这些页号相当于逻辑指针，用于前后遍历。单个索引页内部的记录则主要按键值顺序组成单向链表，并由页目录辅助查找。",[14,9177,9179],{"id":9178},"四b-树与-b-树的核心区别","四、B 树与 B+ 树的核心区别",[341,9181,9182,9194],{},[344,9183,9184],{},[347,9185,9186,9188,9191],{},[350,9187,3182],{},[350,9189,9190],{},"B 树",[350,9192,9193],{},"B+ 树",[360,9195,9196,9207,9218,9229,9240,9251,9262,9273],{},[347,9197,9198,9201,9204],{},[365,9199,9200],{},"数据记录位置",[365,9202,9203],{},"非叶子节点和叶子节点都可以保存",[365,9205,9206],{},"完整索引记录集中在叶子节点",[347,9208,9209,9212,9215],{},[365,9210,9211],{},"非叶子节点职责",[365,9213,9214],{},"导航，同时可能保存数据",[365,9216,9217],{},"主要负责导航",[347,9219,9220,9223,9226],{},[365,9221,9222],{},"单个节点可容纳的键",[365,9224,9225],{},"相对较少",[365,9227,9228],{},"通常更多",[347,9230,9231,9234,9237],{},[365,9232,9233],{},"树的扇出",[365,9235,9236],{},"相对较小",[365,9238,9239],{},"通常更大",[347,9241,9242,9245,9248],{},[365,9243,9244],{},"树高",[365,9246,9247],{},"相同数据量下可能更高",[365,9249,9250],{},"相同数据量下通常更低",[347,9252,9253,9256,9259],{},[365,9254,9255],{},"等值查询",[365,9257,9258],{},"可能在非叶子节点提前结束",[365,9260,9261],{},"通常需要走到叶子节点",[347,9263,9264,9267,9270],{},[365,9265,9266],{},"范围查询",[365,9268,9269],{},"可能需要在树中多次定位",[365,9271,9272],{},"定位起点后可顺序扫描叶子节点",[347,9274,9275,9278,9281],{},[365,9276,9277],{},"查询路径",[365,9279,9280],{},"不同记录的结束层级可能不同",[365,9282,9283],{},"通常都到叶子层，路径更稳定",[18,9285,9286],{},"不能简单得出“B+ 树在所有场景都比 B 树快”的结论。",[18,9288,9289],{},"如果整个数据结构都在内存中，而且只做等值查询，B 树可能在非叶子节点提前命中。但数据库索引更关心页面访问、范围扫描和批量读取，B+ 树的整体特性更适合这类负载。",[14,9291,9293],{"id":9292},"五为什么数据库关心页面访问次数","五、为什么数据库关心页面访问次数",[18,9295,9296],{},"InnoDB 管理数据的基本单位是页，默认页面大小为 16KB。",[18,9298,9299],{},"查询一个索引键时，底层不是只从磁盘读取这个键对应的几个字节，而是把相关页面读入 Buffer Pool，再在页内查找。",[18,9301,9302],{},"因此，索引设计要尽量做到：",[118,9304,9307],{"className":9305,"code":9306,"language":123,"meta":124},[121],"更少的树层级\n ↓\n更少的页面访问\n ↓\n更低的 I\u002FO 和缓存查找成本\n",[21,9308,9306],{"__ignoreMap":124},[18,9310,9311],{},"即使相关页面已经在 Buffer Pool 中，查询仍然需要逐层定位索引页、在页内比较目录项，并在必要时获取页面 Latch。树高较低通常意味着遍历的页面更少，但此时节省的主要是内存中的索引导航成本，而不是磁盘 I\u002FO。",[18,9313,9314,9315,9318],{},"所以分析 B+ 树时，不应只背诵时间复杂度 ",[21,9316,9317],{},"O(log N)","，还要关注：",[63,9320,9321],{},[18,9322,9323],{},"这个对数以多大的扇出为底，以及一次查询需要访问多少个页面。",[14,9325,9327],{"id":9326},"六扇出是什么","六、扇出是什么",[18,9329,9330],{},[68,9331,9332],{},"扇出（Fan-out）是一个非叶子节点能够直接指向的子节点数量。",[18,9334,9335],{},"在 InnoDB 中，可以把它理解为：",[63,9337,9338],{},[18,9339,9340],{},"一个非叶子索引页能够直接导航到多少个下层索引页。",[18,9342,9343],{},"例如，某个非叶子页保存了大量“索引值 + 子页面指针”目录项，并能够据此导航到约 1,000 个子页面，那么可以近似地说这个节点的扇出约为 1,000。",[18,9345,9346,9347,52],{},"扇出不是整棵树的记录总数，也不是一个叶子页能够保存的行数。它描述的是",[68,9348,9349],{},"单个非叶子节点向下一层分出的分支数量",[18,9351,9352],{},"对于相同数量的数据，树高可以粗略理解为：",[118,9354,9357],{"className":9355,"code":9356,"language":123,"meta":124},[121],"树高 ≈ log(扇出)(需要管理的页面数)\n",[21,9358,9356],{"__ignoreMap":124},[18,9360,9361],{},"扇出越大，每增加一层能够覆盖的页面数增长得越快，因此管理相同数据量所需的层级通常越少：",[118,9363,9366],{"className":9364,"code":9365,"language":123,"meta":124},[121],"扇出为 2： 2 → 4 → 8 → 16\n扇出为 1,000： 1,000 → 1,000,000 → 1,000,000,000\n",[21,9367,9365],{"__ignoreMap":124},[18,9369,9370],{},"这里的数字只用于说明增长速度。真实扇出会受到索引键长度、页面格式、记录头、页面填充率等因素影响。",[14,9372,9374],{"id":9373},"七b-树如何通过更大的扇出降低树高","七、B+ 树如何通过更大的扇出降低树高",[18,9376,9377],{},"假设一个非叶子页既保存键，又保存完整行数据，那么每个目录项会比较大，一个页面能够容纳的目录项就比较少。",[18,9379,9380],{},"如果非叶子页只保存：",[118,9382,9385],{"className":9383,"code":9384,"language":123,"meta":124},[121],"索引键 + 子页面指针\n",[21,9386,9384],{"__ignoreMap":124},[18,9388,9389],{},"每个目录项更小，同一个 16KB 页面就能容纳更多目录项，一个节点可以指向更多子页面。",[18,9391,9392],{},"由于单个目录项更紧凑，同一个页面可以保存更多目录项、指向更多子页面，这就是 B+ 树扇出更大的原因。",[18,9394,9395],{},"例如，仅用于理解数量级，假设一个非叶子目录项平均占用 16 字节，忽略页头、槽目录、填充率和其他开销：",[118,9397,9400],{"className":9398,"code":9399,"language":123,"meta":124},[121],"16KB ÷ 16B ≈ 1024\n",[21,9401,9399],{"__ignoreMap":124},[18,9403,9404],{},"一个非叶子页理论上可以导航约一千个子页面：",[118,9406,9409],{"className":9407,"code":9408,"language":123,"meta":124},[121],"根节点：约 1,000 个分支\n第二层：约 1,000 × 1,000 个分支\n第三层：继续扩大\n",[21,9410,9408],{"__ignoreMap":124},[18,9412,9413],{},"真实容量会受到键长度、页格式、记录头、填充率等因素影响，不能直接按这个示例计算生产容量。但它能说明：",[63,9415,9416],{},[18,9417,9418],{},"多路树的扇出很大，少量层级就可以管理大量记录。",[18,9420,9421],{},[77,9422,9425],{"href":9423,"target":80,"rel":9424},"\u002Fimages\u002Fwiki\u002Fjava\u002Fmysql-bplus-tree-fanout.svg",[82,83],[85,9426],{"src":9423,"alt":9427},"B+ 树通过大扇出降低树高",[14,9429,9431],{"id":9430},"八为什么-b-树适合范围查询","八、为什么 B+ 树适合范围查询",[18,9433,9434],{},"假设执行：",[118,9436,9438],{"className":7908,"code":9437,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE id BETWEEN 1000 AND 2000;\n",[21,9439,9440,9445,9450],{"__ignoreMap":124},[142,9441,9442],{"class":144,"line":145},[142,9443,9444],{},"SELECT *\n",[142,9446,9447],{"class":144,"line":151},[142,9448,9449],{},"FROM orders\n",[142,9451,9452],{"class":144,"line":157},[142,9453,9454],{},"WHERE id BETWEEN 1000 AND 2000;\n",[18,9456,9457,9458,9461],{},"B+ 树可以先从根节点定位到 ",[21,9459,9460],{},"id=1000"," 附近的叶子页：",[118,9463,9466],{"className":9464,"code":9465,"language":123,"meta":124},[121],"根页\n ↓\n非叶子页\n ↓\n包含 1000 的叶子页\n",[21,9467,9465],{"__ignoreMap":124},[18,9469,9470],{},"定位范围起点以后，可以沿叶子页顺序扫描：",[118,9472,9475],{"className":9473,"code":9474,"language":123,"meta":124},[121],"[1000 ... 1200] ↔ [1201 ... 1500] ↔ [1501 ... 1800] ↔ [1801 ... 2000]\n",[21,9476,9474],{"__ignoreMap":124},[18,9478,9479],{},"不需要为范围中的每一条记录重新从根节点查找。",[18,9481,9482],{},"因此，B+ 树天然适合：",[99,9484,9485,9499,9504,9510,9516,9525],{},[102,9486,9487,5196,9490,5196,9493,5196,9496,1191],{},[21,9488,9489],{},">",[21,9491,9492],{},">=",[21,9494,9495],{},"\u003C",[21,9497,9498],{},"\u003C=",[102,9500,9501,1191],{},[21,9502,9503],{},"BETWEEN",[102,9505,9506,9507,1191],{},"有效前缀的 ",[21,9508,9509],{},"LIKE 'abc%'",[102,9511,9512,9513,1191],{},"按索引顺序执行的 ",[21,9514,9515],{},"ORDER BY",[102,9517,9518,9519,5196,9522,1191],{},"部分 ",[21,9520,9521],{},"MIN",[21,9523,9524],{},"MAX",[102,9526,9527],{},"范围扫描和顺序分页。",[18,9529,9530],{},"能否真正使用索引顺序，还取决于联合索引结构、最左前缀、排序方向和执行计划，不能因为底层是 B+ 树就认为所有范围条件都会高效。",[14,9532,9534],{"id":9533},"九为什么不用二叉查找树或红黑树","九、为什么不用二叉查找树或红黑树",[18,9536,9537],{},"二叉查找树和红黑树的扇出通常是 2。",[18,9539,9540],{},"即使红黑树能够保持近似平衡，管理大量数据时树高仍然明显高于多路树：",[118,9542,9545],{"className":9543,"code":9544,"language":123,"meta":124},[121],"二叉树：\n每个节点最多 2 个分支\n\nB+ 树：\n每个页面可以拥有数百甚至更多分支\n",[21,9546,9544],{"__ignoreMap":124},[18,9548,9549],{},"如果每层节点可能位于不同页面，树越高，查询可能需要访问的页面越多。",[18,9551,9552,9553,9556],{},"红黑树很适合内存中的集合和映射，例如 Java 的 ",[21,9554,9555],{},"TreeMap","；数据库索引需要尽量减少页面 I\u002FO，并支持大范围顺序扫描，因此多路 B+ 树更加合适。",[14,9558,9560],{"id":9559},"十为什么不直接使用哈希索引","十、为什么不直接使用哈希索引",[18,9562,9563],{},"哈希结构擅长等值查询：",[118,9565,9566],{"className":7908,"code":8205,"language":7910,"meta":124,"style":124},[21,9567,9568],{"__ignoreMap":124},[142,9569,9570],{"class":144,"line":145},[142,9571,8205],{},[18,9573,9574],{},"理想情况下可以根据哈希值直接定位桶。",[18,9576,9577],{},"但哈希值不保留原始键的顺序，因此不适合：",[118,9579,9581],{"className":7908,"code":9580,"language":7910,"meta":124,"style":124},"WHERE id > 100;\nWHERE id BETWEEN 100 AND 200;\nORDER BY id;\nLIKE 'abc%';\n",[21,9582,9583,9588,9593,9598],{"__ignoreMap":124},[142,9584,9585],{"class":144,"line":145},[142,9586,9587],{},"WHERE id > 100;\n",[142,9589,9590],{"class":144,"line":151},[142,9591,9592],{},"WHERE id BETWEEN 100 AND 200;\n",[142,9594,9595],{"class":144,"line":157},[142,9596,9597],{},"ORDER BY id;\n",[142,9599,9600],{"class":144,"line":163},[142,9601,9602],{},"LIKE 'abc%';\n",[18,9604,9605],{},"哈希索引还需要处理哈希冲突，也无法自然支持联合索引的有序最左前缀扫描。",[18,9607,9608],{},"B+ 树虽然等值查找通常需要沿树下降，但同时支持：",[99,9610,9611,9614,9617,9620,9623],{},[102,9612,9613],{},"等值查询；",[102,9615,9616],{},"范围查询；",[102,9618,9619],{},"顺序扫描；",[102,9621,9622],{},"排序；",[102,9624,9625],{},"联合索引前缀匹配。",[18,9627,9628],{},"因此它的通用性更强。",[18,9630,9631],{},"InnoDB 的自适应哈希索引可以为部分热点 B-tree 页面建立哈希访问路径，但它属于内部优化，不会替代原有 B+ 树索引。",[14,9633,9635],{"id":9634},"十一innodb-聚簇索引如何组织数据","十一、InnoDB 聚簇索引如何组织数据",[18,9637,9638],{},"每张 InnoDB 表都有一个聚簇索引。",[18,9640,9641],{},"聚簇索引的选择顺序通常是：",[708,9643,9644,9647,9654],{},[102,9645,9646],{},"显式定义的主键；",[102,9648,9649,9650,9653],{},"第一个所有列均为 ",[21,9651,9652],{},"NOT NULL"," 的唯一索引；",[102,9655,9656],{},"InnoDB 自动生成的隐藏行 ID。",[18,9658,9659],{},"聚簇索引可以简化为：",[118,9661,9664],{"className":9662,"code":9663,"language":123,"meta":124},[121],"非叶子节点：\n主键 + 子页面指针\n\n叶子节点：\n主键 + 完整行数据\n",[21,9665,9663],{"__ignoreMap":124},[18,9667,9668],{},"因此，通过主键查询：",[118,9670,9672],{"className":7908,"code":9671,"language":7910,"meta":124,"style":124},"SELECT * FROM users WHERE id = 100;\n",[21,9673,9674],{"__ignoreMap":124},[142,9675,9676],{"class":144,"line":145},[142,9677,9671],{},[18,9679,9680],{},"沿聚簇索引找到叶子记录时，通常已经取得了完整行数据。",[18,9682,9683],{},"这也是为什么官方文档把 InnoDB 表称为按聚簇索引组织的数据结构。",[14,9685,9687],{"id":9686},"十二innodb-二级索引如何组织数据","十二、InnoDB 二级索引如何组织数据",[18,9689,9690],{},"二级索引的叶子记录不直接保存完整行，而是保存：",[118,9692,9695],{"className":9693,"code":9694,"language":123,"meta":124},[121],"二级索引列 + 主键值\n",[21,9696,9694],{"__ignoreMap":124},[18,9698,9699],{},"假设存在：",[118,9701,9703],{"className":7908,"code":9702,"language":7910,"meta":124,"style":124},"CREATE INDEX idx_users_name ON users(name);\n",[21,9704,9705],{"__ignoreMap":124},[142,9706,9707],{"class":144,"line":145},[142,9708,9702],{},[18,9710,9711],{},"执行：",[118,9713,9715],{"className":7908,"code":9714,"language":7910,"meta":124,"style":124},"SELECT age\nFROM users\nWHERE name = 'Tom';\n",[21,9716,9717,9722,9727],{"__ignoreMap":124},[142,9718,9719],{"class":144,"line":145},[142,9720,9721],{},"SELECT age\n",[142,9723,9724],{"class":144,"line":151},[142,9725,9726],{},"FROM users\n",[142,9728,9729],{"class":144,"line":157},[142,9730,9731],{},"WHERE name = 'Tom';\n",[18,9733,3660,9734,9736],{},[21,9735,2059],{}," 不在二级索引中，查询过程通常是：",[118,9738,9741],{"className":9739,"code":9740,"language":123,"meta":124},[121],"idx_users_name B+ 树\n ↓\n找到 name='Tom' 对应的主键\n ↓\n回到聚簇索引 B+ 树\n ↓\n根据主键取得完整行和 age\n",[21,9742,9740],{"__ignoreMap":124},[18,9744,9745],{},"这就是回表。",[18,9747,9748],{},"如果查询所需列都能从二级索引叶子记录中取得：",[118,9750,9752],{"className":7908,"code":9751,"language":7910,"meta":124,"style":124},"SELECT id\nFROM users\nWHERE name = 'Tom';\n",[21,9753,9754,9759,9763],{"__ignoreMap":124},[142,9755,9756],{"class":144,"line":145},[142,9757,9758],{},"SELECT id\n",[142,9760,9761],{"class":144,"line":151},[142,9762,9726],{},[142,9764,9765],{"class":144,"line":157},[142,9766,9731],{},[18,9768,9769],{},"那么可能直接通过二级索引完成查询，不需要回到聚簇索引，这就是覆盖索引。",[18,9771,9772],{},[77,9773,9776],{"href":9774,"target":80,"rel":9775},"\u002Fimages\u002Fwiki\u002Fjava\u002Fmysql-innodb-index-lookup.svg",[82,83],[85,9777],{"src":9774,"alt":9778},"InnoDB 聚簇索引、二级索引与回表",[14,9780,9782],{"id":9781},"十三为什么主键不宜过长","十三、为什么主键不宜过长",[18,9784,9785],{},"InnoDB 的每条二级索引记录都包含主键值。",[18,9787,9788],{},"如果主键很长：",[118,9790,9793],{"className":9791,"code":9792,"language":123,"meta":124},[121],"每条二级索引记录更大\n ↓\n一个索引页容纳的记录更少\n ↓\n索引占用空间增加\n ↓\n缓存命中率和扇出可能下降\n",[21,9794,9792],{"__ignoreMap":124},[18,9796,9797],{},"因此，在满足业务要求的前提下，较短且稳定的主键通常更有利于 InnoDB 索引组织。",[18,9799,9800],{},"这并不意味着所有表都必须使用自增整数主键。是否采用自增 ID、分布式 ID 或业务主键，还要考虑写入热点、分库分表、数据合并和业务语义。",[14,9802,9804],{"id":9803},"十四叶子节点有序带来的其他收益","十四、叶子节点有序带来的其他收益",[18,9806,9807],{},"除了范围查询，叶子节点按键值有序还可以帮助：",[99,9809,9810,9813,9816,9819,9822],{},[102,9811,9812],{},"按索引顺序输出数据，减少额外排序；",[102,9814,9815],{},"快速定位最小值和最大值；",[102,9817,9818],{},"连续读取相邻索引记录；",[102,9820,9821],{},"对联合索引执行最左前缀扫描；",[102,9823,9824],{},"利用页预读和 Buffer Pool 提高连续访问效率。",[18,9826,9827],{},"但“逻辑有序”不等于“所有叶子页在磁盘上永远物理连续”。页面分裂、删除、合并和长期更新都会产生碎片，同层索引页主要依靠页面头中保存的前后页页号维持逻辑顺序。这些页号发挥逻辑指针的作用，并不是进程内存地址意义上的裸指针。",[14,9829,9831],{"id":9830},"十五b-树的写入代价","十五、B+ 树的写入代价",[18,9833,9834],{},"B+ 树并不是只有优点。",[18,9836,9837],{},"插入新记录时，需要先找到目标叶子页。如果页面空间不足，可能发生页分裂：",[118,9839,9842],{"className":9840,"code":9841,"language":123,"meta":124},[121],"一个满页\n ↓\n分裂为两个页\n ↓\n更新父节点目录项\n",[21,9843,9841],{"__ignoreMap":124},[18,9845,9846],{},"删除大量记录后，也可能触发页面合并或树结构收缩。",[18,9848,9849],{},"随机主键写入容易把数据分散到不同叶子页，可能带来：",[99,9851,9852,9855,9858,9861],{},[102,9853,9854],{},"更多随机页面访问；",[102,9856,9857],{},"页分裂；",[102,9859,9860],{},"页面利用率下降；",[102,9862,9863],{},"Buffer Pool 压力增加。",[18,9865,9866],{},"顺序递增键通常更容易写入索引右侧页面，但高并发场景下也可能形成右侧热点。主键选择需要结合实际写入模式评估。",[14,9868,9870],{"id":9869},"十六常见误区","十六、常见误区",[192,9872,9874],{"id":9873},"误区-1mysql-所有索引都是-b-树","误区 1：MySQL 所有索引都是 B+ 树",[18,9876,9877],{},"不准确。这里主要讨论 InnoDB 的普通索引。空间索引、全文索引和内部自适应哈希索引采用不同结构或机制。",[192,9879,9881],{"id":9880},"误区-2b-树的所有数据都只存在叶子节点","误区 2：B+ 树的所有数据都只存在叶子节点",[18,9883,9884],{},"需要区分“完整索引记录”和“分隔键”。非叶子节点也会保存用于导航的键，但完整索引记录集中在叶子节点。",[192,9886,9888],{"id":9887},"误区-3b-树一定比-b-树快","误区 3：B+ 树一定比 B 树快",[18,9890,9891],{},"不一定。纯内存、单次等值查询中，B 树可能提前在非叶子节点命中。B+ 树的优势主要体现在页面扇出、稳定查询路径和范围扫描。",[192,9893,9895],{"id":9894},"误区-4使用-b-树后查询一定只需要三次-io","误区 4：使用 B+ 树后查询一定只需要三次 I\u002FO",[18,9897,9898],{},"树高不是固定值，取决于页面大小、键长度、记录大小、填充率和数据量。页面还可能已经位于 Buffer Pool 中，因此树层访问次数也不能直接等同于磁盘 I\u002FO 次数。",[192,9900,9902],{"id":9901},"误区-5建立索引就一定能提高性能","误区 5：建立索引就一定能提高性能",[18,9904,9905,9906,5196,9909,5196,9911,9913],{},"索引会占用空间并增加 ",[21,9907,9908],{},"INSERT",[21,9910,7573],{},[21,9912,7576],{}," 的维护成本。低选择性索引、无法满足最左前缀的查询或返回大量数据的查询，也可能不使用索引。",[14,9915,9917],{"id":9916},"十七回答时可以怎样组织","十七、回答时可以怎样组织",[18,9919,9920],{},"面试时可以按照以下顺序回答：",[118,9922,9925],{"className":9923,"code":9924,"language":123,"meta":124},[121],"先说结构差异\n ↓\n再说数据库按页读取\n ↓\n解释扇出更大、树高更低\n ↓\n解释叶子节点有序，适合范围扫描\n ↓\n结合 InnoDB 聚簇索引和二级索引\n",[21,9926,9924],{"__ignoreMap":124},[18,9928,9929,9930,9932],{},"重点不是只说“B+ 树查询复杂度是 ",[21,9931,9317],{},"”，而是说明：",[63,9934,9935],{},[18,9936,9937],{},"InnoDB 通过页组织索引，B+ 树让一个非叶子页保存更多导航项，从而用较少层级管理大量数据；定位到叶子页后，又能沿有序叶子页完成范围扫描。",[14,9939,1570],{"id":1570},[99,9941,9942,9949,9956,9963,9970],{},[102,9943,9944],{},[77,9945,9948],{"href":9946,"rel":9947},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-index-types.html",[1579],"MySQL 8.4 Reference Manual：Clustered and Secondary Indexes",[102,9950,9951],{},[77,9952,9955],{"href":9953,"rel":9954},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-physical-structure.html",[1579],"MySQL 8.4 Reference Manual：The Physical Structure of an InnoDB Index",[102,9957,9958],{},[77,9959,9962],{"href":9960,"rel":9961},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Fcolumn-indexes.html",[1579],"MySQL 8.4 Reference Manual：Column Indexes",[102,9964,9965],{},[77,9966,9969],{"href":9967,"rel":9968},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Findex-btree-hash.html",[1579],"MySQL 8.4 Reference Manual：Comparison of B-Tree and Hash Indexes",[102,9971,9972],{},[77,9973,9976],{"href":9974,"rel":9975},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Finnodb-file-space.html",[1579],"MySQL 8.4 Reference Manual：File Space Management",[1596,9978,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":9980},[9981,9984,9985,9986,9987,9988,9989,9990,9991,9992,9993,9994,9995,9996,9997,9998,9999,10000,10001,10008,10009],{"id":16,"depth":151,"text":16,"children":9982},[9983],{"id":7606,"depth":157,"text":7606},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":9030,"depth":151,"text":9031},{"id":9080,"depth":151,"text":9081},{"id":9126,"depth":151,"text":9127},{"id":9178,"depth":151,"text":9179},{"id":9292,"depth":151,"text":9293},{"id":9326,"depth":151,"text":9327},{"id":9373,"depth":151,"text":9374},{"id":9430,"depth":151,"text":9431},{"id":9533,"depth":151,"text":9534},{"id":9559,"depth":151,"text":9560},{"id":9634,"depth":151,"text":9635},{"id":9686,"depth":151,"text":9687},{"id":9781,"depth":151,"text":9782},{"id":9803,"depth":151,"text":9804},{"id":9830,"depth":151,"text":9831},{"id":9869,"depth":151,"text":9870,"children":10002},[10003,10004,10005,10006,10007],{"id":9873,"depth":157,"text":9874},{"id":9880,"depth":157,"text":9881},{"id":9887,"depth":157,"text":9888},{"id":9894,"depth":157,"text":9895},{"id":9901,"depth":157,"text":9902},{"id":9916,"depth":151,"text":9917},{"id":1570,"depth":151,"text":1570},"wiki:java:mysql-bplus-tree-vs-btree","从磁盘页、树高、扇出、范围查询和 InnoDB 索引组织方式出发，解释 MySQL 为何采用 B+ 树，并对比 B 树、红黑树与哈希索引。",{},76,"\u002Fjava\u002Fmysql-bplus-tree-vs-btree",{"title":8977,"description":10011},"java\u002Fmysql-bplus-tree-vs-btree","2026-07-25","go1AzXFgta1vTlcSLwEBOPoFDDAlbZSlEJktzi-QTb0",{"id":10020,"title":10021,"body":10022,"commentId":13755,"description":13756,"difficulty":3063,"draft":1646,"extension":1647,"meta":13757,"navigation":780,"order":13758,"path":13759,"section":1651,"seo":13760,"stem":13761,"updated":10017,"__hash__":13762},"java\u002Fjava\u002Fmysql-index-failure-scenarios.md","MySQL 索引在什么情况下会失效？",{"type":7,"value":10023,"toc":13688},[10024,10027,10029,10032,10063,10066,10110,10132,10134,10139,10141,10150,10152,10156,10159,10163,10166,10169,10178,10181,10199,10202,10206,10209,10211,10220,10223,10252,10267,10276,10280,10283,10289,10292,10295,10299,10302,10310,10327,10330,10336,10339,10363,10376,10379,10399,10402,10405,10409,10412,10417,10420,10423,10431,10433,10442,10445,10469,10472,10482,10486,10492,10501,10504,10522,10532,10535,10558,10561,10581,10584,10593,10596,10599,10608,10613,10619,10622,10631,10646,10649,10658,10661,10676,10679,10687,10690,10710,10712,10726,10730,10733,10748,10751,10760,10763,10772,10775,10778,10792,10795,10798,10803,10807,10809,10818,10821,10830,10837,10840,10855,10858,10861,10872,10882,10886,10893,10915,10922,10925,10945,10950,10954,10961,10964,10979,10981,11003,11006,11012,11018,11024,11027,11091,11097,11107,11130,11133,11139,11144,11151,11165,11174,11177,11200,11203,11207,11214,11224,11226,11240,11243,11252,11255,11258,11262,11265,11285,11288,11293,11296,11302,11305,11311,11315,11318,11336,11342,11348,11351,11354,11378,11382,11388,11391,11399,11401,11423,11432,11435,11452,11457,11460,11477,11480,11482,11490,11493,11520,11529,11535,11540,11561,11572,11578,11591,11594,11619,11634,11637,11640,11670,11684,11690,11701,11714,11717,11720,11723,11732,11735,11750,11753,11756,11765,11772,11781,11784,11793,11796,11801,11808,11819,11825,11829,11832,11846,11849,11852,11861,11864,11867,11871,11874,11897,11900,11992,11999,12011,12014,12019,12022,12028,12031,12033,12059,12069,12077,12084,12087,12093,12099,12105,12110,12113,12143,12146,12164,12167,12185,12188,12194,12199,12208,12223,12226,12234,12239,12244,12249,12257,12262,12269,12271,12299,12317,12328,12334,12341,12348,12393,12399,12404,12406,12414,12430,12436,12442,12448,12453,12462,12470,12473,12478,12497,12512,12519,12524,12527,12550,12553,12559,12565,12603,12605,12614,12622,12625,12633,12636,12642,12652,12658,12666,12669,12688,12693,12699,12705,12709,12712,12715,12723,12725,12749,12757,12760,12766,12774,12780,12783,12788,12795,12801,12804,12818,12821,12828,12833,12840,12845,12851,12863,12865,12874,12889,12899,12902,12908,12913,12916,12933,12941,12949,12956,12961,12964,12970,12973,12994,12996,13014,13019,13025,13028,13047,13053,13057,13197,13202,13207,13211,13218,13238,13248,13253,13275,13278,13284,13287,13319,13322,13397,13402,13408,13411,13414,13428,13435,13438,13444,13453,13456,13462,13465,13468,13474,13479,13482,13513,13517,13520,13567,13571,13575,13578,13582,13585,13595,13598,13604,13607,13611,13614,13621,13624,13628,13686],[10,10025,10021],{"id":10026},"mysql-索引在什么情况下会失效",[14,10028,16],{"id":16},[18,10030,10031],{},"所谓“索引失效”并不是 MySQL 的正式术语，实际需要区分三种情况：",[708,10033,10034,10041,10060],{},[102,10035,10036,10037,10040],{},"SQL 写法或索引结构决定了索引无法用于快速定位，例如联合索引没有满足最左前缀、查询的是索引列的计算结果但索引只保存原始列值、",[21,10038,10039],{},"LIKE"," 以通配符开头。",[102,10042,10043,10044,10047,10048,10051,10052,10055,10056,10059],{},"索引可以使用，但只能使用其中一部分。例如联合索引 ",[21,10045,10046],{},"(a,b,c)"," 查询 ",[21,10049,10050],{},"a=1 AND b>10 AND c=3"," 时，通常可以用 ",[21,10053,10054],{},"a、b"," 确定扫描范围，",[21,10057,10058],{},"c"," 可能通过索引条件下推继续过滤，却不能进一步缩小连续的索引扫描区间。",[102,10061,10062],{},"索引具备使用条件，但优化器估算全表扫描成本更低，于是主动不选。例如查询返回大量数据、索引选择性很低或回表成本过高。",[18,10064,10065],{},"常见场景包括：",[99,10067,10068,10071,10074,10077,10086,10092,10104,10107],{},[102,10069,10070],{},"联合索引不满足最左前缀；",[102,10072,10073],{},"在索引列上执行函数、计算或不匹配的表达式；",[102,10075,10076],{},"比较两侧数据类型、字符集或排序规则不兼容，引发隐式转换；",[102,10078,10079,1217,10082,10085],{},[21,10080,10081],{},"LIKE '%keyword'",[21,10083,10084],{},"LIKE '%keyword%'"," 以通配符开头；",[102,10087,10088,10091],{},[21,10089,10090],{},"OR"," 的某个分支缺少可用索引，且优化器无法采用合适的 Index Merge；",[102,10093,10094,5196,10097,5196,10100,10103],{},[21,10095,10096],{},"!=",[21,10098,10099],{},"NOT IN",[21,10101,10102],{},"IS NOT NULL"," 等条件命中数据过多；",[102,10105,10106],{},"查询需要返回表中很大比例的数据，优化器认为全表扫描更便宜；",[102,10108,10109],{},"索引统计信息不准确，导致优化器成本估算偏差。",[18,10111,10112,10113,10116,10117,1217,10120,10123,10124,10127,10128,10131],{},"判断索引是否真正有效，不能只看 ",[21,10114,10115],{},"possible_keys","，应使用 ",[21,10118,10119],{},"EXPLAIN",[21,10121,10122],{},"EXPLAIN ANALYZE","，重点观察实际选择的 ",[21,10125,10126],{},"key","、访问类型 ",[21,10129,10130],{},"type","、预计或实际扫描行数，以及是否发生大量回表。",[192,10133,7606],{"id":7606},[63,10135,10136],{},[18,10137,10138],{},"索引失效要区分“不能用、只用一部分、能用但优化器不选”；排查时先看索引结构和 SQL 写法，再用执行计划验证实际扫描成本。",[14,10140,73],{"id":73},[18,10142,10143],{},[77,10144,10147],{"href":10145,"target":80,"rel":10146},"\u002Fimages\u002Fwiki\u002Fjava\u002Fmysql-index-failure-scenarios.svg",[82,83],[85,10148],{"src":10145,"alt":10149},"MySQL 索引失效的三类情况与排查路径",[14,10151,90],{"id":90},[14,10153,10155],{"id":10154},"一先区分三种索引失效","一、先区分三种“索引失效”",[18,10157,10158],{},"日常讨论经常把所有没有达到预期性能的情况都叫作“索引失效”，但这会掩盖真正的问题。",[192,10160,10162],{"id":10161},"_1-索引无法用于定位","1. 索引无法用于定位",[18,10164,10165],{},"索引的有序结构与查询条件不匹配，MySQL 无法根据该条件确定一个有效的索引查找范围。",[18,10167,10168],{},"例如索引为：",[118,10170,10172],{"className":7908,"code":10171,"language":7910,"meta":124,"style":124},"KEY idx_user_time (user_id, created_at)\n",[21,10173,10174],{"__ignoreMap":124},[142,10175,10176],{"class":144,"line":145},[142,10177,10171],{},[18,10179,10180],{},"查询只使用第二列：",[118,10182,10184],{"className":7908,"code":10183,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE created_at >= '2026-07-01';\n",[21,10185,10186,10190,10194],{"__ignoreMap":124},[142,10187,10188],{"class":144,"line":145},[142,10189,9444],{},[142,10191,10192],{"class":144,"line":151},[142,10193,9449],{},[142,10195,10196],{"class":144,"line":157},[142,10197,10198],{},"WHERE created_at >= '2026-07-01';\n",[18,10200,10201],{},"传统的联合索引范围查找无法绕过第一列，直接按照第二列定位连续区间。",[192,10203,10205],{"id":10204},"_2-只使用了部分索引能力","2. 只使用了部分索引能力",[18,10207,10208],{},"SQL 使用了索引，但索引没有把扫描范围缩小到预期程度。",[18,10210,1263],{},[118,10212,10214],{"className":7908,"code":10213,"language":7910,"meta":124,"style":124},"KEY idx_abc (a, b, c)\n",[21,10215,10216],{"__ignoreMap":124},[142,10217,10218],{"class":144,"line":145},[142,10219,10213],{},[18,10221,10222],{},"查询：",[118,10224,10226],{"className":7908,"code":10225,"language":7910,"meta":124,"style":124},"SELECT *\nFROM t\nWHERE a = 1\n AND b > 10\n AND c = 3;\n",[21,10227,10228,10232,10237,10242,10247],{"__ignoreMap":124},[142,10229,10230],{"class":144,"line":145},[142,10231,9444],{},[142,10233,10234],{"class":144,"line":151},[142,10235,10236],{},"FROM t\n",[142,10238,10239],{"class":144,"line":157},[142,10240,10241],{},"WHERE a = 1\n",[142,10243,10244],{"class":144,"line":163},[142,10245,10246],{}," AND b > 10\n",[142,10248,10249],{"class":144,"line":169},[142,10250,10251],{}," AND c = 3;\n",[18,10253,10254,10255,10258,10259,10262,10263,10266],{},"通常可以使用 ",[21,10256,10257],{},"a=1 AND b>10"," 构造索引扫描范围。由于 ",[21,10260,10261],{},"b"," 是范围条件，",[21,10264,10265],{},"c=3"," 一般不能继续把这个范围切成更小的连续区间。",[18,10268,10269,10270,10272,10273,10275],{},"但这不等于 ",[21,10271,10058],{}," 完全没用。满足条件时，MySQL 可以通过索引条件下推（Index Condition Pushdown，ICP），在索引层先判断 ",[21,10274,10265],{},"，减少回表数量。",[192,10277,10279],{"id":10278},"_3-优化器主动不选择索引","3. 优化器主动不选择索引",[18,10281,10282],{},"索引本身可用，但 MySQL 优化器根据统计信息估算：",[118,10284,10287],{"className":10285,"code":10286,"language":123,"meta":124},[121],"使用二级索引扫描 + 大量回表\n >\n顺序扫描整张表\n",[21,10288,10286],{"__ignoreMap":124},[18,10290,10291],{},"于是执行计划选择全表扫描。",[18,10293,10294],{},"这种情况不是索引结构失效，而是成本选择。强行使用索引不一定更快。",[14,10296,10298],{"id":10297},"二联合索引不满足最左前缀","二、联合索引不满足最左前缀",[18,10300,10301],{},"假设存在联合索引：",[118,10303,10304],{"className":7908,"code":10213,"language":7910,"meta":124,"style":124},[21,10305,10306],{"__ignoreMap":124},[142,10307,10308],{"class":144,"line":145},[142,10309,10213],{},[18,10311,10312,10313,10315,10316,10318,10319,10315,10321,10323,10324,10326],{},"B+ 树中的记录首先按 ",[21,10314,77],{}," 排序；",[21,10317,77],{}," 相同时，再按 ",[21,10320,10261],{},[21,10322,10054],{}," 都相同时，才按 ",[21,10325,10058],{}," 排序。",[18,10328,10329],{},"可以近似理解为：",[118,10331,10334],{"className":10332,"code":10333,"language":123,"meta":124},[121],"(a=1, b=1, c=1)\n(a=1, b=1, c=5)\n(a=1, b=2, c=2)\n(a=2, b=1, c=3)\n",[21,10335,10333],{"__ignoreMap":124},[18,10337,10338],{},"因此以下条件通常能够使用联合索引定位：",[118,10340,10342],{"className":7908,"code":10341,"language":7910,"meta":124,"style":124},"WHERE a = 1\nWHERE a = 1 AND b = 2\nWHERE a = 1 AND b = 2 AND c = 3\nWHERE a = 1 AND c = 3\n",[21,10343,10344,10348,10353,10358],{"__ignoreMap":124},[142,10345,10346],{"class":144,"line":145},[142,10347,10241],{},[142,10349,10350],{"class":144,"line":151},[142,10351,10352],{},"WHERE a = 1 AND b = 2\n",[142,10354,10355],{"class":144,"line":157},[142,10356,10357],{},"WHERE a = 1 AND b = 2 AND c = 3\n",[142,10359,10360],{"class":144,"line":163},[142,10361,10362],{},"WHERE a = 1 AND c = 3\n",[18,10364,10365,10366,10369,10370,10372,10373,10375],{},"最后一个条件仍然可以通过 ",[21,10367,10368],{},"a=1"," 定位范围，只是缺少 ",[21,10371,10261],{}," 后，",[21,10374,10265],{}," 通常不能继续缩小查找区间。",[18,10377,10378],{},"以下查询没有使用最左列：",[118,10380,10382],{"className":7908,"code":10381,"language":7910,"meta":124,"style":124},"WHERE b = 2\nWHERE c = 3\nWHERE b = 2 AND c = 3\n",[21,10383,10384,10389,10394],{"__ignoreMap":124},[142,10385,10386],{"class":144,"line":145},[142,10387,10388],{},"WHERE b = 2\n",[142,10390,10391],{"class":144,"line":151},[142,10392,10393],{},"WHERE c = 3\n",[142,10395,10396],{"class":144,"line":157},[142,10397,10398],{},"WHERE b = 2 AND c = 3\n",[18,10400,10401],{},"它们通常无法使用传统的最左前缀方式直接定位。",[18,10403,10404],{},"需要注意，MySQL 8.0 在满足条件时可能使用 Skip Scan，把缺失的最左列按多个可能值分别扫描。因此“缺少最左列一定完全不用索引”也不是绝对结论，最终必须以执行计划为准。",[14,10406,10408],{"id":10407},"三范围条件之后的列还能不能使用","三、范围条件之后的列还能不能使用",[18,10410,10411],{},"常见说法是：",[63,10413,10414],{},[18,10415,10416],{},"联合索引遇到范围查询后，后面的列全部失效。",[18,10418,10419],{},"这个说法过于绝对。",[18,10421,10422],{},"索引为：",[118,10424,10425],{"className":7908,"code":10213,"language":7910,"meta":124,"style":124},[21,10426,10427],{"__ignoreMap":124},[142,10428,10429],{"class":144,"line":145},[142,10430,10213],{},[18,10432,10222],{},[118,10434,10436],{"className":7908,"code":10435,"language":7910,"meta":124,"style":124},"WHERE a = 1 AND b > 10 AND c = 3\n",[21,10437,10438],{"__ignoreMap":124},[142,10439,10440],{"class":144,"line":145},[142,10441,10435],{},[18,10443,10444],{},"更准确的理解是：",[99,10446,10447,10455,10460,10466],{},[102,10448,10449,1441,10451,10454],{},[21,10450,10368],{},[21,10452,10453],{},"b>10"," 可以共同确定扫描范围；",[102,10456,10457,10459],{},[21,10458,10265],{}," 通常不能继续缩小这个连续范围；",[102,10461,10462,10463,10465],{},"如果启用了 ICP，",[21,10464,10265],{}," 仍可能在索引层参与过滤；",[102,10467,10468],{},"如果查询列都包含在索引中，还可能形成覆盖索引，避免回表。",[18,10470,10471],{},"所以“能否参与范围定位”“能否参与索引层过滤”和“能否避免回表”是三个不同问题。",[18,10473,10474,10475,10478,10479,10481],{},"另外，",[21,10476,10477],{},"IN"," 在很多情况下会被转换成多个等值范围，不应简单地把所有 ",[21,10480,10477],{}," 都视为遇到范围后索引失效。",[14,10483,10485],{"id":10484},"四在索引列上进行函数或计算","四、在索引列上进行函数或计算",[18,10487,8131,10488,10491],{},[21,10489,10490],{},"created_at"," 上有普通索引：",[118,10493,10495],{"className":7908,"code":10494,"language":7910,"meta":124,"style":124},"KEY idx_created_at (created_at)\n",[21,10496,10497],{"__ignoreMap":124},[142,10498,10499],{"class":144,"line":145},[142,10500,10494],{},[18,10502,10503],{},"下面的写法把函数作用在索引列上：",[118,10505,10507],{"className":7908,"code":10506,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE DATE(created_at) = '2026-07-25';\n",[21,10508,10509,10513,10517],{"__ignoreMap":124},[142,10510,10511],{"class":144,"line":145},[142,10512,9444],{},[142,10514,10515],{"class":144,"line":151},[142,10516,9449],{},[142,10518,10519],{"class":144,"line":157},[142,10520,10521],{},"WHERE DATE(created_at) = '2026-07-25';\n",[18,10523,10524,10525,10527,10528,10531],{},"普通索引保存的是原始 ",[21,10526,10490],{}," 值，而不是 ",[21,10529,10530],{},"DATE(created_at)"," 的计算结果。MySQL 通常无法直接根据普通索引定位函数结果。",[18,10533,10534],{},"可以改写为范围条件：",[118,10536,10538],{"className":7908,"code":10537,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE created_at >= '2026-07-25 00:00:00'\n AND created_at \u003C '2026-07-26 00:00:00';\n",[21,10539,10540,10544,10548,10553],{"__ignoreMap":124},[142,10541,10542],{"class":144,"line":145},[142,10543,9444],{},[142,10545,10546],{"class":144,"line":151},[142,10547,9449],{},[142,10549,10550],{"class":144,"line":157},[142,10551,10552],{},"WHERE created_at >= '2026-07-25 00:00:00'\n",[142,10554,10555],{"class":144,"line":163},[142,10556,10557],{}," AND created_at \u003C '2026-07-26 00:00:00';\n",[18,10559,10560],{},"类似问题还包括：",[118,10562,10564],{"className":7908,"code":10563,"language":7910,"meta":124,"style":124},"WHERE amount + 1 = 100\nWHERE LOWER(username) = 'tom'\nWHERE CAST(order_no AS UNSIGNED) = 1001\n",[21,10565,10566,10571,10576],{"__ignoreMap":124},[142,10567,10568],{"class":144,"line":145},[142,10569,10570],{},"WHERE amount + 1 = 100\n",[142,10572,10573],{"class":144,"line":151},[142,10574,10575],{},"WHERE LOWER(username) = 'tom'\n",[142,10577,10578],{"class":144,"line":157},[142,10579,10580],{},"WHERE CAST(order_no AS UNSIGNED) = 1001\n",[18,10582,10583],{},"应优先把运算移动到常量一侧：",[118,10585,10587],{"className":7908,"code":10586,"language":7910,"meta":124,"style":124},"WHERE amount = 99\n",[21,10588,10589],{"__ignoreMap":124},[142,10590,10591],{"class":144,"line":145},[142,10592,10586],{},[18,10594,10595],{},"这里所说的“对索引列进行未建立函数索引的运算”，可以用下面的例子理解。",[18,10597,10598],{},"普通索引：",[118,10600,10602],{"className":7908,"code":10601,"language":7910,"meta":124,"style":124},"KEY idx_amount (amount)\n",[21,10603,10604],{"__ignoreMap":124},[142,10605,10606],{"class":144,"line":145},[142,10607,10601],{},[18,10609,10610,10611,3639],{},"保存并排序的是原始 ",[21,10612,8134],{},[118,10614,10617],{"className":10615,"code":10616,"language":123,"meta":124},[121],"10 → 20 → 30 → 40\n",[21,10618,10616],{"__ignoreMap":124},[18,10620,10621],{},"查询条件却是：",[118,10623,10625],{"className":7908,"code":10624,"language":7910,"meta":124,"style":124},"WHERE amount + 1 = 31\n",[21,10626,10627],{"__ignoreMap":124},[142,10628,10629],{"class":144,"line":145},[142,10630,10624],{},[18,10632,10633,10634,10637,10638,10641,10642,10645],{},"MySQL 需要比较的是 ",[21,10635,10636],{},"amount + 1"," 的结果，而普通索引中没有保存这个结果。它通常无法直接在 ",[21,10639,10640],{},"idx_amount"," 中查找 ",[21,10643,10644],{},"31","，而需要对候选记录计算表达式。",[18,10647,10648],{},"这个条件可以直接改写为：",[118,10650,10652],{"className":7908,"code":10651,"language":7910,"meta":124,"style":124},"WHERE amount = 30\n",[21,10653,10654],{"__ignoreMap":124},[142,10655,10656],{"class":144,"line":145},[142,10657,10651],{},[18,10659,10660],{},"如果业务确实需要长期按照某个表达式查询，MySQL 8.0.13 及以上版本支持函数索引：",[118,10662,10664],{"className":7908,"code":10663,"language":7910,"meta":124,"style":124},"CREATE INDEX idx_amount_plus_one\nON orders ((amount + 1));\n",[21,10665,10666,10671],{"__ignoreMap":124},[142,10667,10668],{"class":144,"line":145},[142,10669,10670],{},"CREATE INDEX idx_amount_plus_one\n",[142,10672,10673],{"class":144,"line":151},[142,10674,10675],{},"ON orders ((amount + 1));\n",[18,10677,10678],{},"之后与索引表达式匹配的查询才可以直接检索表达式结果：",[118,10680,10681],{"className":7908,"code":10624,"language":7910,"meta":124,"style":124},[21,10682,10683],{"__ignoreMap":124},[142,10684,10685],{"class":144,"line":145},[142,10686,10624],{},[18,10688,10689],{},"也可以创建生成列，再为生成列建立索引：",[118,10691,10693],{"className":7908,"code":10692,"language":7910,"meta":124,"style":124},"ALTER TABLE orders\nADD COLUMN order_date DATE AS (DATE(created_at)),\nADD INDEX idx_order_date (order_date);\n",[21,10694,10695,10700,10705],{"__ignoreMap":124},[142,10696,10697],{"class":144,"line":145},[142,10698,10699],{},"ALTER TABLE orders\n",[142,10701,10702],{"class":144,"line":151},[142,10703,10704],{},"ADD COLUMN order_date DATE AS (DATE(created_at)),\n",[142,10706,10707],{"class":144,"line":157},[142,10708,10709],{},"ADD INDEX idx_order_date (order_date);\n",[18,10711,4211],{},[99,10713,10714,10717,10720,10723],{},[102,10715,10716],{},"函数索引保存的是表达式计算结果，不是让任意函数都自动使用原列索引；",[102,10718,10719],{},"查询中的表达式需要与索引定义匹配；",[102,10721,10722],{},"函数索引会占用空间，也会增加写入和更新成本；",[102,10724,10725],{},"能通过等价范围条件改写的 SQL，通常优先改写，未必需要新增索引。",[14,10727,10729],{"id":10728},"五隐式类型转换","五、隐式类型转换",[18,10731,10732],{},"假设订单号是字符串：",[118,10734,10736],{"className":7908,"code":10735,"language":7910,"meta":124,"style":124},"order_no VARCHAR(32),\nKEY idx_order_no (order_no)\n",[21,10737,10738,10743],{"__ignoreMap":124},[142,10739,10740],{"class":144,"line":145},[142,10741,10742],{},"order_no VARCHAR(32),\n",[142,10744,10745],{"class":144,"line":151},[142,10746,10747],{},"KEY idx_order_no (order_no)\n",[18,10749,10750],{},"推荐使用相同类型进行比较：",[118,10752,10754],{"className":7908,"code":10753,"language":7910,"meta":124,"style":124},"WHERE order_no = '10001'\n",[21,10755,10756],{"__ignoreMap":124},[142,10757,10758],{"class":144,"line":145},[142,10759,10753],{},[18,10761,10762],{},"如果写成：",[118,10764,10766],{"className":7908,"code":10765,"language":7910,"meta":124,"style":124},"WHERE order_no = 10001\n",[21,10767,10768],{"__ignoreMap":124},[142,10769,10770],{"class":144,"line":145},[142,10771,10765],{},[18,10773,10774],{},"MySQL 需要按照类型转换规则比较字符串与数字，可能对索引列执行转换，导致无法按原有字符串顺序高效定位。",[18,10776,10777],{},"排查时要检查：",[99,10779,10780,10783,10786,10789],{},[102,10781,10782],{},"数字列是否与字符串参数比较；",[102,10784,10785],{},"字符串列的字符集是否一致；",[102,10787,10788],{},"字符串列的排序规则是否兼容；",[102,10790,10791],{},"JOIN 两侧字段的类型、长度、字符集和排序规则是否匹配。",[18,10793,10794],{},"例如两个字符串列字符集不兼容时，即使两侧都有索引，也可能无法高效使用索引完成连接。",[18,10796,10797],{},"最稳妥的原则是：",[63,10799,10800],{},[18,10801,10802],{},"SQL 参数类型应与索引列类型一致，JOIN 字段的类型和字符规则也应保持一致。",[14,10804,10806],{"id":10805},"六like-以通配符开头","六、LIKE 以通配符开头",[18,10808,10422],{},[118,10810,10812],{"className":7908,"code":10811,"language":7910,"meta":124,"style":124},"KEY idx_name (name)\n",[21,10813,10814],{"__ignoreMap":124},[142,10815,10816],{"class":144,"line":145},[142,10817,10811],{},[18,10819,10820],{},"以下前缀匹配通常可以利用 B+ 树的有序性：",[118,10822,10824],{"className":7908,"code":10823,"language":7910,"meta":124,"style":124},"WHERE name LIKE 'zhizhi%'\n",[21,10825,10826],{"__ignoreMap":124},[142,10827,10828],{"class":144,"line":145},[142,10829,10823],{},[18,10831,10832,10833,10836],{},"MySQL 可以定位到以 ",[21,10834,10835],{},"zhizhi"," 开头的索引范围。",[18,10838,10839],{},"以下写法无法确定字符串起始位置：",[118,10841,10843],{"className":7908,"code":10842,"language":7910,"meta":124,"style":124},"WHERE name LIKE '%zhizhi'\nWHERE name LIKE '%zhizhi%'\n",[21,10844,10845,10850],{"__ignoreMap":124},[142,10846,10847],{"class":144,"line":145},[142,10848,10849],{},"WHERE name LIKE '%zhizhi'\n",[142,10851,10852],{"class":144,"line":151},[142,10853,10854],{},"WHERE name LIKE '%zhizhi%'\n",[18,10856,10857],{},"普通 B+ 树索引通常无法据此快速定位范围。",[18,10859,10860],{},"如果查询是高频的任意位置文本搜索，应根据业务考虑：",[99,10862,10863,10866,10869],{},[102,10864,10865],{},"FULLTEXT 全文索引；",[102,10867,10868],{},"Elasticsearch 等搜索系统；",[102,10870,10871],{},"调整业务模型，保存可索引的前缀或结构化字段。",[18,10873,10874,10875,10877,10878,10881],{},"需要注意，如果查询需要的列全部包含在索引中，优化器仍可能选择扫描整个索引，因为索引比数据行更窄。此时执行计划中的 ",[21,10876,10130],{}," 可能是 ",[21,10879,10880],{},"index","，但这仍然是全索引扫描，并不是高效的范围查找。",[14,10883,10885],{"id":10884},"七or-中存在无法使用索引的分支","七、OR 中存在无法使用索引的分支",[18,10887,10888,10889,10892],{},"假设只有 ",[21,10890,10891],{},"user_id"," 有索引：",[118,10894,10896],{"className":7908,"code":10895,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE user_id = 100\n OR remark = 'manual';\n",[21,10897,10898,10902,10906,10910],{"__ignoreMap":124},[142,10899,10900],{"class":144,"line":145},[142,10901,9444],{},[142,10903,10904],{"class":144,"line":151},[142,10905,9449],{},[142,10907,10908],{"class":144,"line":157},[142,10909,8499],{},[142,10911,10912],{"class":144,"line":163},[142,10913,10914],{}," OR remark = 'manual';\n",[18,10916,10917,10918,10921],{},"即使第一部分能够使用索引，为了找出满足 ",[21,10919,10920],{},"remark='manual'"," 的记录，MySQL 仍可能需要扫描大量数据，最终选择全表扫描。",[18,10923,10924],{},"常见优化方式包括：",[708,10926,10927,10930,10936,10942],{},[102,10928,10929],{},"为确实需要的条件建立合适索引；",[102,10931,10932,10933,1191],{},"在语义允许且执行计划更优时拆成两个查询并使用 ",[21,10934,10935],{},"UNION ALL",[102,10937,10938,10939,10941],{},"检查重复数据处理，不能为了用索引直接把 ",[21,10940,10090],{}," 改坏；",[102,10943,10944],{},"观察优化器是否采用 Index Merge，而不是假设多个单列索引一定会被组合。",[18,10946,3660,10947,10949],{},[21,10948,10090],{}," 两侧分别有可用索引，MySQL 可能选择 Index Merge，也可能根据成本选择其他计划。",[192,10951,10953],{"id":10952},"index-merge-是什么","Index Merge 是什么",[18,10955,10956,10957,10960],{},"Index Merge 是 MySQL 在",[68,10958,10959],{},"同一张表","上分别扫描多个索引，再合并这些索引扫描结果的访问方式。",[18,10962,10963],{},"假设存在两个单列索引：",[118,10965,10967],{"className":7908,"code":10966,"language":7910,"meta":124,"style":124},"KEY idx_user_id (user_id),\nKEY idx_status (status)\n",[21,10968,10969,10974],{"__ignoreMap":124},[142,10970,10971],{"class":144,"line":145},[142,10972,10973],{},"KEY idx_user_id (user_id),\n",[142,10975,10976],{"class":144,"line":151},[142,10977,10978],{},"KEY idx_status (status)\n",[18,10980,10222],{},[118,10982,10984],{"className":7908,"code":10983,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE user_id = 100\n OR status = 1;\n",[21,10985,10986,10990,10994,10998],{"__ignoreMap":124},[142,10987,10988],{"class":144,"line":145},[142,10989,9444],{},[142,10991,10992],{"class":144,"line":151},[142,10993,9449],{},[142,10995,10996],{"class":144,"line":157},[142,10997,8499],{},[142,10999,11000],{"class":144,"line":163},[142,11001,11002],{}," OR status = 1;\n",[18,11004,11005],{},"MySQL 可以分别得到：",[118,11007,11010],{"className":11008,"code":11009,"language":123,"meta":124},[121],"idx_user_id 扫描结果：满足 user_id=100 的行 ID\nidx_status 扫描结果：满足 status=1 的行 ID\n ↓\n 合并并去重\n ↓\n 读取完整记录\n",[21,11011,11009],{"__ignoreMap":124},[18,11013,11014,11015,11017],{},"在 ",[21,11016,10119],{}," 中通常表现为：",[118,11019,11022],{"className":11020,"code":11021,"language":123,"meta":124},[121],"type: index_merge\nkey: idx_user_id,idx_status\nExtra: Using union(...)\n",[21,11023,11021],{"__ignoreMap":124},[18,11025,11026],{},"Index Merge 主要有三种合并方式：",[341,11028,11029,11042],{},[344,11030,11031],{},[347,11032,11033,11036,11039],{},[350,11034,11035],{},"方式",[350,11037,11038],{},"适用逻辑",[350,11040,11041],{},"处理方式",[360,11043,11044,11061,11075],{},[347,11045,11046,11051,11058],{},[365,11047,11048],{},[21,11049,11050],{},"Using intersect(...)",[365,11052,11053,11054,11057],{},"多个条件用 ",[21,11055,11056],{},"AND"," 连接",[365,11059,11060],{},"取多个索引结果的交集",[347,11062,11063,11068,11072],{},[365,11064,11065],{},[21,11066,11067],{},"Using union(...)",[365,11069,11053,11070,11057],{},[21,11071,10090],{},[365,11073,11074],{},"取多个索引结果的并集",[347,11076,11077,11082,11088],{},[365,11078,11079],{},[21,11080,11081],{},"Using sort_union(...)",[365,11083,11084,11085,11087],{},"多个范围条件用 ",[21,11086,10090],{}," 连接，但不能直接使用 union 算法",[365,11089,11090],{},"收集全部行 ID，排序、去重后再读取记录",[192,11092,11094,11096],{"id":11093},"using-sort_union-是什么意思",[21,11095,11081],{}," 是什么意思",[18,11098,11099,11100,1441,11103,11106],{},"先看一个典型查询。假设 ",[21,11101,11102],{},"key_col1",[21,11104,11105],{},"key_col2"," 分别建立了单列索引：",[118,11108,11110],{"className":7908,"code":11109,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE key_col1 \u003C 10\n OR key_col2 \u003C 20;\n",[21,11111,11112,11116,11120,11125],{"__ignoreMap":124},[142,11113,11114],{"class":144,"line":145},[142,11115,9444],{},[142,11117,11118],{"class":144,"line":151},[142,11119,9449],{},[142,11121,11122],{"class":144,"line":157},[142,11123,11124],{},"WHERE key_col1 \u003C 10\n",[142,11126,11127],{"class":144,"line":163},[142,11128,11129],{}," OR key_col2 \u003C 20;\n",[18,11131,11132],{},"优化器可以分别扫描两个索引，但这两个范围扫描产生的行 ID 不能直接按 union 算法边扫描边归并。此时可能采用 sort-union：",[118,11134,11137],{"className":11135,"code":11136,"language":123,"meta":124},[121],"扫描 key_col1 \u003C 10，收集行 ID\n \\\n → 汇总全部行 ID → 按行 ID 排序 → 去重 → 读取完整记录\n \u002F\n扫描 key_col2 \u003C 20，收集行 ID\n",[21,11138,11136],{"__ignoreMap":124},[18,11140,11141,11142,52],{},"以 InnoDB 二级索引为例，这里的“行 ID”通常可以理解为索引记录中携带的主键值。排序的对象是这些用于定位记录的标识，不是对最终查询结果执行 ",[21,11143,9515],{},[18,11145,11146,5705,11148,11150],{},[21,11147,11067],{},[21,11149,11081],{}," 的关键区别是：",[99,11152,11153,11159],{},[102,11154,11155,11158],{},[21,11156,11157],{},"union"," 可以对多个索引扫描产生的有序行 ID 流直接归并；",[102,11160,11161,11164],{},[21,11162,11163],{},"sort_union"," 需要先收集所有行 ID，再排序和去重，因此在完成收集与排序前不能开始返回记录。",[18,11166,11167,11168,11170,11171,11173],{},"所以 ",[21,11169,11163],{}," 通常比直接的 ",[21,11172,11157],{}," 多出行 ID 缓冲、排序和去重成本。候选记录很多时，优化器也可能认为全表扫描更便宜，最终不选择 Index Merge。",[18,11175,11176],{},"需要特别区分：",[99,11178,11179,11184,11191],{},[102,11180,11181,11183],{},[21,11182,11081],{}," 是同一张表内部多个索引扫描结果的合并算法；",[102,11185,11186,11187,11190],{},"SQL 的 ",[21,11188,11189],{},"UNION"," 是多个查询结果集的集合运算；",[102,11192,11193,11196,11197,11199],{},[21,11194,11195],{},"Using filesort"," 通常表示为了满足 ",[21,11198,9515],{}," 等要求进行额外排序。",[18,11201,11202],{},"这三者不是一回事。",[192,11204,11206],{"id":11205},"index-merge-从哪个版本开始支持","Index Merge 从哪个版本开始支持",[18,11208,11209,11210,11213],{},"Index Merge 从 ",[68,11211,11212],{},"MySQL 5.0"," 开始引入。在此之前，一张表在一次查询访问中通常至多选择一个索引；MySQL 5.0 开始可以在同一张表上扫描多个索引并合并结果。",[18,11215,11216,11217,5196,11220,11223],{},"需要注意，Index Merge 本身是 MySQL 5.0 就有的访问方式，而用于显式影响它的 ",[21,11218,11219],{},"INDEX_MERGE",[21,11221,11222],{},"NO_INDEX_MERGE"," 优化器 Hint 是后续版本才增加的能力，不应把两者的版本混为一谈。",[18,11225,1263],{},[118,11227,11229],{"className":7908,"code":11228,"language":7910,"meta":124,"style":124},"WHERE user_id = 100\n AND status = 1\n",[21,11230,11231,11235],{"__ignoreMap":124},[142,11232,11233],{"class":144,"line":145},[142,11234,8499],{},[142,11236,11237],{"class":144,"line":151},[142,11238,11239],{}," AND status = 1\n",[18,11241,11242],{},"优化器可能分别扫描两个索引后取交集。不过，很多情况下建立符合查询模式的联合索引：",[118,11244,11246],{"className":7908,"code":11245,"language":7910,"meta":124,"style":124},"KEY idx_user_status (user_id, status)\n",[21,11247,11248],{"__ignoreMap":124},[142,11249,11250],{"class":144,"line":145},[142,11251,11245],{},[18,11253,11254],{},"会比扫描并合并两个单列索引更直接。",[18,11256,11257],{},"因此 Index Merge 是优化器可选择的一种方案，不代表“多个单列索引一定等价于联合索引”。它也只合并同一张表上的索引扫描，不负责合并不同表的索引。",[14,11259,11261],{"id":11260},"八否定条件和低选择性条件","八、否定条件和低选择性条件",[18,11263,11264],{},"以下条件经常返回大量记录：",[118,11266,11268],{"className":7908,"code":11267,"language":7910,"meta":124,"style":124},"WHERE status != 1\nWHERE type NOT IN (1, 2)\nWHERE deleted_at IS NOT NULL\n",[21,11269,11270,11275,11280],{"__ignoreMap":124},[142,11271,11272],{"class":144,"line":145},[142,11273,11274],{},"WHERE status != 1\n",[142,11276,11277],{"class":144,"line":151},[142,11278,11279],{},"WHERE type NOT IN (1, 2)\n",[142,11281,11282],{"class":144,"line":157},[142,11283,11284],{},"WHERE deleted_at IS NOT NULL\n",[18,11286,11287],{},"这些操作符并不意味着语法上绝对不能使用索引。真正的问题通常是选择性：",[63,11289,11290],{},[18,11291,11292],{},"如果条件会命中表中大部分记录，使用二级索引定位后再逐条回表，可能比全表扫描更贵。",[18,11294,11295],{},"同理，以下字段即使有索引，也可能因为区分度太低而不被选择：",[118,11297,11300],{"className":11298,"code":11299,"language":123,"meta":124},[121],"性别\n是否删除\n只有少量枚举值的状态\n大量相同值的业务类型\n",[21,11301,11299],{"__ignoreMap":124},[18,11303,11304],{},"低基数字段并非永远不适合索引。如果它与其他字段组成联合索引、查询命中比例很低，或者能够形成覆盖索引，依然可能产生价值。",[18,11306,10474,11307,11310],{},[21,11308,11309],{},"IS NULL"," 可以使用索引，不应把它列为固定的索引失效规则。",[14,11312,11314],{"id":11313},"九查询返回数据过多","九、查询返回数据过多",[18,11316,11317],{},"假设表中有 100 万行，而条件预计返回 80 万行：",[118,11319,11321],{"className":7908,"code":11320,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE status = 1;\n",[21,11322,11323,11327,11331],{"__ignoreMap":124},[142,11324,11325],{"class":144,"line":145},[142,11326,9444],{},[142,11328,11329],{"class":144,"line":151},[142,11330,9449],{},[142,11332,11333],{"class":144,"line":157},[142,11334,11335],{},"WHERE status = 1;\n",[18,11337,3660,11338,11341],{},[21,11339,11340],{},"status"," 是二级索引，执行过程可能是：",[118,11343,11346],{"className":11344,"code":11345,"language":123,"meta":124},[121],"扫描大量二级索引记录\n ↓\n根据主键逐条回表\n ↓\n读取完整行\n",[21,11347,11345],{"__ignoreMap":124},[18,11349,11350],{},"大量离散回表的成本可能高于直接扫描聚簇索引，因此优化器会主动选择全表扫描。",[18,11352,11353],{},"可以从以下方向优化：",[99,11355,11356,11359,11362,11365,11368,11371],{},[102,11357,11358],{},"确认业务是否真的需要返回如此多的数据；",[102,11360,11361],{},"增加更有区分度的查询条件；",[102,11363,11364],{},"建立符合查询模式的联合索引；",[102,11366,11367],{},"只查询必要字段，评估覆盖索引；",[102,11369,11370],{},"分页或分批处理；",[102,11372,11373,11374,11377],{},"避免用 ",[21,11375,11376],{},"FORCE INDEX"," 掩盖不合理的数据访问方式。",[14,11379,11381],{"id":11380},"十order-by-或-group-by-没有匹配索引顺序","十、ORDER BY 或 GROUP BY 没有匹配索引顺序",[18,11383,11384,11385,11387],{},"索引不仅可以用于 ",[21,11386,8387],{}," 过滤，也可以帮助排序和分组，但需要满足相应的顺序条件。",[18,11389,11390],{},"例如索引：",[118,11392,11393],{"className":7908,"code":10171,"language":7910,"meta":124,"style":124},[21,11394,11395],{"__ignoreMap":124},[142,11396,11397],{"class":144,"line":145},[142,11398,10171],{},[18,11400,10222],{},[118,11402,11404],{"className":7908,"code":11403,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE user_id = 100\nORDER BY created_at;\n",[21,11405,11406,11410,11414,11418],{"__ignoreMap":124},[142,11407,11408],{"class":144,"line":145},[142,11409,9444],{},[142,11411,11412],{"class":144,"line":151},[142,11413,9449],{},[142,11415,11416],{"class":144,"line":157},[142,11417,8499],{},[142,11419,11420],{"class":144,"line":163},[142,11421,11422],{},"ORDER BY created_at;\n",[18,11424,11425,11426,11428,11429,11431],{},"通常可以利用索引中同一 ",[21,11427,10891],{}," 下 ",[21,11430,10490],{}," 有序的特点。",[18,11433,11434],{},"但下面的查询未限定最左列：",[118,11436,11438],{"className":7908,"code":11437,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nORDER BY created_at;\n",[21,11439,11440,11444,11448],{"__ignoreMap":124},[142,11441,11442],{"class":144,"line":145},[142,11443,9444],{},[142,11445,11446],{"class":144,"line":151},[142,11447,9449],{},[142,11449,11450],{"class":144,"line":157},[142,11451,11422],{},[18,11453,11454,11456],{},[21,11455,10490],{}," 在整棵联合索引中并不是全局连续有序，通常无法直接利用该索引消除排序。",[18,11458,11459],{},"以下情况也可能无法直接使用索引顺序：",[99,11461,11462,11465,11468,11471,11474],{},[102,11463,11464],{},"排序列顺序与联合索引不匹配；",[102,11466,11467],{},"联合索引中，排序列前面存在没有被固定为常量的索引列；",[102,11469,11470],{},"对排序列执行表达式或函数；",[102,11472,11473],{},"多张表连接后按非驱动表字段排序；",[102,11475,11476],{},"混合升降序与索引定义不匹配。",[192,11478,11479],{"id":11479},"过滤条件如何影响索引顺序",[18,11481,10301],{},[118,11483,11484],{"className":7908,"code":10213,"language":7910,"meta":124,"style":124},[21,11485,11486],{"__ignoreMap":124},[142,11487,11488],{"class":144,"line":145},[142,11489,10213],{},[18,11491,11492],{},"下面的查询可以利用索引顺序：",[118,11494,11496],{"className":7908,"code":11495,"language":7910,"meta":124,"style":124},"SELECT *\nFROM t\nWHERE a = 1\n AND b = 2\nORDER BY c;\n",[21,11497,11498,11502,11506,11510,11515],{"__ignoreMap":124},[142,11499,11500],{"class":144,"line":145},[142,11501,9444],{},[142,11503,11504],{"class":144,"line":151},[142,11505,10236],{},[142,11507,11508],{"class":144,"line":157},[142,11509,10241],{},[142,11511,11512],{"class":144,"line":163},[142,11513,11514],{}," AND b = 2\n",[142,11516,11517],{"class":144,"line":169},[142,11518,11519],{},"ORDER BY c;\n",[18,11521,11522,11523,11525,11526,11528],{},"因为 ",[21,11524,10054],{}," 都固定为常量，剩余记录天然按照 ",[21,11527,10058],{}," 排序：",[118,11530,11533],{"className":11531,"code":11532,"language":123,"meta":124},[121],"(a=1, b=2, c=1)\n(a=1, b=2, c=2)\n(a=1, b=2, c=3)\n",[21,11534,11532],{"__ignoreMap":124},[18,11536,11537,11538,3639],{},"如果只固定 ",[21,11539,77],{},[118,11541,11543],{"className":7908,"code":11542,"language":7910,"meta":124,"style":124},"SELECT *\nFROM t\nWHERE a = 1\nORDER BY c;\n",[21,11544,11545,11549,11553,11557],{"__ignoreMap":124},[142,11546,11547],{"class":144,"line":145},[142,11548,9444],{},[142,11550,11551],{"class":144,"line":151},[142,11552,10236],{},[142,11554,11555],{"class":144,"line":157},[142,11556,10241],{},[142,11558,11559],{"class":144,"line":163},[142,11560,11519],{},[18,11562,11563,11564,11566,11567,11569,11570,11528],{},"索引记录先按照 ",[21,11565,10261],{}," 排序，再在相同 ",[21,11568,10261],{}," 中按照 ",[21,11571,10058],{},[118,11573,11576],{"className":11574,"code":11575,"language":123,"meta":124},[121],"(a=1, b=1, c=1)\n(a=1, b=1, c=9)\n(a=1, b=2, c=2)\n(a=1, b=2, c=8)\n",[21,11577,11575],{"__ignoreMap":124},[18,11579,11580,11581,11583,11584,11587,11588,52],{},"从整体看，",[21,11582,10058],{}," 的顺序是 ",[21,11585,11586],{},"1、9、2、8","，并不是全局有序，因此通常仍需 ",[21,11589,11590],{},"filesort",[18,11592,11593],{},"范围条件也可能产生类似效果：",[118,11595,11597],{"className":7908,"code":11596,"language":7910,"meta":124,"style":124},"SELECT *\nFROM t\nWHERE a = 1\n AND b > 10\nORDER BY c;\n",[21,11598,11599,11603,11607,11611,11615],{"__ignoreMap":124},[142,11600,11601],{"class":144,"line":145},[142,11602,9444],{},[142,11604,11605],{"class":144,"line":151},[142,11606,10236],{},[142,11608,11609],{"class":144,"line":157},[142,11610,10241],{},[142,11612,11613],{"class":144,"line":163},[142,11614,10246],{},[142,11616,11617],{"class":144,"line":169},[142,11618,11519],{},[18,11620,11621,11622,11624,11625,11627,11628,11630,11631,11633],{},"扫描结果首先按不同的 ",[21,11623,10261],{}," 值分组，每个 ",[21,11626,10261],{}," 内部才按 ",[21,11629,10058],{}," 排序，所以不能直接保证全局 ",[21,11632,10058],{}," 有序。",[192,11635,11636],{"id":11636},"为什么按非驱动表字段排序通常需要额外排序",[18,11638,11639],{},"假设查询：",[118,11641,11643],{"className":7908,"code":11642,"language":7910,"meta":124,"style":124},"SELECT o.id, u.name\nFROM orders o\nJOIN users u ON u.id = o.user_id\nWHERE o.created_at >= '2026-07-01'\nORDER BY u.name;\n",[21,11644,11645,11650,11655,11660,11665],{"__ignoreMap":124},[142,11646,11647],{"class":144,"line":145},[142,11648,11649],{},"SELECT o.id, u.name\n",[142,11651,11652],{"class":144,"line":151},[142,11653,11654],{},"FROM orders o\n",[142,11656,11657],{"class":144,"line":157},[142,11658,11659],{},"JOIN users u ON u.id = o.user_id\n",[142,11661,11662],{"class":144,"line":163},[142,11663,11664],{},"WHERE o.created_at >= '2026-07-01'\n",[142,11666,11667],{"class":144,"line":169},[142,11668,11669],{},"ORDER BY u.name;\n",[18,11671,11672,11673,11676,11677,11680,11681,11683],{},"假设优化器选择 ",[21,11674,11675],{},"orders"," 作为第一个非 ",[21,11678,11679],{},"const"," 表，也就是先按订单时间读取订单，再逐条根据 ",[21,11682,10891],{}," 查询用户：",[118,11685,11688],{"className":11686,"code":11687,"language":123,"meta":124},[121],"按 orders.created_at 读取订单\n ↓\n逐条查找对应 users\n ↓\n得到的 u.name 没有全局顺序\n ↓\n对连接结果执行 filesort\n",[21,11689,11687],{"__ignoreMap":124},[18,11691,11692,11693,11696,11697,11700],{},"即使 ",[21,11694,11695],{},"users.name"," 上有索引，这个索引也只保证从 ",[21,11698,11699],{},"users"," 出发扫描时的姓名顺序，不能保证“先读取订单、再查用户”得到的连接结果按姓名有序。",[18,11702,11703,11704,11706,11707,11709,11710,11713],{},"如果优化器能够把 ",[21,11705,11699],{}," 调整为驱动表，并且从 ",[21,11708,11695],{}," 索引按顺序读取，再连接订单，就可能利用该顺序。但是否能够这样执行，还取决于过滤条件、连接关系、成本估算和 ",[21,11711,11712],{},"LIMIT"," 等因素。",[192,11715,11716],{"id":11716},"索引方向与查询方向如何匹配",[18,11718,11719],{},"MySQL 8.0 支持降序索引，也支持反向扫描 B+ 树索引。",[18,11721,11722],{},"索引：",[118,11724,11726],{"className":7908,"code":11725,"language":7910,"meta":124,"style":124},"KEY idx_ab (a ASC, b ASC)\n",[21,11727,11728],{"__ignoreMap":124},[142,11729,11730],{"class":144,"line":145},[142,11731,11725],{},[18,11733,11734],{},"通常可以支持：",[118,11736,11738],{"className":7908,"code":11737,"language":7910,"meta":124,"style":124},"ORDER BY a ASC, b ASC\nORDER BY a DESC, b DESC\n",[21,11739,11740,11745],{"__ignoreMap":124},[142,11741,11742],{"class":144,"line":145},[142,11743,11744],{},"ORDER BY a ASC, b ASC\n",[142,11746,11747],{"class":144,"line":151},[142,11748,11749],{},"ORDER BY a DESC, b DESC\n",[18,11751,11752],{},"第二条可以通过整体反向扫描完成。",[18,11754,11755],{},"但混合方向：",[118,11757,11759],{"className":7908,"code":11758,"language":7910,"meta":124,"style":124},"ORDER BY a ASC, b DESC\n",[21,11760,11761],{"__ignoreMap":124},[142,11762,11763],{"class":144,"line":145},[142,11764,11758],{},[18,11766,11767,11768,11771],{},"与 ",[21,11769,11770],{},"(a ASC, b ASC)"," 的排序关系不同。要直接使用索引顺序，应建立方向相匹配的索引：",[118,11773,11775],{"className":7908,"code":11774,"language":7910,"meta":124,"style":124},"KEY idx_ab_mixed (a ASC, b DESC)\n",[21,11776,11777],{"__ignoreMap":124},[142,11778,11779],{"class":144,"line":145},[142,11780,11774],{},[18,11782,11783],{},"这个索引也可以通过整体反向扫描支持：",[118,11785,11787],{"className":7908,"code":11786,"language":7910,"meta":124,"style":124},"ORDER BY a DESC, b ASC\n",[21,11788,11789],{"__ignoreMap":124},[142,11790,11791],{"class":144,"line":145},[142,11792,11786],{},[18,11794,11795],{},"所以更准确的规则是：",[63,11797,11798],{},[18,11799,11800],{},"所有列同向时，升序索引可以正向或反向扫描；升降序混合时，索引各列的方向关系需要与查询一致，或者与查询整体相反。",[18,11802,11803,11804,11807],{},"MySQL 5.7 及更早版本虽然允许在索引定义中书写 ",[21,11805,11806],{},"DESC","，但通常不会真正按降序存储键值。讨论索引方向时必须结合实际 MySQL 版本。",[18,11809,227,11810,11812,11813,11816,11817,52],{},[21,11811,10119],{}," 的 ",[21,11814,11815],{},"Extra"," 中可能出现 ",[21,11818,11195],{},[18,11820,11821,11822,11824],{},"需要注意，",[21,11823,11195],{}," 表示没有直接利用索引顺序完成排序，并不保证真的使用磁盘文件；数据较小时也可能在内存中排序。",[14,11826,11828],{"id":11827},"十一索引统计信息不准确","十一、索引统计信息不准确",[18,11830,11831],{},"MySQL 优化器依赖统计信息估算：",[99,11833,11834,11837,11840,11843],{},[102,11835,11836],{},"条件会命中多少行；",[102,11838,11839],{},"不同索引的选择性；",[102,11841,11842],{},"扫描和回表成本；",[102,11844,11845],{},"JOIN 的顺序及成本。",[18,11847,11848],{},"如果数据分布发生剧烈变化，而统计信息未能反映真实情况，优化器可能选错索引或改用全表扫描。",[18,11850,11851],{},"可以先通过执行计划验证估算行数与实际行数是否偏差明显，再根据情况评估：",[118,11853,11855],{"className":7908,"code":11854,"language":7910,"meta":124,"style":124},"ANALYZE TABLE orders;\n",[21,11856,11857],{"__ignoreMap":124},[142,11858,11859],{"class":144,"line":145},[142,11860,11854],{},[18,11862,11863],{},"MySQL 8.0 还可以使用直方图帮助优化器理解非索引列或数据分布不均匀字段的值分布。",[18,11865,11866],{},"不要在没有验证的情况下频繁更新统计信息，也不要把所有执行计划问题都归因于统计信息。",[14,11868,11870],{"id":11869},"十二如何用-explain-判断","十二、如何用 EXPLAIN 判断",[18,11872,11873],{},"基础排查可以执行：",[118,11875,11877],{"className":7908,"code":11876,"language":7910,"meta":124,"style":124},"EXPLAIN\nSELECT *\nFROM orders\nWHERE user_id = 100;\n",[21,11878,11879,11884,11888,11892],{"__ignoreMap":124},[142,11880,11881],{"class":144,"line":145},[142,11882,11883],{},"EXPLAIN\n",[142,11885,11886],{"class":144,"line":151},[142,11887,9444],{},[142,11889,11890],{"class":144,"line":157},[142,11891,9449],{},[142,11893,11894],{"class":144,"line":163},[142,11895,11896],{},"WHERE user_id = 100;\n",[18,11898,11899],{},"重点观察：",[341,11901,11902,11911],{},[344,11903,11904],{},[347,11905,11906,11908],{},[350,11907,2047],{},[350,11909,11910],{},"关注点",[360,11912,11913,11922,11931,11941,11963,11973,11983],{},[347,11914,11915,11919],{},[365,11916,11917],{},[21,11918,10115],{},[365,11920,11921],{},"理论上可能使用哪些索引",[347,11923,11924,11928],{},[365,11925,11926],{},[21,11927,10126],{},[365,11929,11930],{},"优化器最终选择了哪个索引",[347,11932,11933,11938],{},[365,11934,11935],{},[21,11936,11937],{},"key_len",[365,11939,11940],{},"实际使用的索引长度，可辅助判断联合索引用到哪一部分",[347,11942,11943,11947],{},[365,11944,11945],{},[21,11946,10130],{},[365,11948,11949,11950,5196,11952,5196,11955,5196,11958,5196,11960],{},"访问方式，如 ",[21,11951,11679],{},[21,11953,11954],{},"ref",[21,11956,11957],{},"range",[21,11959,10880],{},[21,11961,11962],{},"ALL",[347,11964,11965,11970],{},[365,11966,11967],{},[21,11968,11969],{},"rows",[365,11971,11972],{},"预计需要检查的行数",[347,11974,11975,11980],{},[365,11976,11977],{},[21,11978,11979],{},"filtered",[365,11981,11982],{},"经过表条件过滤后预计保留的百分比",[347,11984,11985,11989],{},[365,11986,11987],{},[21,11988,11815],{},[365,11990,11991],{},"是否覆盖索引、ICP、额外排序或临时表等",[192,11993,11995,11996,11998],{"id":11994},"_1-type-到底表示什么","1. ",[21,11997,10130],{}," 到底表示什么",[18,12000,12001,12003,12004,12007,12008,52],{},[21,12002,10130],{}," 表示 MySQL 访问当前表中记录的方式。在 ",[21,12005,12006],{},"EXPLAIN FORMAT=JSON"," 中，对应字段名是 ",[21,12009,12010],{},"access_type",[18,12012,12013],{},"它回答的不是“有没有索引”这么简单，而是：",[63,12015,12016],{},[18,12017,12018],{},"MySQL 准备通过唯一键直接取一行、按普通索引查一组记录、扫描一个索引范围，还是扫描整棵索引或整张表？",[18,12020,12021],{},"官方文档通常按照下面的顺序描述常见访问类型：",[118,12023,12026],{"className":12024,"code":12025,"language":123,"meta":124},[121],"system\n ↓\nconst\n ↓\neq_ref\n ↓\nref\n ↓\nrange\n ↓\nindex\n ↓\nALL\n",[21,12027,12025],{"__ignoreMap":124},[18,12029,12030],{},"越靠前通常代表定位越精确，但这不是脱离数据量的绝对性能排名。",[18,12032,1263],{},[99,12034,12035,12041,12049,12054],{},[102,12036,12037,12038,12040],{},"小表使用 ",[21,12039,11962],{}," 可能只扫描几十行，成本很低；",[102,12042,12043,12045,12046,12048],{},[21,12044,11954],{}," 虽然比 ",[21,12047,11957],{}," 靠前，但如果某个值匹配几十万行，仍然可能很慢；",[102,12050,12051,12053],{},[21,12052,11957],{}," 如果只扫描十行，通常会非常高效；",[102,12055,12056,12058],{},[21,12057,10880],{}," 虽然使用了索引，却可能把整个索引扫描一遍。",[18,12060,12061,12062,12064,12065,12068],{},"所以查看 ",[21,12063,10130],{}," 后，还必须结合 ",[21,12066,12067],{},"key、rows、filtered、Extra"," 以及实际耗时判断。",[192,12070,12072,12073,12076],{"id":12071},"_2-system表中只有一行","2. ",[21,12074,12075],{},"system","：表中只有一行",[18,12078,12079,303,12081,12083],{},[21,12080,12075],{},[21,12082,11679],{}," 的特殊情况，表示优化器判断当前表只有一行。",[18,12085,12086],{},"访问过程可以理解为：",[118,12088,12091],{"className":12089,"code":12090,"language":123,"meta":124},[121],"整张表只有一行\n ↓\n直接读取这一行\n",[21,12092,12090],{"__ignoreMap":124},[18,12094,12095,12096,12098],{},"它在普通 InnoDB 业务表的执行计划中并不常见。看到 ",[21,12097,12075],{}," 时，不需要把它理解成某种特殊索引；它表达的是表规模已经确定为单行，因此没有查找范围可言。",[192,12100,5702,12102,12104],{"id":12101},"_3-const通过主键或唯一键最多定位一行",[21,12103,11679],{},"：通过主键或唯一键最多定位一行",[18,12106,12107,12109],{},[21,12108,11679],{}," 表示当前表最多只有一条记录满足条件，并且这条记录在查询开始时只需要读取一次。",[18,12111,12112],{},"典型场景是使用常量匹配主键或完整唯一索引：",[118,12114,12116],{"className":7908,"code":12115,"language":7910,"meta":124,"style":124},"CREATE TABLE users (\n id BIGINT PRIMARY KEY,\n email VARCHAR(128) NOT NULL,\n UNIQUE KEY uk_email (email)\n);\n",[21,12117,12118,12123,12128,12133,12138],{"__ignoreMap":124},[142,12119,12120],{"class":144,"line":145},[142,12121,12122],{},"CREATE TABLE users (\n",[142,12124,12125],{"class":144,"line":151},[142,12126,12127],{}," id BIGINT PRIMARY KEY,\n",[142,12129,12130],{"class":144,"line":157},[142,12131,12132],{}," email VARCHAR(128) NOT NULL,\n",[142,12134,12135],{"class":144,"line":163},[142,12136,12137],{}," UNIQUE KEY uk_email (email)\n",[142,12139,12140],{"class":144,"line":169},[142,12141,12142],{},");\n",[18,12144,12145],{},"查询主键：",[118,12147,12149],{"className":7908,"code":12148,"language":7910,"meta":124,"style":124},"SELECT *\nFROM users\nWHERE id = 100;\n",[21,12150,12151,12155,12159],{"__ignoreMap":124},[142,12152,12153],{"class":144,"line":145},[142,12154,9444],{},[142,12156,12157],{"class":144,"line":151},[142,12158,9726],{},[142,12160,12161],{"class":144,"line":157},[142,12162,12163],{},"WHERE id = 100;\n",[18,12165,12166],{},"或者查询唯一键：",[118,12168,12170],{"className":7908,"code":12169,"language":7910,"meta":124,"style":124},"SELECT *\nFROM users\nWHERE email = 'tom@example.com';\n",[21,12171,12172,12176,12180],{"__ignoreMap":124},[142,12173,12174],{"class":144,"line":145},[142,12175,9444],{},[142,12177,12178],{"class":144,"line":151},[142,12179,9726],{},[142,12181,12182],{"class":144,"line":157},[142,12183,12184],{},"WHERE email = 'tom@example.com';\n",[18,12186,12187],{},"由于主键或唯一键能够保证最多返回一行，MySQL 可以直接定位目标记录：",[118,12189,12192],{"className":12190,"code":12191,"language":123,"meta":124},[121],"常量值\n ↓\n主键或唯一索引查找\n ↓\n最多一条记录\n",[21,12193,12191],{"__ignoreMap":124},[18,12195,12196,12197,3639],{},"如果是联合唯一索引，需要把能够确定唯一记录的索引列完整匹配，才容易形成 ",[21,12198,11679],{},[118,12200,12202],{"className":7908,"code":12201,"language":7910,"meta":124,"style":124},"UNIQUE KEY uk_tenant_order (tenant_id, order_no)\n",[21,12203,12204],{"__ignoreMap":124},[142,12205,12206],{"class":144,"line":145},[142,12207,12201],{},[118,12209,12211],{"className":7908,"code":12210,"language":7910,"meta":124,"style":124},"WHERE tenant_id = 10\n AND order_no = 'A1001'\n",[21,12212,12213,12218],{"__ignoreMap":124},[142,12214,12215],{"class":144,"line":145},[142,12216,12217],{},"WHERE tenant_id = 10\n",[142,12219,12220],{"class":144,"line":151},[142,12221,12222],{}," AND order_no = 'A1001'\n",[18,12224,12225],{},"如果只查询：",[118,12227,12228],{"className":7908,"code":12217,"language":7910,"meta":124,"style":124},[21,12229,12230],{"__ignoreMap":124},[142,12231,12232],{"class":144,"line":145},[142,12233,12217],{},[18,12235,12236,12237,52],{},"可能返回多行，通常就不是 ",[21,12238,11679],{},[18,12240,12241,12243],{},[21,12242,11679],{}," 的核心不是“使用了等号”，而是：",[63,12245,12246],{},[18,12247,12248],{},"通过常量和唯一约束，能够确定当前表最多只返回一条记录。",[192,12250,12252,12253,12256],{"id":12251},"_4-eq_refjoin-时每条前表记录最多匹配一行","4. ",[21,12254,12255],{},"eq_ref","：JOIN 时每条前表记录最多匹配一行",[18,12258,12259,12261],{},[21,12260,12255],{}," 最常见于多表 JOIN。",[18,12263,12264,12265,12268],{},"它表示对于前面表产生的每一条记录，MySQL 都通过主键或 ",[21,12266,12267],{},"UNIQUE NOT NULL"," 索引，在当前表中最多查到一条记录。",[18,12270,1263],{},[118,12272,12274],{"className":7908,"code":12273,"language":7910,"meta":124,"style":124},"CREATE TABLE orders (\n id BIGINT PRIMARY KEY,\n user_id BIGINT NOT NULL,\n KEY idx_user_id (user_id)\n);\n",[21,12275,12276,12281,12285,12290,12295],{"__ignoreMap":124},[142,12277,12278],{"class":144,"line":145},[142,12279,12280],{},"CREATE TABLE orders (\n",[142,12282,12283],{"class":144,"line":151},[142,12284,12127],{},[142,12286,12287],{"class":144,"line":157},[142,12288,12289],{}," user_id BIGINT NOT NULL,\n",[142,12291,12292],{"class":144,"line":163},[142,12293,12294],{}," KEY idx_user_id (user_id)\n",[142,12296,12297],{"class":144,"line":169},[142,12298,12142],{},[118,12300,12302],{"className":7908,"code":12301,"language":7910,"meta":124,"style":124},"SELECT o.id, u.name\nFROM orders o\nJOIN users u ON u.id = o.user_id;\n",[21,12303,12304,12308,12312],{"__ignoreMap":124},[142,12305,12306],{"class":144,"line":145},[142,12307,11649],{},[142,12309,12310],{"class":144,"line":151},[142,12311,11654],{},[142,12313,12314],{"class":144,"line":157},[142,12315,12316],{},"JOIN users u ON u.id = o.user_id;\n",[18,12318,12319,12320,12322,12323,10047,12326,3639],{},"假设执行顺序是先读取 ",[21,12321,11675],{},"，再根据 ",[21,12324,12325],{},"o.user_id",[21,12327,11699],{},[118,12329,12332],{"className":12330,"code":12331,"language":123,"meta":124},[121],"orders 的一条记录\n ↓\nu.id = o.user_id\n ↓\n通过 users 主键最多定位一行\n",[21,12333,12331],{"__ignoreMap":124},[18,12335,227,12336,12338,12339,52],{},[21,12337,11699],{}," 表的访问类型可能是 ",[21,12340,12255],{},[18,12342,12343,1441,12345,12347],{},[21,12344,11679],{},[21,12346,12255],{}," 的区别是：",[341,12349,12350,12363],{},[344,12351,12352],{},[347,12353,12354,12357,12360],{},[350,12355,12356],{},"类型",[350,12358,12359],{},"查找值来自哪里",[350,12361,12362],{},"典型场景",[360,12364,12365,12379],{},[347,12366,12367,12371,12374],{},[365,12368,12369],{},[21,12370,11679],{},[365,12372,12373],{},"SQL 中的常量",[365,12375,12376],{},[21,12377,12378],{},"WHERE id = 100",[347,12380,12381,12385,12388],{},[365,12382,12383],{},[21,12384,12255],{},[365,12386,12387],{},"前面表的列值",[365,12389,12390],{},[21,12391,12392],{},"u.id = o.user_id",[192,12394,4439,12396,12398],{"id":12395},"_5-ref通过非唯一索引等值查找一组记录",[21,12397,11954],{},"：通过非唯一索引等值查找一组记录",[18,12400,12401,12403],{},[21,12402,11954],{}," 表示使用普通索引或联合索引的非唯一前缀进行等值查找，可能返回多条具有相同索引值的记录。",[18,12405,1263],{},[118,12407,12408],{"className":7908,"code":10978,"language":7910,"meta":124,"style":124},[21,12409,12410],{"__ignoreMap":124},[142,12411,12412],{"class":144,"line":145},[142,12413,10978],{},[118,12415,12416],{"className":7908,"code":11320,"language":7910,"meta":124,"style":124},[21,12417,12418,12422,12426],{"__ignoreMap":124},[142,12419,12420],{"class":144,"line":145},[142,12421,9444],{},[142,12423,12424],{"class":144,"line":151},[142,12425,9449],{},[142,12427,12428],{"class":144,"line":157},[142,12429,11335],{},[18,12431,3660,12432,12435],{},[21,12433,12434],{},"status=1"," 对应多条订单，访问过程是：",[118,12437,12440],{"className":12438,"code":12439,"language":123,"meta":124},[121],"在 idx_status 中定位 status=1 的起点\n ↓\n连续读取所有 status=1 的索引记录\n ↓\n按需回表\n",[21,12441,12439],{"__ignoreMap":124},[18,12443,12444,12445,12447],{},"因此，",[21,12446,11954],{}," 不代表只读取一行。它可能读取几行，也可能读取几十万行，实际成本取决于索引选择性和回表数量。",[18,12449,12450,12451,3639],{},"联合索引只使用左侧一部分时，也可能出现 ",[21,12452,11954],{},[118,12454,12456],{"className":7908,"code":12455,"language":7910,"meta":124,"style":124},"KEY idx_tenant_status (tenant_id, status)\n",[21,12457,12458],{"__ignoreMap":124},[142,12459,12460],{"class":144,"line":145},[142,12461,12455],{},[118,12463,12464],{"className":7908,"code":12217,"language":7910,"meta":124,"style":124},[21,12465,12466],{"__ignoreMap":124},[142,12467,12468],{"class":144,"line":145},[142,12469,12217],{},[18,12471,12472],{},"虽然使用了索引最左列，但同一个租户可能有大量记录，所以仍然是非唯一匹配。",[18,12474,12475,12476,3639],{},"JOIN 中如果使用普通索引关联，也常见 ",[21,12477,11954],{},[118,12479,12481],{"className":7908,"code":12480,"language":7910,"meta":124,"style":124},"SELECT *\nFROM users u\nJOIN orders o ON o.user_id = u.id;\n",[21,12482,12483,12487,12492],{"__ignoreMap":124},[142,12484,12485],{"class":144,"line":145},[142,12486,9444],{},[142,12488,12489],{"class":144,"line":151},[142,12490,12491],{},"FROM users u\n",[142,12493,12494],{"class":144,"line":157},[142,12495,12496],{},"JOIN orders o ON o.user_id = u.id;\n",[18,12498,12499,12500,12503,12504,12506,12507,12509,12510,52],{},"对于每个用户，普通索引 ",[21,12501,12502],{},"orders.idx_user_id"," 可能匹配多条订单，因此 ",[21,12505,11675],{}," 的访问类型可能是 ",[21,12508,11954],{},"，而不是 ",[21,12511,12255],{},[192,12513,12515,12516,12518],{"id":12514},"_6-range扫描索引中的一个或多个区间","6. ",[21,12517,11957],{},"：扫描索引中的一个或多个区间",[18,12520,12521,12523],{},[21,12522,11957],{}," 表示 MySQL 先根据条件确定一个或多个索引区间，然后只扫描这些区间中的记录。",[18,12525,12526],{},"典型范围查询：",[118,12528,12530],{"className":7908,"code":12529,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE created_at >= '2026-07-01'\n AND created_at \u003C '2026-08-01';\n",[21,12531,12532,12536,12540,12545],{"__ignoreMap":124},[142,12533,12534],{"class":144,"line":145},[142,12535,9444],{},[142,12537,12538],{"class":144,"line":151},[142,12539,9449],{},[142,12541,12542],{"class":144,"line":157},[142,12543,12544],{},"WHERE created_at >= '2026-07-01'\n",[142,12546,12547],{"class":144,"line":163},[142,12548,12549],{}," AND created_at \u003C '2026-08-01';\n",[18,12551,12552],{},"索引访问过程可以理解为：",[118,12554,12557],{"className":12555,"code":12556,"language":123,"meta":124},[121],"定位 2026-07-01 的索引位置\n ↓\n沿叶子节点向后扫描\n ↓\n到达 2026-08-01 时停止\n",[21,12558,12556],{"__ignoreMap":124},[18,12560,12561,12562,12564],{},"常见能够形成 ",[21,12563,11957],{}," 的条件包括：",[99,12566,12567,12577,12581,12587,12591,12596],{},[102,12568,12569,5196,12571,5196,12573,5196,12575,1191],{},[21,12570,9489],{},[21,12572,9492],{},[21,12574,9495],{},[21,12576,9498],{},[102,12578,12579,1191],{},[21,12580,9503],{},[102,12582,12583,12586],{},[21,12584,12585],{},"IN (...)"," 形成多个离散范围；",[102,12588,12589,1191],{},[21,12590,11309],{},[102,12592,12593,12594,1191],{},"能确定前缀范围的 ",[21,12595,9509],{},[102,12597,12598,12599,12602],{},"某些 ",[21,12600,12601],{},"\u003C>"," 或其他可转化为索引区间的条件。",[18,12604,1263],{},[118,12606,12608],{"className":7908,"code":12607,"language":7910,"meta":124,"style":124},"WHERE id IN (10, 20, 30)\n",[21,12609,12610],{"__ignoreMap":124},[142,12611,12612],{"class":144,"line":145},[142,12613,12607],{},[18,12615,12616,12617,12619,12620,52],{},"虽然使用的是多个等值条件，优化器也可能把它组织成多个索引范围，因此 ",[21,12618,10130],{}," 显示为 ",[21,12621,11957],{},[18,12623,12624],{},"具体来说，范围优化器可以把：",[118,12626,12627],{"className":7908,"code":12607,"language":7910,"meta":124,"style":124},[21,12628,12629],{"__ignoreMap":124},[142,12630,12631],{"class":144,"line":145},[142,12632,12607],{},[18,12634,12635],{},"转换为同一个索引上的三个单点区间：",[118,12637,12640],{"className":12638,"code":12639,"language":123,"meta":124},[121],"[10, 10]\n∪\n[20, 20]\n∪\n[30, 30]\n",[21,12641,12639],{"__ignoreMap":124},[18,12643,12644,12645,12647,12648,12651],{},"执行时并不是从 ",[21,12646,1958],{}," 一直扫描到 ",[21,12649,12650],{},"30","，而是分别在同一棵 B+ 树中定位这些单点范围，再合并访问结果：",[118,12653,12656],{"className":12654,"code":12655,"language":123,"meta":124},[121],"定位 id=10\n定位 id=20\n定位 id=30\n ↓\n返回三个范围的记录\n",[21,12657,12655],{"__ignoreMap":124},[18,12659,12660,12661,12663,12664,52],{},"因此，SQL 语义上虽然是多个等值条件，物理访问方式仍属于“扫描一个或多个索引范围”，",[21,12662,10130],{}," 可以显示为 ",[21,12665,11957],{},[18,12667,12668],{},"这与 Index Merge 不同：",[99,12670,12671,12681],{},[102,12672,12673,12676,12677,12680],{},[21,12674,12675],{},"IN (10,20,30)"," 通常是在",[68,12678,12679],{},"同一个索引","上构造多个范围；",[102,12682,12683,12684,12687],{},"Index Merge 是扫描",[68,12685,12686],{},"同一张表的多个索引","，再合并结果。",[18,12689,12690,12692],{},[21,12691,11957],{}," 是否高效，主要看范围大小：",[118,12694,12697],{"className":12695,"code":12696,"language":123,"meta":124},[121],"扫描 10 条索引记录 → 通常很快\n扫描 80 万条索引记录 → 仍可能很慢\n",[21,12698,12696],{"__ignoreMap":124},[18,12700,12701,12702,12704],{},"所以不能看到 ",[21,12703,11957],{}," 就直接认定 SQL 已经优化完成。",[192,12706,12708],{"id":12707},"_7-icp在回表前用索引中的字段过滤","7. ICP：在回表前用索引中的字段过滤",[18,12710,12711],{},"ICP 全称是 Index Condition Pushdown，中文通常称为“索引条件下推”。",[18,12713,12714],{},"仍然使用联合索引：",[118,12716,12717],{"className":7908,"code":10213,"language":7910,"meta":124,"style":124},[21,12718,12719],{"__ignoreMap":124},[142,12720,12721],{"class":144,"line":145},[142,12722,10213],{},[18,12724,10222],{},[118,12726,12727],{"className":7908,"code":10225,"language":7910,"meta":124,"style":124},[21,12728,12729,12733,12737,12741,12745],{"__ignoreMap":124},[142,12730,12731],{"class":144,"line":145},[142,12732,9444],{},[142,12734,12735],{"class":144,"line":151},[142,12736,10236],{},[142,12738,12739],{"class":144,"line":157},[142,12740,10241],{},[142,12742,12743],{"class":144,"line":163},[142,12744,10246],{},[142,12746,12747],{"class":144,"line":169},[142,12748,10251],{},[18,12750,12751,12753,12754,12756],{},[21,12752,10257],{}," 可以确定索引扫描范围，但 ",[21,12755,10265],{}," 通常不能继续缩小这个连续范围。",[18,12758,12759],{},"没有 ICP 时，过程近似为：",[118,12761,12764],{"className":12762,"code":12763,"language":123,"meta":124},[121],"扫描满足 a=1、b>10 的二级索引记录\n ↓\n每一条都根据主键回表\n ↓\n取得完整行后判断 c=3\n",[21,12765,12763],{"__ignoreMap":124},[18,12767,12768,12769,12771,12772,3639],{},"开启 ICP 后，由于 ",[21,12770,10058],{}," 也存储在联合索引中，存储引擎可以先检查索引记录中的 ",[21,12773,10058],{},[118,12775,12778],{"className":12776,"code":12777,"language":123,"meta":124},[121],"扫描满足 a=1、b>10 的二级索引记录\n ↓\n直接在索引记录中判断 c=3\n ├─ 不满足：跳过，不回表\n └─ 满足：根据主键回表\n",[21,12779,12777],{"__ignoreMap":124},[18,12781,12782],{},"它的主要收益是：",[63,12784,12785],{},[18,12786,12787],{},"减少不必要的聚簇索引回表，而不是进一步缩小最初的索引扫描范围。",[18,12789,11014,12790,11812,12792,12794],{},[21,12791,10119],{},[21,12793,11815],{}," 中通常显示：",[118,12796,12799],{"className":12797,"code":12798,"language":123,"meta":124},[121],"Using index condition\n",[21,12800,12798],{"__ignoreMap":124},[18,12802,12803],{},"ICP 与覆盖索引也不同：",[99,12805,12806,12809],{},[102,12807,12808],{},"ICP：仍可能需要回表，只是先在索引层过滤；",[102,12810,12811,12812,12814,12815,52],{},"覆盖索引：查询所需数据全部在索引中，最终也不需要回表，",[21,12813,11815],{}," 常见 ",[21,12816,12817],{},"Using index",[18,12819,12820],{},"只有能够利用当前索引记录判断的条件，才适合下推到存储引擎；依赖其他表、存储函数或无法从索引记录取得的数据，通常不能这样处理。",[192,12822,12824,12825,12827],{"id":12823},"_8-index把整棵索引扫描一遍","8. ",[21,12826,10880],{},"：把整棵索引扫描一遍",[18,12829,12830,12832],{},[21,12831,10880],{}," 很容易被误解为“查询已经通过索引精准定位”。",[18,12834,12835,12836,12839],{},"实际上，",[21,12837,12838],{},"type=index"," 通常表示：",[63,12841,12842],{},[18,12843,12844],{},"MySQL 没有通过索引条件缩小扫描区间，而是把选中的整棵索引从头到尾扫描一遍。",[18,12846,12847,12848,12850],{},"它与 ",[21,12849,11962],{}," 的共同点是都可能读取全部记录；区别在于：",[99,12852,12853,12858],{},[102,12854,12855,12857],{},[21,12856,10880],{}," 扫描索引树；",[102,12859,12860,12862],{},[21,12861,11962],{}," 扫描表数据。",[18,12864,1263],{},[118,12866,12868],{"className":7908,"code":12867,"language":7910,"meta":124,"style":124},"KEY idx_user_id (user_id)\n",[21,12869,12870],{"__ignoreMap":124},[142,12871,12872],{"class":144,"line":145},[142,12873,12867],{},[118,12875,12877],{"className":7908,"code":12876,"language":7910,"meta":124,"style":124},"SELECT user_id\nFROM orders;\n",[21,12878,12879,12884],{"__ignoreMap":124},[142,12880,12881],{"class":144,"line":145},[142,12882,12883],{},"SELECT user_id\n",[142,12885,12886],{"class":144,"line":151},[142,12887,12888],{},"FROM orders;\n",[18,12890,12891,12892,12894,12895,12898],{},"如果查询只需要 ",[21,12893,10891],{},"，二级索引已经包含全部所需数据，MySQL 可以扫描更窄的 ",[21,12896,12897],{},"idx_user_id","，而不必扫描保存完整行的聚簇索引。",[18,12900,12901],{},"执行计划可能显示：",[118,12903,12906],{"className":12904,"code":12905,"language":123,"meta":124},[121],"type: index\nkey: idx_user_id\nExtra: Using index\n",[21,12907,12905],{"__ignoreMap":124},[18,12909,7750,12910,12912],{},[21,12911,12817],{}," 表示覆盖索引：查询需要的数据可以直接从索引取得，不需要回表。",[18,12914,12915],{},"另一个常见场景是利用索引顺序避免额外排序：",[118,12917,12919],{"className":7908,"code":12918,"language":7910,"meta":124,"style":124},"SELECT id\nFROM orders\nORDER BY created_at;\n",[21,12920,12921,12925,12929],{"__ignoreMap":124},[142,12922,12923],{"class":144,"line":145},[142,12924,9758],{},[142,12926,12927],{"class":144,"line":151},[142,12928,9449],{},[142,12930,12931],{"class":144,"line":157},[142,12932,11422],{},[18,12934,12935,12936,12938,12939,52],{},"如果存在适合的 ",[21,12937,10490],{}," 索引，优化器可能按索引顺序扫描全部记录，以避免 ",[21,12940,11590],{},[18,12942,12943,12945,12946,12948],{},[21,12944,10880],{}," 可能比 ",[21,12947,11962],{}," 快，因为二级索引通常更窄，缓存命中和读取的数据量更小；但它本质上仍是全索引扫描，数据量大时成本依然很高。",[192,12950,12952,12953,12955],{"id":12951},"_9-all扫描整张表","9. ",[21,12954,11962],{},"：扫描整张表",[18,12957,12958,12960],{},[21,12959,11962],{}," 表示全表扫描。",[18,12962,12963],{},"对于 InnoDB，可以把它近似理解为扫描保存完整行数据的聚簇索引：",[118,12965,12968],{"className":12966,"code":12967,"language":123,"meta":124},[121],"聚簇索引第一条记录\n ↓\n逐条向后读取\n ↓\n检查 WHERE 条件\n ↓\n直到最后一条记录\n",[21,12969,12967],{"__ignoreMap":124},[18,12971,12972],{},"典型原因包括：",[99,12974,12975,12978,12981,12985,12988,12991],{},[102,12976,12977],{},"查询条件没有可用索引；",[102,12979,12980],{},"在索引列上进行了导致无法定位的函数或转换；",[102,12982,12983,10085],{},[21,12984,10039],{},[102,12986,12987],{},"条件会返回表中大部分数据；",[102,12989,12990],{},"表很小，全表扫描成本更低；",[102,12992,12993],{},"优化器根据统计信息判断使用索引加回表更贵。",[18,12995,1263],{},[118,12997,12999],{"className":7908,"code":12998,"language":7910,"meta":124,"style":124},"SELECT *\nFROM orders\nWHERE remark LIKE '%manual%';\n",[21,13000,13001,13005,13009],{"__ignoreMap":124},[142,13002,13003],{"class":144,"line":145},[142,13004,9444],{},[142,13006,13007],{"class":144,"line":151},[142,13008,9449],{},[142,13010,13011],{"class":144,"line":157},[142,13012,13013],{},"WHERE remark LIKE '%manual%';\n",[18,13015,13016,13017,52],{},"普通 B+ 树索引无法按照任意位置包含关系定位，执行计划很可能是 ",[21,13018,11962],{},[18,13020,13021,13022,13024],{},"但 ",[21,13023,11962],{}," 不等于必须立刻创建索引。",[18,13026,13027],{},"如果表只有几十行，或者查询本来就要读取 80% 的数据，全表扫描可能是合理选择。真正需要关注的是：",[99,13029,13030,13033,13038,13041,13044],{},[102,13031,13032],{},"表有多大；",[102,13034,13035,13037],{},[21,13036,11969],{}," 预计扫描多少行；",[102,13039,13040],{},"查询执行频率多高；",[102,13042,13043],{},"是否处于 JOIN 的内层并被重复扫描；",[102,13045,13046],{},"实际耗时和资源消耗是否不可接受。",[18,13048,13049,13050,13052],{},"特别是在 JOIN 中，如果前表返回一万行，而后表对每条前表记录都执行一次 ",[21,13051,11962],{},"，成本可能被放大得非常严重。",[192,13054,13056],{"id":13055},"_10-常见类型对比","10. 常见类型对比",[341,13058,13059,13079],{},[344,13060,13061],{},[347,13062,13063,13067,13070,13073,13076],{},[350,13064,13065],{},[21,13066,10130],{},[350,13068,13069],{},"核心含义",[350,13071,13072],{"align":7654},"是否精准定位",[350,13074,13075],{"align":7654},"可能读取的记录数",[350,13077,13078],{},"常见场景",[360,13080,13081,13099,13119,13139,13162,13180],{},[347,13082,13083,13087,13090,13093,13096],{},[365,13084,13085],{},[21,13086,12075],{},[365,13088,13089],{},"表中只有一行",[365,13091,13092],{"align":7654},"无需查找",[365,13094,13095],{"align":7654},"1 行",[365,13097,13098],{},"单行表",[347,13100,13101,13105,13108,13111,13114],{},[365,13102,13103],{},[21,13104,11679],{},[365,13106,13107],{},"通过常量匹配主键或唯一键",[365,13109,13110],{"align":7654},"是",[365,13112,13113],{"align":7654},"最多 1 行",[365,13115,13116],{},[21,13117,13118],{},"WHERE id=100",[347,13120,13121,13125,13128,13131,13134],{},[365,13122,13123],{},[21,13124,11954],{},[365,13126,13127],{},"通过普通索引做等值查找",[365,13129,13130],{"align":7654},"是，但结果不唯一",[365,13132,13133],{"align":7654},"1 行到大量记录",[365,13135,13136],{},[21,13137,13138],{},"WHERE status=1",[347,13140,13141,13145,13148,13151,13154],{},[365,13142,13143],{},[21,13144,11957],{},[365,13146,13147],{},"扫描一个或多个索引区间",[365,13149,13150],{"align":7654},"定位区间",[365,13152,13153],{"align":7654},"取决于范围大小",[365,13155,13156,5196,13158,5196,13160],{},[21,13157,9503],{},[21,13159,10477],{},[21,13161,9489],{},[347,13163,13164,13168,13171,13174,13177],{},[365,13165,13166],{},[21,13167,10880],{},[365,13169,13170],{},"扫描整棵索引",[365,13172,13173],{"align":7654},"否",[365,13175,13176],{"align":7654},"通常为整个索引",[365,13178,13179],{},"覆盖索引全扫描、按索引顺序遍历",[347,13181,13182,13186,13189,13191,13194],{},[365,13183,13184],{},[21,13185,11962],{},[365,13187,13188],{},"扫描整张表",[365,13190,13173],{"align":7654},[365,13192,13193],{"align":7654},"通常为整张表",[365,13195,13196],{},"无可用索引或全表扫描更便宜",[18,13198,13199,13200,3639],{},"还应单独记住 JOIN 中的 ",[21,13201,12255],{},[63,13203,13204],{},[18,13205,13206],{},"对前表的每一条记录，通过当前表的主键或唯一非空索引最多匹配一行。",[192,13208,13210],{"id":13209},"_11-explain-与-explain-analyze-的区别","11. EXPLAIN 与 EXPLAIN ANALYZE 的区别",[18,13212,13213,13215,13216,3639],{},[21,13214,10119],{}," 只展示优化器计划如何执行 SQL，并不会真正执行普通 ",[21,13217,7594],{},[118,13219,13220],{"className":7908,"code":11876,"language":7910,"meta":124,"style":124},[21,13221,13222,13226,13230,13234],{"__ignoreMap":124},[142,13223,13224],{"class":144,"line":145},[142,13225,11883],{},[142,13227,13228],{"class":144,"line":151},[142,13229,9444],{},[142,13231,13232],{"class":144,"line":157},[142,13233,9449],{},[142,13235,13236],{"class":144,"line":163},[142,13237,11896],{},[18,13239,13240,13241,13244,13245,52],{},"其中的 ",[21,13242,13243],{},"rows、filtered、cost"," 等主要来自统计信息和成本模型，是",[68,13246,13247],{},"估算值",[18,13249,13250,13252],{},[21,13251,10122],{}," 会真正执行查询，并在执行计划中同时展示估算值和实际运行数据：",[118,13254,13256],{"className":7908,"code":13255,"language":7910,"meta":124,"style":124},"EXPLAIN ANALYZE\nSELECT *\nFROM orders\nWHERE user_id = 100;\n",[21,13257,13258,13263,13267,13271],{"__ignoreMap":124},[142,13259,13260],{"class":144,"line":145},[142,13261,13262],{},"EXPLAIN ANALYZE\n",[142,13264,13265],{"class":144,"line":151},[142,13266,9444],{},[142,13268,13269],{"class":144,"line":157},[142,13270,9449],{},[142,13272,13273],{"class":144,"line":163},[142,13274,11896],{},[18,13276,13277],{},"典型输出片段：",[118,13279,13282],{"className":13280,"code":13281,"language":123,"meta":124},[121],"Index lookup on orders using idx_user_id\n (cost=10.2 rows=20)\n (actual time=0.08..0.15 rows=350 loops=1)\n",[21,13283,13281],{"__ignoreMap":124},[18,13285,13286],{},"可以重点对比：",[99,13288,13289,13295,13301,13307,13313],{},[102,13290,13291,13294],{},[21,13292,13293],{},"cost","：优化器估算成本；",[102,13296,13297,13298,13300],{},"前一个 ",[21,13299,11969],{},"：预计返回行数；",[102,13302,13303,13306],{},[21,13304,13305],{},"actual time","：实际首行时间和完成时间；",[102,13308,13309,13310,13312],{},"后一个 ",[21,13311,11969],{},"：每次循环实际返回行数；",[102,13314,13315,13318],{},[21,13316,13317],{},"loops","：该执行节点实际执行次数。",[18,13320,13321],{},"两者的核心区别：",[341,13323,13324,13338],{},[344,13325,13326],{},[347,13327,13328,13330,13334],{},[350,13329,3182],{},[350,13331,13332],{},[21,13333,10119],{},[350,13335,13336],{},[21,13337,10122],{},[360,13339,13340,13353,13364,13375,13386],{},[347,13341,13342,13345,13350],{},[365,13343,13344],{},"是否真正执行查询",[365,13346,7591,13347,13349],{},[21,13348,7594],{}," 不执行",[365,13351,13352],{},"会真实执行",[347,13354,13355,13358,13361],{},[365,13356,13357],{},"行数与成本",[365,13359,13360],{},"主要是估算值",[365,13362,13363],{},"同时提供估算与实际数据",[347,13365,13366,13369,13372],{},[365,13367,13368],{},"实际耗时",[365,13370,13371],{},"不提供",[365,13373,13374],{},"提供各执行节点耗时",[347,13376,13377,13380,13383],{},[365,13378,13379],{},"主要用途",[365,13381,13382],{},"上线前检查计划、低风险分析",[365,13384,13385],{},"验证估算偏差、定位真实瓶颈",[347,13387,13388,13391,13394],{},[365,13389,13390],{},"使用风险",[365,13392,13393],{},"较低",[365,13395,13396],{},"慢 SQL 会真实消耗资源",[18,13398,13399,13401],{},[21,13400,10122],{}," 能发现这类问题：",[118,13403,13406],{"className":13404,"code":13405,"language":123,"meta":124},[121],"优化器预计返回 20 行\n实际返回 350000 行\n",[21,13407,13405],{"__ignoreMap":124},[18,13409,13410],{},"这种巨大偏差可能与统计信息、数据倾斜、条件相关性或估算模型有关。",[18,13412,13413],{},"使用时必须注意：",[99,13415,13416,13419,13422,13425],{},[102,13417,13418],{},"它会真实执行查询，慢查询会真实占用 CPU、I\u002FO 和锁资源；",[102,13420,13421],{},"对复杂 SQL 应优先在测试或影子环境执行；",[102,13423,13424],{},"不要在生产高峰期随意分析可能扫描海量数据的语句；",[102,13426,13427],{},"对数据修改语句尤其谨慎，不能把它当成完全无副作用的静态分析工具。",[192,13429,13431,13432,13434],{"id":13430},"_12-不要只根据-type-判断性能","12. 不要只根据 ",[21,13433,10130],{}," 判断性能",[18,13436,13437],{},"下面两个计划：",[118,13439,13442],{"className":13440,"code":13441,"language":123,"meta":124},[121],"计划 A：type=ref，rows=500000\n计划 B：type=range，rows=20\n",[21,13443,13441],{"__ignoreMap":124},[18,13445,13446,13447,13449,13450,13452],{},"虽然官方列表中 ",[21,13448,11954],{}," 排在 ",[21,13451,11957],{}," 前面，但计划 B 很可能扫描更少、执行更快。",[18,13454,13455],{},"同理：",[118,13457,13460],{"className":13458,"code":13459,"language":123,"meta":124},[121],"计划 A：type=ALL，rows=30\n计划 B：type=ref，rows=100000\n",[21,13461,13459],{"__ignoreMap":124},[18,13463,13464],{},"对只有 30 行的小表执行全表扫描，不一定是问题。",[18,13466,13467],{},"因此，合理的判断方式是：",[118,13469,13472],{"className":13470,"code":13471,"language":123,"meta":124},[121],"type\n +\nkey \u002F key_len\n +\nrows \u002F filtered\n +\nExtra\n +\nEXPLAIN ANALYZE 的实际行数与耗时\n",[21,13473,13471],{"__ignoreMap":124},[18,13475,13476,13478],{},[21,13477,10130],{}," 是执行计划的重要入口，但不是最终结论。",[18,13480,13481],{},"几个常见误区：",[99,13483,13484,13489,13494,13499,13505,13510],{},[102,13485,13486,13488],{},[21,13487,10115],{}," 有值，不代表最终使用了索引；",[102,13490,13491,13493],{},[21,13492,10126],{}," 有值，不代表查询一定高效；",[102,13495,13496,13498],{},[21,13497,12838],{}," 通常表示全索引扫描，不等于范围定位；",[102,13500,13501,13504],{},[21,13502,13503],{},"type=ALL"," 是全表扫描，但小表全表扫描可能就是合理计划；",[102,13506,13507,13509],{},[21,13508,12817],{}," 通常表示覆盖索引，不等于“使用索引定位”；",[102,13511,13512],{},"预计扫描行数少，也可能因估算偏差与实际执行差异很大。",[14,13514,13516],{"id":13515},"十三排查顺序","十三、排查顺序",[18,13518,13519],{},"遇到“明明建了索引却很慢”，可以按下面顺序检查：",[708,13521,13522,13525,13528,13543,13546,13549,13552,13555,13561],{},[102,13523,13524],{},"确认慢 SQL、参数值和数据量，不能只拿脱离现场的 SQL 模板分析。",[102,13526,13527],{},"查看表结构、索引顺序、字段类型、字符集和排序规则。",[102,13529,3501,13530,13532,13533,5196,13535,5196,13537,5196,13539,1441,13541,52],{},[21,13531,10119],{}," 检查 ",[21,13534,10126],{},[21,13536,10130],{},[21,13538,11969],{},[21,13540,11979],{},[21,13542,11815],{},[102,13544,13545],{},"检查联合索引是否满足最左前缀，范围条件之后是否只剩过滤能力。",[102,13547,13548],{},"检查索引列上是否存在函数、计算或隐式转换。",[102,13550,13551],{},"估算查询命中比例和回表次数，判断优化器放弃索引是否合理。",[102,13553,13554],{},"对比估算行数与实际行数，检查统计信息是否明显失真。",[102,13556,13557,13558,13560],{},"在可控环境中使用 ",[21,13559,10122],{}," 验证真实执行路径。",[102,13562,13563,13564,13566],{},"调整 SQL 或索引后，在可控环境中使用 ",[21,13565,10122],{}," 验证实际执行情况，并结合线上灰度后的查询耗时、扫描行数、回表量及资源指标持续观察，不能只看静态执行计划就宣布优化完成。只有涉及高并发、容量上限或锁竞争的场景，才需要进一步进行专项压测。",[14,13568,13570],{"id":13569},"十四常见错误结论","十四、常见错误结论",[192,13572,13574],{"id":13573},"_1-联合索引中间断了一列整个索引都失效","1. 联合索引中间断了一列，整个索引都失效",[18,13576,13577],{},"不准确。最左侧连续部分仍可能用于定位，后续列也可能通过 ICP 或覆盖索引发挥作用。",[192,13579,13581],{"id":13580},"_2-遇到范围查询后面的索引列完全没用","2. 遇到范围查询，后面的索引列完全没用",[18,13583,13584],{},"不准确。后续列通常不能继续缩小连续范围，但仍可能用于索引层过滤或覆盖查询。",[192,13586,5702,13588,5196,13590,5196,13592,13594],{"id":13587},"_3-not-inis-null-一定不走索引",[21,13589,10096],{},[21,13591,10099],{},[21,13593,11309],{}," 一定不走索引",[18,13596,13597],{},"不准确。是否选择索引取决于数据分布、命中比例、覆盖情况和优化器成本估算。",[192,13599,12252,13601,13603],{"id":13600},"_4-key-不为-null-就说明索引使用良好",[21,13602,10126],{}," 不为 NULL 就说明索引使用良好",[18,13605,13606],{},"不准确。可能扫描了大部分索引，也可能发生大量回表。",[192,13608,13610],{"id":13609},"_5-全表扫描一定比索引慢","5. 全表扫描一定比索引慢",[18,13612,13613],{},"不准确。小表或需要读取大部分数据时，顺序全表扫描可能是成本更低的方案。",[192,13615,13617,13618,13620],{"id":13616},"_6-使用-force-index-就能解决问题","6. 使用 ",[21,13619,11376],{}," 就能解决问题",[18,13622,13623],{},"不准确。强制索引可能暂时改变执行计划，也可能在数据分布变化后变得更慢。应先找到优化器不选择索引的真实原因。",[14,13625,13627],{"id":13626},"十五参考资料","十五、参考资料",[99,13629,13630,13637,13644,13651,13658,13665,13672,13679],{},[102,13631,13632],{},[77,13633,13636],{"href":13634,"rel":13635},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Fmysql-indexes.html",[1579],"MySQL 8.0 Reference Manual：How MySQL Uses Indexes",[102,13638,13639],{},[77,13640,13643],{"href":13641,"rel":13642},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Foptimization-indexes.html",[1579],"MySQL 8.0 Reference Manual：Optimization and Indexes",[102,13645,13646],{},[77,13647,13650],{"href":13648,"rel":13649},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Fexplain.html",[1579],"MySQL 8.0 Reference Manual：EXPLAIN Statement",[102,13652,13653],{},[77,13654,13657],{"href":13655,"rel":13656},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Findex-merge-optimization.html",[1579],"MySQL 8.0 Reference Manual：Index Merge Optimization",[102,13659,13660],{},[77,13661,13664],{"href":13662,"rel":13663},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Findex-condition-pushdown-optimization.html",[1579],"MySQL 8.0 Reference Manual：Index Condition Pushdown Optimization",[102,13666,13667],{},[77,13668,13671],{"href":13669,"rel":13670},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Forder-by-optimization.html",[1579],"MySQL 8.0 Reference Manual：ORDER BY Optimization",[102,13673,13674],{},[77,13675,13678],{"href":13676,"rel":13677},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Fcreate-index.html",[1579],"MySQL 8.0 Reference Manual：CREATE INDEX Statement",[102,13680,13681],{},[77,13682,13685],{"href":13683,"rel":13684},"https:\u002F\u002Fdev.mysql.com\u002Fdoc\u002Frefman\u002F8.0\u002Fen\u002Fgenerated-column-index-optimizations.html",[1579],"MySQL 8.0 Reference Manual：Optimizer Use of Generated Column Indexes",[1596,13687,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":13689},[13690,13693,13694,13695,13700,13701,13702,13703,13704,13705,13711,13712,13713,13718,13719,13742,13743,13754],{"id":16,"depth":151,"text":16,"children":13691},[13692],{"id":7606,"depth":157,"text":7606},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":10154,"depth":151,"text":10155,"children":13696},[13697,13698,13699],{"id":10161,"depth":157,"text":10162},{"id":10204,"depth":157,"text":10205},{"id":10278,"depth":157,"text":10279},{"id":10297,"depth":151,"text":10298},{"id":10407,"depth":151,"text":10408},{"id":10484,"depth":151,"text":10485},{"id":10728,"depth":151,"text":10729},{"id":10805,"depth":151,"text":10806},{"id":10884,"depth":151,"text":10885,"children":13706},[13707,13708,13710],{"id":10952,"depth":157,"text":10953},{"id":11093,"depth":157,"text":13709},"Using sort_union(...) 是什么意思",{"id":11205,"depth":157,"text":11206},{"id":11260,"depth":151,"text":11261},{"id":11313,"depth":151,"text":11314},{"id":11380,"depth":151,"text":11381,"children":13714},[13715,13716,13717],{"id":11479,"depth":157,"text":11479},{"id":11636,"depth":157,"text":11636},{"id":11716,"depth":157,"text":11716},{"id":11827,"depth":151,"text":11828},{"id":11869,"depth":151,"text":11870,"children":13720},[13721,13723,13725,13727,13729,13731,13733,13734,13736,13738,13739,13740],{"id":11994,"depth":157,"text":13722},"1. type 到底表示什么",{"id":12071,"depth":157,"text":13724},"2. system：表中只有一行",{"id":12101,"depth":157,"text":13726},"3. const：通过主键或唯一键最多定位一行",{"id":12251,"depth":157,"text":13728},"4. eq_ref：JOIN 时每条前表记录最多匹配一行",{"id":12395,"depth":157,"text":13730},"5. ref：通过非唯一索引等值查找一组记录",{"id":12514,"depth":157,"text":13732},"6. range：扫描索引中的一个或多个区间",{"id":12707,"depth":157,"text":12708},{"id":12823,"depth":157,"text":13735},"8. index：把整棵索引扫描一遍",{"id":12951,"depth":157,"text":13737},"9. ALL：扫描整张表",{"id":13055,"depth":157,"text":13056},{"id":13209,"depth":157,"text":13210},{"id":13430,"depth":157,"text":13741},"12. 不要只根据 type 判断性能",{"id":13515,"depth":151,"text":13516},{"id":13569,"depth":151,"text":13570,"children":13744},[13745,13746,13747,13749,13751,13752],{"id":13573,"depth":157,"text":13574},{"id":13580,"depth":157,"text":13581},{"id":13587,"depth":157,"text":13748},"3. !=、NOT IN、IS NULL 一定不走索引",{"id":13600,"depth":157,"text":13750},"4. key 不为 NULL 就说明索引使用良好",{"id":13609,"depth":157,"text":13610},{"id":13616,"depth":157,"text":13753},"6. 使用 FORCE INDEX 就能解决问题",{"id":13626,"depth":151,"text":13627},"wiki:java:mysql-index-failure-scenarios","从联合索引、函数运算、隐式转换、LIKE、OR、选择性和优化器成本等角度，系统解释 MySQL 索引无法使用、部分使用及主动放弃索引的常见场景。",{},77,"\u002Fjava\u002Fmysql-index-failure-scenarios",{"title":10021,"description":13756},"java\u002Fmysql-index-failure-scenarios","AqnNs3qUNTn8ktXgQNQWmCN5cMkFaGtftEusXnNhnmY",{"id":13764,"title":13765,"body":13766,"commentId":14918,"description":14919,"difficulty":1645,"draft":1646,"extension":1647,"meta":14920,"navigation":780,"order":14921,"path":14922,"section":1651,"seo":14923,"stem":14924,"updated":1654,"__hash__":14925},"java\u002Fjava\u002Frocketmq-message-types-and-use-cases.md","RocketMQ 都有哪些消息类型？使用场景是什么？",{"type":7,"value":13767,"toc":14863},[13768,13771,13773,13776,13802,13805,13807,13814,13816,13825,13827,13831,13834,13902,13905,13908,13922,13925,13929,13933,13936,13942,13945,13948,13953,13957,13960,13983,13986,13992,13995,13999,14002,14013,14016,14020,14024,14027,14030,14036,14039,14045,14055,14059,14062,14065,14071,14074,14078,14081,14084,14087,14090,14093,14096,14099,14105,14109,14129,14133,14136,14139,14156,14159,14163,14167,14170,14176,14179,14194,14198,14204,14207,14211,14234,14237,14243,14246,14250,14257,14274,14277,14281,14284,14290,14297,14300,14304,14308,14311,14316,14319,14327,14330,14336,14340,14346,14349,14355,14358,14361,14378,14382,14385,14387,14393,14396,14413,14416,14420,14423,14429,14432,14492,14495,14499,14503,14506,14512,14515,14529,14533,14536,14539,14545,14551,14564,14567,14571,14574,14577,14594,14598,14601,14607,14619,14623,14626,14632,14635,14639,14642,14648,14651,14685,14688,14691,14710,14713,14727,14730,14734,14738,14741,14745,14748,14752,14755,14759,14762,14766,14769,14773,14777,14780,14784,14787,14791,14794,14798,14801,14805,14808,14810,14861],[10,13769,13765],{"id":13770},"rocketmq-都有哪些消息类型使用场景是什么",[14,13772,16],{"id":16},[18,13774,13775],{},"RocketMQ 5.x 按消息的传输语义正式分为四种类型：",[708,13777,13778,13784,13790,13796],{},[102,13779,13780,13783],{},[68,13781,13782],{},"普通消息 Normal","：没有顺序、定时或事务等特殊语义，发送成功后即可被消费，适合微服务解耦、异步通知、日志和数据集成。",[102,13785,13786,13789],{},[68,13787,13788],{},"顺序消息 FIFO","：同一 Message Group 内的消息按照发送、存储和投递顺序处理，适合同一订单的创建、支付、发货等状态流转，以及 Binlog 增量同步。",[102,13791,13792,13795],{},[68,13793,13794],{},"定时与延时消息 Delay","：消息到指定时间后才对消费者可见，适合订单超时关闭、延迟检查、定时通知和任务调度。",[102,13797,13798,13801],{},[68,13799,13800],{},"事务消息 Transaction","：通过半事务消息、本地事务确认和事务回查，保证本地事务与消息发送的最终一致性，适合下单后发放积分、扣款后发送通知等场景。",[18,13803,13804],{},"RocketMQ 5.x 可以为 Topic 声明消息类型，一个 Topic 只应承载一种消息类型。批量消息属于发送方式，重试消息和死信消息属于消费失败后的系统处理状态，Request-Reply 属于通信模式，它们都不属于上述四种正式 MessageType。",[18,13806,61],{},[63,13808,13809],{},[18,13810,13811],{},[68,13812,13813],{},"无特殊要求用普通消息；同一业务实体需要按序处理用 FIFO；需要未来触发用 Delay；本地事务必须和消息发送保持最终一致用 Transaction。",[14,13815,73],{"id":73},[18,13817,13818],{},[77,13819,13822],{"href":13820,"target":80,"rel":13821},"\u002Fimages\u002Fwiki\u002Fjava\u002Frocketmq-message-types-and-use-cases.svg",[82,83],[85,13823],{"src":13820,"alt":13824},"RocketMQ 四种消息类型、核心语义、典型场景及选择方法",[14,13826,90],{"id":90},[14,13828,13830],{"id":13829},"一先明确-rocketmq-的正式分类","一、先明确 RocketMQ 的正式分类",[18,13832,13833],{},"RocketMQ 5.x 定义了四种 MessageType：",[341,13835,13836,13848],{},[344,13837,13838],{},[347,13839,13840,13843,13846],{},[350,13841,13842],{},"消息类型",[350,13844,13845],{},"核心语义",[350,13847,12362],{},[360,13849,13850,13863,13876,13889],{},[347,13851,13852,13857,13860],{},[365,13853,13854],{},[21,13855,13856],{},"NORMAL",[365,13858,13859],{},"发送后立即进入可消费状态",[365,13861,13862],{},"异步解耦、事件通知、日志传输",[347,13864,13865,13870,13873],{},[365,13866,13867],{},[21,13868,13869],{},"FIFO",[365,13871,13872],{},"同一 Message Group 内按顺序处理",[365,13874,13875],{},"订单状态流转、Binlog 同步",[347,13877,13878,13883,13886],{},[365,13879,13880],{},[21,13881,13882],{},"DELAY",[365,13884,13885],{},"到指定时间后才允许消费",[365,13887,13888],{},"超时关闭、延迟检查、定时任务",[347,13890,13891,13896,13899],{},[365,13892,13893],{},[21,13894,13895],{},"TRANSACTION",[365,13897,13898],{},"本地事务与消息发送最终一致",[365,13900,13901],{},"交易完成后驱动下游业务",[18,13903,13904],{},"这四种类型不是按照消息内容划分，而是按照消息需要具备的传输和投递语义划分。",[18,13906,13907],{},"例如，同样是“订单创建”事件：",[99,13909,13910,13913,13916,13919],{},[102,13911,13912],{},"创建后立即异步通知风控，可以使用普通消息；",[102,13914,13915],{},"必须与后续支付、发货事件保持同一订单内的顺序，可以使用顺序消息；",[102,13917,13918],{},"创建三十分钟后检查是否支付，可以使用延时消息；",[102,13920,13921],{},"只有订单数据库事务成功后才能向下游投递，可以使用事务消息。",[18,13923,13924],{},"因此，消息类型的选择取决于业务语义，而不是消息中装了什么数据。",[14,13926,13928],{"id":13927},"二普通消息-normal","二、普通消息 Normal",[192,13930,13932],{"id":13931},"_1-什么是普通消息","1. 什么是普通消息",[18,13934,13935],{},"普通消息没有顺序、定时和事务等特殊语义。Broker 接收并保存消息后，消息进入 Ready 状态，Consumer 可以正常获取并处理。",[118,13937,13940],{"className":13938,"code":13939,"language":123,"meta":124},[121],"Producer\n │ 发送\n ▼\nBroker 持久化\n │ 立即可见\n ▼\nConsumer 消费\n",[21,13941,13939],{"__ignoreMap":124},[18,13943,13944],{},"“普通”不代表不可靠。普通消息同样可以使用发送确认、Broker 持久化、消费重试、死信队列和业务幂等机制。",[18,13946,13947],{},"它只表示：",[63,13949,13950],{},[18,13951,13952],{},"消息之间没有需要 RocketMQ 额外维护的顺序、时间或事务关系。",[192,13954,13956],{"id":13955},"_2-适用场景","2. 适用场景",[18,13958,13959],{},"普通消息适合绝大多数异步业务：",[99,13961,13962,13965,13968,13971,13974,13977,13980],{},[102,13963,13964],{},"微服务之间异步解耦；",[102,13966,13967],{},"用户注册后异步发送欢迎短信；",[102,13969,13970],{},"订单创建后异步更新搜索索引；",[102,13972,13973],{},"操作日志、埋点和审计事件传输；",[102,13975,13976],{},"缓存失效通知；",[102,13978,13979],{},"数据采集和数据集成；",[102,13981,13982],{},"不要求严格顺序的业务事件广播。",[18,13984,13985],{},"例如，订单创建后需要通知多个独立系统：",[118,13987,13990],{"className":13988,"code":13989,"language":123,"meta":124},[121],"订单服务\n │\n └── OrderCreated 普通消息\n ├── 风控服务\n ├── 推荐服务\n └── 数据分析服务\n",[21,13991,13989],{"__ignoreMap":124},[18,13993,13994],{},"这些下游之间不存在必须先后执行的关系，使用普通消息能够获得更好的并发能力。",[192,13996,13998],{"id":13997},"_3-不适合的场景","3. 不适合的场景",[18,14000,14001],{},"以下要求不能只依赖普通消息：",[99,14003,14004,14007,14010],{},[102,14005,14006],{},"同一订单的支付必须在创建之后处理；",[102,14008,14009],{},"消息必须在未来某个时间触发；",[102,14011,14012],{},"本地数据库事务失败时消息绝对不能对下游可见。",[18,14014,14015],{},"这时应分别考虑 FIFO、Delay 或 Transaction。",[14,14017,14019],{"id":14018},"三顺序消息-fifo","三、顺序消息 FIFO",[192,14021,14023],{"id":14022},"_1-顺序消息保证什么","1. 顺序消息保证什么",[18,14025,14026],{},"RocketMQ 5.x 使用 Message Group 标识需要保持顺序的一组消息。同一个 Message Group 中的消息按照先进先出顺序处理。",[18,14028,14029],{},"例如以订单号作为 Message Group：",[118,14031,14034],{"className":14032,"code":14033,"language":123,"meta":124},[121],"Message Group = order-1001\n\n创建订单 → 支付成功 → 仓库出库 → 物流发货\n",[21,14035,14033],{"__ignoreMap":124},[18,14037,14038],{},"另一个订单可以使用不同的 Message Group：",[118,14040,14043],{"className":14041,"code":14042,"language":123,"meta":124},[121],"order-1001：创建 → 支付 → 发货\norder-1002：创建 → 取消\n",[21,14044,14042],{"__ignoreMap":124},[18,14046,14047,14048,14051,14052,52],{},"两个订单之间不要求顺序，可以并发处理；同一订单内部保持顺序。这通常称为",[68,14049,14050],{},"局部顺序","或",[68,14053,14054],{},"分组顺序",[192,14056,14058],{"id":14057},"_2-为什么不追求整个-topic-的全局顺序","2. 为什么不追求整个 Topic 的全局顺序",[18,14060,14061],{},"如果一个 Topic 的全部消息都要求全局顺序，就只能把所有消息串行发送、存储和消费，并发能力会受到严重限制。",[18,14063,14064],{},"按订单号、用户 ID、账户 ID 等业务键划分 Message Group，可以做到：",[118,14066,14069],{"className":14067,"code":14068,"language":123,"meta":124},[121],"组内有序\n+\n组间并行\n",[21,14070,14068],{"__ignoreMap":124},[18,14072,14073],{},"这更符合大多数业务的真实要求。",[192,14075,14077],{"id":14076},"_3-保证顺序需要满足哪些条件","3. 保证顺序需要满足哪些条件",[18,14079,14080],{},"完整的顺序需要覆盖三个阶段。",[5727,14082,14083],{"id":14083},"发送顺序",[18,14085,14086],{},"同一 Message Group 的消息需要由生产端按业务顺序串行发送。如果多个线程或多个生产者同时发送，即使 Message Group 相同，RocketMQ 也无法推断业务上谁应该在前。",[5727,14088,14089],{"id":14089},"存储顺序",[18,14091,14092],{},"RocketMQ 将同一 Message Group 的消息存入同一个队列，并保持接收顺序。",[5727,14094,14095],{"id":14095},"消费顺序",[18,14097,14098],{},"Consumer 必须遵循“接收、处理、确认”的顺序。不能收到消息后随意提交给异步线程并立即确认，否则业务实际完成顺序仍可能被打乱。",[118,14100,14103],{"className":14101,"code":14102,"language":123,"meta":124},[121],"发送有序\n ↓\n存储有序\n ↓\n投递有序\n ↓\n业务处理有序\n",[21,14104,14102],{"__ignoreMap":124},[192,14106,14108],{"id":14107},"_4-适用场景","4. 适用场景",[99,14110,14111,14114,14117,14120,14123,14126],{},[102,14112,14113],{},"同一订单的创建、支付、取消和发货；",[102,14115,14116],{},"同一账户的充值、扣款和退款；",[102,14118,14119],{},"同一用户的状态变更；",[102,14121,14122],{},"数据库 Binlog 增量同步；",[102,14124,14125],{},"工作流节点推进；",[102,14127,14128],{},"交易撮合等要求按到达顺序处理的场景。",[192,14130,14132],{"id":14131},"_5-使用代价与风险","5. 使用代价与风险",[18,14134,14135],{},"顺序消息会牺牲部分并发能力，并且前面的消息处理失败时，后续消息可能等待。",[18,14137,14138],{},"需要重点关注：",[99,14140,14141,14144,14147,14150,14153],{},[102,14142,14143],{},"Message Group 是否过热；",[102,14145,14146],{},"单条消息是否持续重试并阻塞后续消息；",[102,14148,14149],{},"消费逻辑是否包含慢 SQL、慢 RPC；",[102,14151,14152],{},"是否错误地在消费端进行异步并发处理；",[102,14154,14155],{},"是否真的需要顺序，还是使用状态机和幂等就能解决。",[18,14157,14158],{},"不要把所有消息都设置为同一个 Message Group，否则会把系统退化成串行消费。",[14,14160,14162],{"id":14161},"四定时与延时消息-delay","四、定时与延时消息 Delay",[192,14164,14166],{"id":14165},"_1-定时消息和延时消息有什么区别","1. 定时消息和延时消息有什么区别",[18,14168,14169],{},"业务表达方式不同，但在 RocketMQ 5.x 中本质相同：都是设置一个未来的投递时间戳。",[118,14171,14174],{"className":14172,"code":14173,"language":123,"meta":124},[121],"延时消息：10 分钟后投递\n定时消息：2026-07-26 18:00:00 投递\n",[21,14175,14173],{"__ignoreMap":124},[18,14177,14178],{},"延时消息也需要先计算出最终投递时间：",[118,14180,14182],{"className":136,"code":14181,"language":138,"meta":124,"style":124},"long deliveryTimestamp =\n System.currentTimeMillis() + Duration.ofMinutes(10).toMillis();\n",[21,14183,14184,14189],{"__ignoreMap":124},[142,14185,14186],{"class":144,"line":145},[142,14187,14188],{},"long deliveryTimestamp =\n",[142,14190,14191],{"class":144,"line":151},[142,14192,14193],{}," System.currentTimeMillis() + Duration.ofMinutes(10).toMillis();\n",[192,14195,14197],{"id":14196},"_2-消息生命周期","2. 消息生命周期",[118,14199,14202],{"className":14200,"code":14201,"language":123,"meta":124},[121],"Producer 发送\n ↓\nTiming：Broker 按时间暂存\n ↓ 到达投递时间\nReady：转入普通存储并对 Consumer 可见\n ↓\nConsumer 消费并确认\n",[21,14203,14201],{"__ignoreMap":124},[18,14205,14206],{},"消息到达 Broker 并不代表 Consumer 立即可见。只有达到投递时间，消息才进入可以消费的状态。",[192,14208,14210],{"id":14209},"_3-适用场景","3. 适用场景",[99,14212,14213,14216,14219,14222,14225,14228,14231],{},[102,14214,14215],{},"订单创建三十分钟后检查是否支付；",[102,14217,14218],{},"支付处理中，五分钟后查询渠道结果；",[102,14220,14221],{},"优惠券到期提醒；",[102,14223,14224],{},"用户预约通知；",[102,14226,14227],{},"延迟重试；",[102,14229,14230],{},"定时清理任务；",[102,14232,14233],{},"分布式定时调度。",[18,14235,14236],{},"例如订单超时关闭：",[118,14238,14241],{"className":14239,"code":14240,"language":123,"meta":124},[121],"创建订单\n │\n ├── 写入订单数据\n └── 发送 30 分钟后投递的 Delay 消息\n ↓\n Consumer 查询订单状态\n ├── 未支付：关闭订单\n └── 已支付：忽略消息\n",[21,14242,14240],{"__ignoreMap":124},[18,14244,14245],{},"Consumer 收到延时消息后仍然必须重新检查业务状态。消息表达的是“现在应该检查”，不是“订单一定未支付”。",[192,14247,14249],{"id":14248},"_4-延时消息不是精确定时器","4. 延时消息不是精确定时器",[18,14251,14252,14253,14256],{},"设置的时间表示消息",[68,14254,14255],{},"不应早于该时间被消费","，但以下因素可能使实际处理晚于目标时间：",[99,14258,14259,14262,14265,14268,14271],{},[102,14260,14261],{},"Broker 当前负载较高；",[102,14263,14264],{},"大量消息设置了相同投递时间；",[102,14266,14267],{},"消费端发生积压；",[102,14269,14270],{},"Consumer 执行较慢或暂时不可用；",[102,14272,14273],{},"存储系统故障或重启。",[18,14275,14276],{},"因此，对秒级严格准点有强要求的业务不能只依赖消息到达时间，还要监控投递延迟并准备补偿扫描。",[192,14278,14280],{"id":14279},"_5-rocketmq-4x-与-5x-的区别","5. RocketMQ 4.x 与 5.x 的区别",[18,14282,14283],{},"RocketMQ 4.x 常见实现使用固定的延迟级别，例如：",[118,14285,14288],{"className":14286,"code":14287,"language":123,"meta":124},[121],"1 秒、5 秒、10 秒、30 秒、1 分钟……\n",[21,14289,14287],{"__ignoreMap":124},[18,14291,14292,14293,14296],{},"生产者通过 ",[21,14294,14295],{},"delayTimeLevel"," 选择预设级别。",[18,14298,14299],{},"RocketMQ 5.x 的正式 Delay 消息使用毫秒级 Unix 时间戳表示投递时间，不再局限于旧版固定延迟级别。面试时需要先说明讨论的是哪个版本，避免把 4.x 的十八个延迟级别直接当作 5.x 的唯一实现。",[14,14301,14303],{"id":14302},"五事务消息-transaction","五、事务消息 Transaction",[192,14305,14307],{"id":14306},"_1-事务消息解决什么问题","1. 事务消息解决什么问题",[18,14309,14310],{},"事务消息解决的是：",[63,14312,14313],{},[18,14314,14315],{},"本地事务与消息发送之间的最终一致性。",[18,14317,14318],{},"例如订单服务需要同时完成：",[708,14320,14321,14324],{},[102,14322,14323],{},"在本地数据库创建订单；",[102,14325,14326],{},"向 RocketMQ 发送订单创建消息。",[18,14328,14329],{},"如果先提交数据库再发送消息，数据库成功后消息可能发送失败；如果先发送消息再写数据库，消息可能已被消费，但数据库事务最终失败。",[118,14331,14334],{"className":14332,"code":14333,"language":123,"meta":124},[121],"数据库事务成功，消息失败 → 下游永远不知道订单已创建\n消息发送成功，数据库失败 → 下游处理了一笔不存在的订单\n",[21,14335,14333],{"__ignoreMap":124},[192,14337,14339],{"id":14338},"_2-核心流程","2. 核心流程",[118,14341,14344],{"className":14342,"code":14343,"language":123,"meta":124},[121],"Producer 发送 Half Message\n ↓\nBroker 保存消息，但暂不向 Consumer 投递\n ↓\nProducer 执行本地事务\n ┌───┴────────┐\n │ │\n Commit Rollback\n │ │\n消息可见并投递 消息回滚\n",[21,14345,14343],{"__ignoreMap":124},[18,14347,14348],{},"如果 Broker 长时间没有收到明确结果，会回查 Producer：",[118,14350,14353],{"className":14351,"code":14352,"language":123,"meta":124},[121],"Broker 发起事务回查\n ↓\nProducer 查询本地事务记录\n ┌────┼─────┐\n Commit Unknown Rollback\n",[21,14354,14352],{"__ignoreMap":124},[18,14356,14357],{},"Producer 的事务回查不能只依赖内存变量，需要根据订单表、事务日志或本地 Outbox 等持久化数据判断。",[192,14359,14210],{"id":14360},"_3-适用场景-1",[99,14362,14363,14366,14369,14372,14375],{},[102,14364,14365],{},"订单创建成功后通知库存、积分系统；",[102,14367,14368],{},"扣款成功后发送账务事件；",[102,14370,14371],{},"账户入账成功后通知下游；",[102,14373,14374],{},"数据库状态变化后更新搜索索引；",[102,14376,14377],{},"本地事务成功后驱动跨服务异步流程。",[192,14379,14381],{"id":14380},"_4-事务消息不保证什么","4. 事务消息不保证什么",[18,14383,14384],{},"事务消息保证的是本地事务与消息是否投递之间的最终一致性，不等于整个分布式业务已经成功。",[18,14386,1263],{},[118,14388,14391],{"className":14389,"code":14390,"language":123,"meta":124},[121],"订单本地事务成功\n ↓\n事务消息 Commit\n ↓\n积分服务消费失败\n",[21,14392,14390],{"__ignoreMap":124},[18,14394,14395],{},"RocketMQ 可以重试投递，但积分服务仍需实现：",[99,14397,14398,14401,14404,14407,14410],{},[102,14399,14400],{},"消费幂等；",[102,14402,14403],{},"失败重试；",[102,14405,14406],{},"死信处理；",[102,14408,14409],{},"对账与补偿；",[102,14411,14412],{},"业务状态机。",[18,14414,14415],{},"事务消息也不是跨多个数据库的强一致分布式事务。它更适合能够接受异步执行和最终一致性的业务。",[14,14417,14419],{"id":14418},"六四种消息类型如何选择","六、四种消息类型如何选择",[18,14421,14422],{},"可以按照下面的顺序判断：",[118,14424,14427],{"className":14425,"code":14426,"language":123,"meta":124},[121],"本地事务是否必须与消息发送保持最终一致？\n ├── 是 → Transaction\n └── 否\n ↓\n消息是否需要到未来某个时间才可消费？\n ├── 是 → Delay\n └── 否\n ↓\n同一业务实体的事件是否必须按顺序处理？\n ├── 是 → FIFO\n └── 否 → Normal\n",[21,14428,14426],{"__ignoreMap":124},[18,14430,14431],{},"对应关系：",[341,14433,14434,14447],{},[344,14435,14436],{},[347,14437,14438,14441,14444],{},[350,14439,14440],{},"业务要求",[350,14442,14443],{},"推荐类型",[350,14445,14446],{},"关键设计点",[360,14448,14449,14460,14470,14481],{},[347,14450,14451,14454,14457],{},[365,14452,14453],{},"只需要可靠异步传输",[365,14455,14456],{},"Normal",[365,14458,14459],{},"重试、幂等、监控",[347,14461,14462,14465,14467],{},[365,14463,14464],{},"同一订单内有先后关系",[365,14466,13869],{},[365,14468,14469],{},"Message Group、串行处理",[347,14471,14472,14475,14478],{},[365,14473,14474],{},"未来某个时间触发",[365,14476,14477],{},"Delay",[365,14479,14480],{},"投递时间、状态复查、延迟监控",[347,14482,14483,14486,14489],{},[365,14484,14485],{},"本地事务成功后才能投递",[365,14487,14488],{},"Transaction",[365,14490,14491],{},"Half Message、事务回查、持久化事务状态",[18,14493,14494],{},"不要因为高级消息类型“功能更多”就默认使用。每种特殊语义都会增加约束、运维成本或吞吐损耗；没有特殊要求时，普通消息通常是更简单的选择。",[14,14496,14498],{"id":14497},"七这些算不算消息类型","七、这些算不算消息类型",[192,14500,14502],{"id":14501},"_1-批量消息","1. 批量消息",[18,14504,14505],{},"批量消息不是独立 MessageType，而是一种发送或消费方式。",[118,14507,14510],{"className":14508,"code":14509,"language":123,"meta":124},[121],"单条发送：一次请求发送一条消息\n批量发送：一次请求携带多条消息\n",[21,14511,14509],{"__ignoreMap":124},[18,14513,14514],{},"批量能够减少网络往返和请求开销，适合日志采集、数据同步等吞吐优先的场景，但需要注意：",[99,14516,14517,14520,14523,14526],{},[102,14518,14519],{},"控制整个批次的大小；",[102,14521,14522],{},"批次失败后的重试粒度；",[102,14524,14525],{},"顺序消息不应随意并行批处理；",[102,14527,14528],{},"批量消费部分成功时的幂等和重试问题。",[192,14530,14532],{"id":14531},"_2-重试消息","2. 重试消息",[18,14534,14535],{},"重试消息是普通消息、FIFO 消息等消费失败后，RocketMQ 根据消费重试策略重新投递形成的系统处理过程，不是业务创建 Topic 时选择的正式 MessageType。",[18,14537,14538],{},"对于 PushConsumer，一次消费及失败重试可以简化为：",[118,14540,14543],{"className":14541,"code":14542,"language":123,"meta":124},[121],"Ready\n ↓ Consumer 获取消息\nInflight\n ├─ 消费成功并返回结果 → Commit\n └─ 消费失败或等待结果超时 → WaitingRetry\n ├─ 到达重试时间 → Ready\n └─ 超过最大重试次数 → DLQ\n",[21,14544,14542],{"__ignoreMap":124},[18,14546,14547,14550],{},[21,14548,14549],{},"Inflight"," 表示消息已经被 Consumer 获取，Consumer 正在执行业务逻辑，但消费结果还没有返回给 Broker。它可以理解为“正在处理中、等待确认”，不是一种新的消息类型。",[18,14552,14553,14556,14557,14559,14560,14563],{},[21,14554,14555],{},"WaitingRetry"," 是 PushConsumer 重试状态机中的状态。消息消费失败或 Broker 等待消费结果超时后，如果尚未达到最大重试次数，消息会先进入 ",[21,14558,14555],{},"；重试间隔结束后重新回到 ",[21,14561,14562],{},"Ready","，等待下一次投递。",[18,14565,14566],{},"Consumer 必须按消息可能重复投递来设计幂等。",[192,14568,14570],{"id":14569},"_3-死信消息","3. 死信消息",[18,14572,14573],{},"消息超过最大消费重试次数后，可能进入死信队列。死信消息代表消息进入异常隔离状态，也不是四种正式业务 MessageType 之一。",[18,14575,14576],{},"死信队列需要配套：",[99,14578,14579,14582,14585,14588,14591],{},[102,14580,14581],{},"告警；",[102,14583,14584],{},"失败原因记录；",[102,14586,14587],{},"人工检查；",[102,14589,14590],{},"修复后的重投；",[102,14592,14593],{},"对账和业务补偿。",[192,14595,14597],{"id":14596},"_4-request-reply-消息","4. Request-Reply 消息",[18,14599,14600],{},"Request-Reply 是一种通信模式：",[118,14602,14605],{"className":14603,"code":14604,"language":123,"meta":124},[121],"请求方发送消息\n ↓\n处理方消费并返回响应\n ↓\n请求方等待响应\n",[21,14606,14604],{"__ignoreMap":124},[18,14608,14609,14610,5196,14612,5196,14614,5196,14616,14618],{},"它描述生产者和消费者如何交互，不属于 ",[21,14611,13856],{},[21,14613,13869],{},[21,14615,13882],{},[21,14617,13895],{}," 之外的第五种正式 MessageType。",[192,14620,14622],{"id":14621},"_5-同步异步和单向消息","5. 同步、异步和单向消息",[18,14624,14625],{},"同步发送、异步发送和单向发送描述的是 Producer 调用发送接口的方式，也不是消息类型。",[118,14627,14630],{"className":14628,"code":14629,"language":123,"meta":124},[121],"同步发送：等待 Broker 返回结果\n异步发送：通过回调接收结果\n单向发送：发送后不等待结果\n",[21,14631,14629],{"__ignoreMap":124},[18,14633,14634],{},"不要把“发送方式”和“消息传输语义”混为一谈。",[14,14636,14638],{"id":14637},"八rocketmq-5x-为什么要求-topic-类型一致","八、RocketMQ 5.x 为什么要求 Topic 类型一致",[18,14640,14641],{},"RocketMQ 5.x 支持在 Topic 上声明消息类型：",[118,14643,14646],{"className":14644,"code":14645,"language":123,"meta":124},[121],".\u002Fbin\u002Fmqadmin updateTopic \\\n -n 127.0.0.1:9876 \\\n -t order-events \\\n -c DefaultCluster \\\n -a \"+message.type=FIFO\"\n",[21,14647,14645],{"__ignoreMap":124},[18,14649,14650],{},"其中：",[99,14652,14653,14659,14665,14671],{},[102,14654,14655,14658],{},[21,14656,14657],{},"-n"," 指定 NameServer 地址；",[102,14660,14661,14664],{},[21,14662,14663],{},"-t"," 指定 Topic 名称；",[102,14666,14667,14670],{},[21,14668,14669],{},"-c"," 指定目标集群；",[102,14672,14673,14676,14677,5196,14679,5196,14681,1217,14683,52],{},[21,14674,14675],{},"message.type"," 可设置为 ",[21,14678,13856],{},[21,14680,13869],{},[21,14682,13882],{},[21,14684,13895],{},[18,14686,14687],{},"上面创建的是 FIFO Topic。创建其他类型时，只需要替换最后一个参数的类型值。",[18,14689,14690],{},"启用类型校验后，一个 Topic 只允许发送与其类型一致的消息。例如：",[99,14692,14693,14701,14707],{},[102,14694,14695,14697,14698,14700],{},[21,14696,13869],{}," 消息不能发送到 ",[21,14699,13856],{}," Topic；",[102,14702,14703,14697,14705,14700],{},[21,14704,13895],{},[21,14706,13882],{},[102,14708,14709],{},"同一个 Topic 不应同时承载普通消息和顺序消息。",[18,14711,14712],{},"这样做的价值是：",[99,14714,14715,14718,14721,14724],{},[102,14716,14717],{},"让 Topic 的行为语义清晰；",[102,14719,14720],{},"避免客户端误用高级消息能力；",[102,14722,14723],{},"便于 Broker 按消息类型管理；",[102,14725,14726],{},"降低运维和故障排查复杂度。",[18,14728,14729],{},"为了兼容旧客户端，5.x 的强制类型校验能力需要结合服务端配置判断。面试中可以说“5.x 支持并推荐一个 Topic 对应一种消息类型”，不要绝对化为所有兼容部署都默认强制拒绝。",[14,14731,14733],{"id":14732},"九常见追问","九、常见追问",[192,14735,14737],{"id":14736},"_1-普通消息一定无序吗","1. 普通消息一定无序吗",[18,14739,14740],{},"普通消息在某个物理队列中自然存在存储先后，但业务没有建立端到端 FIFO 约束。多队列发送、并发消费、失败重试都可能使业务完成顺序变化，因此不能依赖普通消息保证业务顺序。",[192,14742,14744],{"id":14743},"_2-顺序消息能否保证整个-topic-全局有序","2. 顺序消息能否保证整个 Topic 全局有序",[18,14746,14747],{},"实际通常保证同一 Message Group 内有序。理论上把所有消息放入一个组可以接近全局串行，但会形成热点并严重限制吞吐，不建议这样设计。",[192,14749,14751],{"id":14750},"_3-延时消息到点后一定立即执行吗","3. 延时消息到点后一定立即执行吗",[18,14753,14754],{},"不一定。到点表示消息可以进入可消费状态，Broker 调度延迟、消息积压和 Consumer 处理能力都会影响最终业务执行时间。",[192,14756,14758],{"id":14757},"_4-事务消息消费成功是否与本地事务强一致","4. 事务消息消费成功是否与本地事务强一致",[18,14760,14761],{},"不是。事务消息只保证本地事务结果与消息是否投递之间的最终一致性。Consumer 的业务处理仍然是独立的异步过程，需要重试、幂等和补偿。",[192,14763,14765],{"id":14764},"_5-fifo-和-transaction-能否同时使用","5. FIFO 和 Transaction 能否同时使用",[18,14767,14768],{},"从 RocketMQ 5.x 的 Topic 类型模型看，一个 Topic 只对应一种正式消息类型，不能把同一条消息同时声明为 FIFO 和 Transaction。业务同时需要“事务一致性”和“顺序处理”时，需要重新审视领域流程，常见做法是用事务消息可靠发布业务事件，再由下游状态机、版本号、业务序号或独立 FIFO 流程处理顺序要求。",[14,14770,14772],{"id":14771},"十容易答错的地方","十、容易答错的地方",[192,14774,14776],{"id":14775},"错误一rocketmq-有五种消息包含批量消息","错误一：RocketMQ 有五种消息，包含批量消息",[18,14778,14779],{},"批量是发送方式，不是 RocketMQ 5.x 的正式 MessageType。正式类型是 Normal、FIFO、Delay、Transaction。",[192,14781,14783],{"id":14782},"错误二顺序消息保证整个-topic-全局有序","错误二：顺序消息保证整个 Topic 全局有序",[18,14785,14786],{},"通常保证同一 Message Group 内的局部顺序，不同组之间允许并发。",[192,14788,14790],{"id":14789},"错误三延时消息到了时间就保证业务已经执行","错误三：延时消息到了时间就保证业务已经执行",[18,14792,14793],{},"到达投递时间只表示消息对 Consumer 可见，实际业务完成还受积压、消费能力和重试影响。",[192,14795,14797],{"id":14796},"错误四事务消息保证上下游所有业务一起提交","错误四：事务消息保证上下游所有业务一起提交",[18,14799,14800],{},"事务消息保证本地事务与消息投递最终一致，下游消费结果仍然需要独立保障。",[192,14802,14804],{"id":14803},"错误五普通消息可靠性低","错误五：普通消息可靠性低",[18,14806,14807],{},"普通消息只是没有高级传输语义，不代表不持久化、不重试或不可靠。",[14,14809,1570],{"id":1570},[99,14811,14812,14819,14826,14833,14840,14847,14854],{},[102,14813,14814],{},[77,14815,14818],{"href":14816,"rel":14817},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FdomainModel\u002F02topic\u002F",[1579],"Apache RocketMQ 5.0：Topic 与 MessageType",[102,14820,14821],{},[77,14822,14825],{"href":14823,"rel":14824},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FfeatureBehavior\u002F01normalmessage\u002F",[1579],"Apache RocketMQ 5.0：普通消息",[102,14827,14828],{},[77,14829,14832],{"href":14830,"rel":14831},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FfeatureBehavior\u002F03fifomessage\u002F",[1579],"Apache RocketMQ 5.0：顺序消息",[102,14834,14835],{},[77,14836,14839],{"href":14837,"rel":14838},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FfeatureBehavior\u002F02delaymessage\u002F",[1579],"Apache RocketMQ 5.0：定时与延时消息",[102,14841,14842],{},[77,14843,14846],{"href":14844,"rel":14845},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FfeatureBehavior\u002F04transactionmessage\u002F",[1579],"Apache RocketMQ 5.0：事务消息",[102,14848,14849],{},[77,14850,14853],{"href":14851,"rel":14852},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002FfeatureBehavior\u002F10consumerretrypolicy\u002F",[1579],"Apache RocketMQ 5.0：消费重试",[102,14855,14856],{},[77,14857,14860],{"href":14858,"rel":14859},"https:\u002F\u002Frocketmq.apache.org\u002Fdocs\u002F4.x\u002Fproducer\u002F04message3\u002F",[1579],"Apache RocketMQ 4.x：延时消息级别",[1596,14862,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":14864},[14865,14866,14867,14868,14869,14874,14881,14888,14894,14895,14902,14903,14910,14917],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":13829,"depth":151,"text":13830},{"id":13927,"depth":151,"text":13928,"children":14870},[14871,14872,14873],{"id":13931,"depth":157,"text":13932},{"id":13955,"depth":157,"text":13956},{"id":13997,"depth":157,"text":13998},{"id":14018,"depth":151,"text":14019,"children":14875},[14876,14877,14878,14879,14880],{"id":14022,"depth":157,"text":14023},{"id":14057,"depth":157,"text":14058},{"id":14076,"depth":157,"text":14077},{"id":14107,"depth":157,"text":14108},{"id":14131,"depth":157,"text":14132},{"id":14161,"depth":151,"text":14162,"children":14882},[14883,14884,14885,14886,14887],{"id":14165,"depth":157,"text":14166},{"id":14196,"depth":157,"text":14197},{"id":14209,"depth":157,"text":14210},{"id":14248,"depth":157,"text":14249},{"id":14279,"depth":157,"text":14280},{"id":14302,"depth":151,"text":14303,"children":14889},[14890,14891,14892,14893],{"id":14306,"depth":157,"text":14307},{"id":14338,"depth":157,"text":14339},{"id":14360,"depth":157,"text":14210},{"id":14380,"depth":157,"text":14381},{"id":14418,"depth":151,"text":14419},{"id":14497,"depth":151,"text":14498,"children":14896},[14897,14898,14899,14900,14901],{"id":14501,"depth":157,"text":14502},{"id":14531,"depth":157,"text":14532},{"id":14569,"depth":157,"text":14570},{"id":14596,"depth":157,"text":14597},{"id":14621,"depth":157,"text":14622},{"id":14637,"depth":151,"text":14638},{"id":14732,"depth":151,"text":14733,"children":14904},[14905,14906,14907,14908,14909],{"id":14736,"depth":157,"text":14737},{"id":14743,"depth":157,"text":14744},{"id":14750,"depth":157,"text":14751},{"id":14757,"depth":157,"text":14758},{"id":14764,"depth":157,"text":14765},{"id":14771,"depth":151,"text":14772,"children":14911},[14912,14913,14914,14915,14916],{"id":14775,"depth":157,"text":14776},{"id":14782,"depth":157,"text":14783},{"id":14789,"depth":157,"text":14790},{"id":14796,"depth":157,"text":14797},{"id":14803,"depth":157,"text":14804},{"id":1570,"depth":151,"text":1570},"wiki:java:rocketmq-message-types-and-use-cases","系统介绍 RocketMQ 5.x 的普通消息、顺序消息、定时与延时消息、事务消息，说明各自语义、适用场景、使用限制，并澄清批量消息、重试消息和死信消息是否属于消息类型。",{},78,"\u002Fjava\u002Frocketmq-message-types-and-use-cases",{"title":13765,"description":14919},"java\u002Frocketmq-message-types-and-use-cases","zPNK0dDY9QBEyEm1LnCsD-ND3HLubjvBfZlwmFdve98",{"id":4,"title":5,"body":14927,"commentId":1643,"description":1644,"difficulty":1645,"draft":1646,"extension":1647,"meta":16069,"navigation":780,"order":1649,"path":1650,"section":1651,"seo":16070,"stem":1653,"updated":1654,"__hash__":1655},{"type":7,"value":14928,"toc":16025},[14929,14931,14933,14951,14953,14955,14957,14963,14965,14972,14974,14976,14978,14988,14990,14995,14997,14999,15035,15037,15041,15043,15051,15053,15061,15065,15067,15071,15073,15078,15082,15084,15088,15094,15102,15104,15106,15112,15114,15120,15134,15136,15138,15142,15144,15200,15202,15214,15216,15218,15222,15232,15234,15239,15241,15243,15245,15247,15303,15305,15307,15309,15317,15321,15326,15328,15330,15332,15334,15339,15341,15346,15350,15356,15358,15360,15362,15364,15369,15371,15373,15375,15380,15382,15387,15389,15401,15403,15405,15407,15417,15419,15424,15426,15428,15430,15670,15672,15688,15690,15692,15696,15698,15700,15705,15707,15711,15715,15723,15727,15729,15731,15739,15749,15751,15759,15779,15787,15789,15791,15793,15798,15800,15812,15814,15816,15818,15898,15900,15914,15916,15918,15924,15929,15931,15936,15940,15942,15944,15946,15948,15950,15952,15956,15958,15960,15962,15970,15972,15974,15976,16004,16006,16023],[10,14930,5],{"id":12},[14,14932,16],{"id":16},[18,14934,14935,24,14937,28,14939,32,14941,36,14943,40,14945,44,14947,48,14949,52],{},[21,14936,23],{},[21,14938,27],{},[21,14940,31],{},[21,14942,35],{},[21,14944,39],{},[21,14946,43],{},[21,14948,47],{},[21,14950,51],{},[18,14952,55],{},[18,14954,58],{},[18,14956,61],{},[63,14958,14959],{},[18,14960,14961],{},[68,14962,70],{},[14,14964,73],{"id":73},[18,14966,14967],{},[77,14968,14970],{"href":79,"target":80,"rel":14969},[82,83],[85,14971],{"src":79,"alt":87},[14,14973,90],{"id":90},[14,14975,94],{"id":93},[18,14977,97],{},[99,14979,14980,14982,14984,14986],{},[102,14981,104],{},[102,14983,107],{},[102,14985,110],{},[102,14987,113],{},[18,14989,116],{},[118,14991,14993],{"className":14992,"code":122,"language":123,"meta":124},[121],[21,14994,122],{"__ignoreMap":124},[14,14996,130],{"id":129},[18,14998,133],{},[118,15000,15001],{"className":136,"code":137,"language":138,"meta":124,"style":124},[21,15002,15003,15007,15011,15015,15019,15023,15027,15031],{"__ignoreMap":124},[142,15004,15005],{"class":144,"line":145},[142,15006,148],{},[142,15008,15009],{"class":144,"line":151},[142,15010,154],{},[142,15012,15013],{"class":144,"line":157},[142,15014,160],{},[142,15016,15017],{"class":144,"line":163},[142,15018,166],{},[142,15020,15021],{"class":144,"line":169},[142,15022,172],{},[142,15024,15025],{"class":144,"line":175},[142,15026,178],{},[142,15028,15029],{"class":144,"line":181},[142,15030,184],{},[142,15032,15033],{"class":144,"line":187},[142,15034,190],{},[192,15036,195],{"id":194},[18,15038,15039,200],{},[21,15040,27],{},[18,15042,203],{},[118,15044,15045],{"className":136,"code":206,"language":138,"meta":124,"style":124},[21,15046,15047],{"__ignoreMap":124},[142,15048,15049],{"class":144,"line":145},[142,15050,206],{},[18,15052,215],{},[118,15054,15055],{"className":136,"code":218,"language":138,"meta":124,"style":124},[21,15056,15057],{"__ignoreMap":124},[142,15058,15059],{"class":144,"line":145},[142,15060,218],{},[18,15062,227,15063,230],{},[21,15064,35],{},[192,15066,234],{"id":233},[18,15068,15069,239],{},[21,15070,31],{},[18,15072,242],{},[118,15074,15076],{"className":15075,"code":246,"language":123,"meta":124},[121],[21,15077,246],{"__ignoreMap":124},[18,15079,251,15080,52],{},[21,15081,31],{},[192,15083,257],{"id":256},[18,15085,260,15086,263],{},[21,15087,27],{},[18,15089,15090,268,15092,271],{},[21,15091,35],{},[21,15093,39],{},[118,15095,15096],{"className":136,"code":274,"language":138,"meta":124,"style":124},[21,15097,15098],{"__ignoreMap":124},[142,15099,15100],{"class":144,"line":145},[142,15101,274],{},[18,15103,283],{},[18,15105,286],{},[99,15107,15108,15110],{},[102,15109,291],{},[102,15111,294],{},[192,15113,298],{"id":297},[18,15115,15116,303,15118,306],{},[21,15117,39],{},[21,15119,35],{},[99,15121,15122,15126,15130],{},[102,15123,15124],{},[21,15125,313],{},[102,15127,15128],{},[21,15129,318],{},[102,15131,15132],{},[21,15133,323],{},[18,15135,326],{},[192,15137,330],{"id":329},[18,15139,333,15140,336],{},[21,15141,43],{},[18,15143,339],{},[341,15145,15146,15156],{},[344,15147,15148],{},[347,15149,15150,15152,15154],{},[350,15151,352],{},[350,15153,355],{},[350,15155,358],{},[360,15157,15158,15168,15180,15190],{},[347,15159,15160,15164,15166],{},[365,15161,15162],{},[21,15163,369],{},[365,15165,372],{},[365,15167,375],{},[347,15169,15170,15174,15176],{},[365,15171,15172],{},[21,15173,382],{},[365,15175,385],{},[365,15177,388,15178,392],{},[21,15179,391],{},[347,15181,15182,15186,15188],{},[365,15183,15184],{},[21,15185,399],{},[365,15187,402],{},[365,15189,405],{},[347,15191,15192,15196,15198],{},[365,15193,15194],{},[21,15195,412],{},[365,15197,415],{},[365,15199,418],{},[18,15201,421],{},[99,15203,15204,15206,15208,15210,15212],{},[102,15205,426],{},[102,15207,429],{},[102,15209,432],{},[102,15211,435],{},[102,15213,438],{},[18,15215,441],{},[192,15217,445],{"id":444},[18,15219,15220,450],{},[21,15221,47],{},[99,15223,15224,15226,15228,15230],{},[102,15225,455],{},[102,15227,458],{},[102,15229,461],{},[102,15231,464],{},[18,15233,467],{},[118,15235,15237],{"className":15236,"code":471,"language":123,"meta":124},[121],[21,15238,471],{"__ignoreMap":124},[18,15240,476],{},[192,15242,480],{"id":479},[18,15244,483],{},[18,15246,486],{},[341,15248,15249,15259],{},[344,15250,15251],{},[347,15252,15253,15255,15257],{},[350,15254,495],{},[350,15256,498],{},[350,15258,501],{},[360,15260,15261,15273,15283,15293],{},[347,15262,15263,15267,15271],{},[365,15264,15265],{},[21,15266,510],{},[365,15268,513,15269],{},[21,15270,516],{},[365,15272,519],{},[347,15274,15275,15279,15281],{},[365,15276,15277],{},[21,15278,526],{},[365,15280,529],{},[365,15282,532],{},[347,15284,15285,15289,15291],{},[365,15286,15287],{},[21,15288,539],{},[365,15290,542],{},[365,15292,545],{},[347,15294,15295,15299,15301],{},[365,15296,15297],{},[21,15298,552],{},[365,15300,555],{},[365,15302,558],{},[18,15304,561],{},[14,15306,565],{"id":564},[18,15308,568],{},[118,15310,15311],{"className":136,"code":571,"language":138,"meta":124,"style":124},[21,15312,15313],{"__ignoreMap":124},[142,15314,15315],{"class":144,"line":145},[142,15316,571],{},[18,15318,15319,582],{},[21,15320,23],{},[118,15322,15324],{"className":15323,"code":586,"language":123,"meta":124},[121],[21,15325,586],{"__ignoreMap":124},[18,15327,591],{},[18,15329,594],{},[14,15331,598],{"id":597},[18,15333,601],{},[118,15335,15337],{"className":15336,"code":605,"language":123,"meta":124},[121],[21,15338,605],{"__ignoreMap":124},[18,15340,610],{},[118,15342,15344],{"className":15343,"code":614,"language":123,"meta":124},[121],[21,15345,614],{"__ignoreMap":124},[18,15347,619,15348,622],{},[21,15349,382],{},[18,15351,625,15352,628,15354,631],{},[21,15353,31],{},[21,15355,43],{},[14,15357,635],{"id":634},[192,15359,639],{"id":638},[18,15361,642],{},[18,15363,645],{},[118,15365,15367],{"className":15366,"code":649,"language":123,"meta":124},[121],[21,15368,649],{"__ignoreMap":124},[18,15370,654],{},[192,15372,658],{"id":657},[18,15374,661],{},[118,15376,15378],{"className":15377,"code":665,"language":123,"meta":124},[121],[21,15379,665],{"__ignoreMap":124},[18,15381,670],{},[118,15383,15385],{"className":15384,"code":674,"language":123,"meta":124},[121],[21,15386,674],{"__ignoreMap":124},[18,15388,679],{},[99,15390,15391,15393,15395,15397,15399],{},[102,15392,684],{},[102,15394,687],{},[102,15396,690],{},[102,15398,693],{},[102,15400,696],{},[18,15402,699],{},[192,15404,703],{"id":702},[18,15406,706],{},[708,15408,15409,15411,15413,15415],{},[102,15410,712],{},[102,15412,715],{},[102,15414,718],{},[102,15416,721],{},[18,15418,724],{},[118,15420,15422],{"className":15421,"code":728,"language":123,"meta":124},[121],[21,15423,728],{"__ignoreMap":124},[18,15425,733],{},[14,15427,737],{"id":736},[18,15429,740],{},[118,15431,15432],{"className":136,"code":743,"language":138,"meta":124,"style":124},[21,15433,15434,15438,15442,15446,15450,15454,15458,15462,15466,15470,15474,15478,15482,15486,15490,15494,15498,15502,15506,15510,15514,15518,15522,15526,15530,15534,15538,15542,15546,15550,15554,15558,15562,15566,15570,15574,15578,15582,15586,15590,15594,15598,15602,15606,15610,15614,15618,15622,15626,15630,15634,15638,15642,15646,15650,15654,15658,15662,15666],{"__ignoreMap":124},[142,15435,15436],{"class":144,"line":145},[142,15437,750],{},[142,15439,15440],{"class":144,"line":151},[142,15441,755],{},[142,15443,15444],{"class":144,"line":157},[142,15445,760],{},[142,15447,15448],{"class":144,"line":163},[142,15449,765],{},[142,15451,15452],{"class":144,"line":169},[142,15453,770],{},[142,15455,15456],{"class":144,"line":175},[142,15457,775],{},[142,15459,15460],{"class":144,"line":181},[142,15461,781],{"emptyLinePlaceholder":780},[142,15463,15464],{"class":144,"line":187},[142,15465,786],{},[142,15467,15468],{"class":144,"line":789},[142,15469,781],{"emptyLinePlaceholder":780},[142,15471,15472],{"class":144,"line":794},[142,15473,797],{},[142,15475,15476],{"class":144,"line":800},[142,15477,781],{"emptyLinePlaceholder":780},[142,15479,15480],{"class":144,"line":805},[142,15481,808],{},[142,15483,15484],{"class":144,"line":811},[142,15485,814],{},[142,15487,15488],{"class":144,"line":817},[142,15489,820],{},[142,15491,15492],{"class":144,"line":823},[142,15493,826],{},[142,15495,15496],{"class":144,"line":829},[142,15497,832],{},[142,15499,15500],{"class":144,"line":835},[142,15501,838],{},[142,15503,15504],{"class":144,"line":841},[142,15505,844],{},[142,15507,15508],{"class":144,"line":847},[142,15509,850],{},[142,15511,15512],{"class":144,"line":853},[142,15513,856],{},[142,15515,15516],{"class":144,"line":859},[142,15517,832],{},[142,15519,15520],{"class":144,"line":864},[142,15521,867],{},[142,15523,15524],{"class":144,"line":870},[142,15525,873],{},[142,15527,15528],{"class":144,"line":876},[142,15529,781],{"emptyLinePlaceholder":780},[142,15531,15532],{"class":144,"line":881},[142,15533,884],{},[142,15535,15536],{"class":144,"line":887},[142,15537,890],{},[142,15539,15540],{"class":144,"line":893},[142,15541,896],{},[142,15543,15544],{"class":144,"line":899},[142,15545,902],{},[142,15547,15548],{"class":144,"line":905},[142,15549,908],{},[142,15551,15552],{"class":144,"line":911},[142,15553,914],{},[142,15555,15556],{"class":144,"line":917},[142,15557,920],{},[142,15559,15560],{"class":144,"line":923},[142,15561,926],{},[142,15563,15564],{"class":144,"line":929},[142,15565,932],{},[142,15567,15568],{"class":144,"line":935},[142,15569,938],{},[142,15571,15572],{"class":144,"line":941},[142,15573,781],{"emptyLinePlaceholder":780},[142,15575,15576],{"class":144,"line":946},[142,15577,949],{},[142,15579,15580],{"class":144,"line":952},[142,15581,955],{},[142,15583,15584],{"class":144,"line":958},[142,15585,781],{"emptyLinePlaceholder":780},[142,15587,15588],{"class":144,"line":963},[142,15589,966],{},[142,15591,15592],{"class":144,"line":969},[142,15593,972],{},[142,15595,15596],{"class":144,"line":975},[142,15597,978],{},[142,15599,15600],{"class":144,"line":981},[142,15601,984],{},[142,15603,15604],{"class":144,"line":987},[142,15605,990],{},[142,15607,15608],{"class":144,"line":993},[142,15609,996],{},[142,15611,15612],{"class":144,"line":999},[142,15613,1002],{},[142,15615,15616],{"class":144,"line":1005},[142,15617,955],{},[142,15619,15620],{"class":144,"line":1010},[142,15621,781],{"emptyLinePlaceholder":780},[142,15623,15624],{"class":144,"line":1015},[142,15625,1018],{},[142,15627,15628],{"class":144,"line":1021},[142,15629,1024],{},[142,15631,15632],{"class":144,"line":1027},[142,15633,972],{},[142,15635,15636],{"class":144,"line":1032},[142,15637,1035],{},[142,15639,15640],{"class":144,"line":1038},[142,15641,1041],{},[142,15643,15644],{"class":144,"line":1044},[142,15645,1047],{},[142,15647,15648],{"class":144,"line":1050},[142,15649,1053],{},[142,15651,15652],{"class":144,"line":1056},[142,15653,1059],{},[142,15655,15656],{"class":144,"line":1062},[142,15657,1065],{},[142,15659,15660],{"class":144,"line":1068},[142,15661,1002],{},[142,15663,15664],{"class":144,"line":1073},[142,15665,955],{},[142,15667,15668],{"class":144,"line":1078},[142,15669,1081],{},[18,15671,1084],{},[99,15673,15674,15676,15678,15680,15682,15684],{},[102,15675,1089],{},[102,15677,1092],{},[102,15679,1095],{},[102,15681,1098],{},[102,15683,1101],{},[102,15685,1104,15686,1108],{},[21,15687,1107],{},[18,15689,1111],{},[14,15691,1115],{"id":1114},[18,15693,15694,1121],{},[21,15695,1120],{},[192,15697,1125],{"id":1124},[18,15699,1128],{},[118,15701,15703],{"className":15702,"code":1132,"language":123,"meta":124},[121],[21,15704,1132],{"__ignoreMap":124},[192,15706,1138],{"id":1137},[18,15708,1141,15709,1144],{},[21,15710,399],{},[18,15712,1147,15713,1150],{},[21,15714,23],{},[99,15716,15717,15719,15721],{},[102,15718,1155],{},[102,15720,1158],{},[102,15722,1161],{},[18,15724,1164,15725,1167],{},[21,15726,1120],{},[14,15728,1171],{"id":1170},[192,15730,1174],{"id":1174},[118,15732,15733],{"className":136,"code":571,"language":138,"meta":124,"style":124},[21,15734,15735],{"__ignoreMap":124},[142,15736,15737],{"class":144,"line":145},[142,15738,571],{},[99,15740,15741,15745,15747],{},[102,15742,1187,15743,1191],{},[21,15744,1190],{},[102,15746,1194],{},[102,15748,1197],{},[192,15750,1200],{"id":1200},[118,15752,15753],{"className":136,"code":1203,"language":138,"meta":124,"style":124},[21,15754,15755],{"__ignoreMap":124},[142,15756,15757],{"class":144,"line":145},[142,15758,1203],{},[99,15760,15761,15767,15771],{},[102,15762,1214,15763,1217,15765,1191],{},[21,15764,1190],{},[21,15766,1220],{},[102,15768,1223,15769,1227],{},[21,15770,1226],{},[102,15772,1230,15773,1233,15775,1237,15777,1241],{},[21,15774,1226],{},[21,15776,1236],{},[21,15778,1240],{},[18,15780,1244,15781,1248,15783,1251,15785,52],{},[21,15782,1247],{},[21,15784,1226],{},[21,15786,1226],{},[14,15788,1257],{"id":1256},[18,15790,1260],{},[18,15792,1263],{},[118,15794,15796],{"className":15795,"code":1267,"language":123,"meta":124},[121],[21,15797,1267],{"__ignoreMap":124},[18,15799,1272],{},[99,15801,15802,15804,15806,15808,15810],{},[102,15803,1277],{},[102,15805,1280],{},[102,15807,1283],{},[102,15809,1286],{},[102,15811,1289],{},[18,15813,1292],{},[14,15815,1296],{"id":1295},[18,15817,1299],{},[341,15819,15820,15828],{},[344,15821,15822],{},[347,15823,15824,15826],{},[350,15825,1308],{},[350,15827,1311],{},[360,15829,15830,15838,15846,15854,15860,15866,15874,15880,15886,15892],{},[347,15831,15832,15836],{},[365,15833,1318,15834],{},[21,15835,1321],{},[365,15837,1324],{},[347,15839,15840,15844],{},[365,15841,1329,15842],{},[21,15843,1332],{},[365,15845,1335],{},[347,15847,15848,15852],{},[365,15849,1340,15850],{},[21,15851,1343],{},[365,15853,1346],{},[347,15855,15856,15858],{},[365,15857,1351],{},[365,15859,1354],{},[347,15861,15862,15864],{},[365,15863,1359],{},[365,15865,1362],{},[347,15867,15868,15872],{},[365,15869,1367,15870],{},[21,15871,1370],{},[365,15873,1373],{},[347,15875,15876,15878],{},[365,15877,1378],{},[365,15879,1381],{},[347,15881,15882,15884],{},[365,15883,1386],{},[365,15885,1389],{},[347,15887,15888,15890],{},[365,15889,1394],{},[365,15891,1397],{},[347,15893,15894,15896],{},[365,15895,1402],{},[365,15897,1405],{},[18,15899,1408],{},[99,15901,15902,15904,15906,15908,15910,15912],{},[102,15903,1413],{},[102,15905,1416],{},[102,15907,1419],{},[102,15909,1422],{},[102,15911,1425],{},[102,15913,1428],{},[18,15915,1431],{},[14,15917,1435],{"id":1434},[18,15919,15920,1441,15922,1445],{},[21,15921,1440],{},[21,15923,1444],{},[118,15925,15927],{"className":15926,"code":1449,"language":123,"meta":124},[121],[21,15928,1449],{"__ignoreMap":124},[18,15930,1454],{},[118,15932,15934],{"className":15933,"code":1458,"language":123,"meta":124},[121],[21,15935,1458],{"__ignoreMap":124},[18,15937,1463,15938,1466],{},[21,15939,1107],{},[14,15941,1470],{"id":1469},[192,15943,1474],{"id":1473},[18,15945,1477],{},[192,15947,1481],{"id":1480},[18,15949,1484],{},[192,15951,1488],{"id":1487},[18,15953,15954,1493],{},[21,15955,526],{},[192,15957,1497],{"id":1496},[18,15959,1500],{},[192,15961,1504],{"id":1503},[18,15963,15964,1509,15966,1512,15968,1515],{},[21,15965,1247],{},[21,15967,1226],{},[21,15969,1236],{},[192,15971,1519],{"id":1518},[18,15973,1522],{},[14,15975,1526],{"id":1525},[99,15977,15978,15980,15982,15984,15986,15988,15990,15992,15998,16002],{},[102,15979,1531],{},[102,15981,1534],{},[102,15983,1537],{},[102,15985,1540],{},[102,15987,1543],{},[102,15989,1546],{},[102,15991,1549],{},[102,15993,15994,1554,15996,1557],{},[21,15995,1247],{},[21,15997,1226],{},[102,15999,1560,16000,1564],{},[21,16001,1563],{},[102,16003,1567],{},[14,16005,1570],{"id":1570},[99,16007,16008,16013,16018],{},[102,16009,16010],{},[77,16011,1580],{"href":1577,"rel":16012},[1579],[102,16014,16015],{},[77,16016,1587],{"href":1585,"rel":16017},[1579],[102,16019,16020],{},[77,16021,1594],{"href":1592,"rel":16022},[1579],[1596,16024,1598],{},{"title":124,"searchDepth":151,"depth":151,"links":16026},[16027,16028,16029,16030,16031,16040,16041,16042,16047,16048,16052,16056,16057,16058,16059,16067,16068],{"id":16,"depth":151,"text":16},{"id":73,"depth":151,"text":73},{"id":90,"depth":151,"text":90},{"id":93,"depth":151,"text":94},{"id":129,"depth":151,"text":130,"children":16032},[16033,16034,16035,16036,16037,16038,16039],{"id":194,"depth":157,"text":195},{"id":233,"depth":157,"text":234},{"id":256,"depth":157,"text":257},{"id":297,"depth":157,"text":298},{"id":329,"depth":157,"text":330},{"id":444,"depth":157,"text":445},{"id":479,"depth":157,"text":480},{"id":564,"depth":151,"text":565},{"id":597,"depth":151,"text":598},{"id":634,"depth":151,"text":635,"children":16043},[16044,16045,16046],{"id":638,"depth":157,"text":639},{"id":657,"depth":157,"text":658},{"id":702,"depth":157,"text":703},{"id":736,"depth":151,"text":737},{"id":1114,"depth":151,"text":1115,"children":16049},[16050,16051],{"id":1124,"depth":157,"text":1125},{"id":1137,"depth":157,"text":1138},{"id":1170,"depth":151,"text":1171,"children":16053},[16054,16055],{"id":1174,"depth":157,"text":1174},{"id":1200,"depth":157,"text":1200},{"id":1256,"depth":151,"text":1257},{"id":1295,"depth":151,"text":1296},{"id":1434,"depth":151,"text":1435},{"id":1469,"depth":151,"text":1470,"children":16060},[16061,16062,16063,16064,16065,16066],{"id":1473,"depth":157,"text":1474},{"id":1480,"depth":157,"text":1481},{"id":1487,"depth":157,"text":1488},{"id":1496,"depth":157,"text":1497},{"id":1503,"depth":157,"text":1504},{"id":1518,"depth":157,"text":1519},{"id":1525,"depth":151,"text":1526},{"id":1570,"depth":151,"text":1570},{},{"title":5,"description":1644},1785074510913]