- 博客(59)
- 收藏
- 关注
RSS订阅原创 Elasticsearch 生产环境全栈最佳实践：从架构设计到故障排查一站式落地指南
本文全面总结了Elasticsearch生产环境落地的最佳实践，涵盖集群架构设计、JVM优化、索引管理、性能调优等关键环节。针对不同规模集群提供了节点角色规划与硬件配置建议，详细阐述了JVM内存分配和GC调优策略，并深入解析了索引分片、Mapping设计等核心优化方法。文章还提供了可直接复用的配置模板和代码示例，帮助开发者构建高性能、高可用的ES集群，避免常见生产环境问题。
2026-03-19 01:13:15
428
原创 Elasticsearch 实战系列（二）：SpringBoot 集成 Elasticsearch，从 0 到 1 实现商品搜索系统
本文是Elasticsearch实战系列第二篇，详细介绍如何在SpringBoot项目中集成Elasticsearch，实现商品搜索系统。主要内容包括：ES Java客户端选型建议，重点推荐Spring Data Elasticsearch；环境准备中的版本匹配关系；通过注解方式定义商品实体类与ES索引的映射；以及分层架构设计思路。文章提供了完整的Maven依赖配置和YAML配置文件示例，帮助开发者从零开始构建ES集成方案，涵盖基础CRUD到复杂搜索功能的全流程实现。
2026-03-19 00:58:32
575
原创 Elasticsearch 实战系列（一）：从核心基础概念入门到实战落地
本文介绍了Elasticsearch的核心概念与应用场景。首先阐述了ES作为分布式搜索分析引擎的特性，包括高可用架构、近实时检索和强大的全文搜索能力。通过与MySQL的对比，明确了ES适用于全文检索、日志分析等场景。重点讲解了ES的核心概念：索引(类比数据库)、文档(类比数据行)、映射(定义字段类型)以及分片机制(实现水平扩展)。最后提供了版本选择建议，推荐使用7.17.10稳定版。全文帮助开发者快速理解ES的核心功能与适用场景。
2026-03-19 00:45:13
542
原创 利用SpringCloud Gateway 重试 + 降级解决第三方接口频繁超时问题，提升性能
本文介绍了在SpringCloud Gateway层实现统一重试+降级方案的完整实践。针对第三方接口不稳定的问题，传统业务层重试存在代码重复、逻辑分散、无降级兜底和POST请求无法重试等四大缺陷。通过Gateway层的统一处理，可以无侵入地解决这些问题。方案核心包括请求体缓存机制（解决POST重试难题）、指数退避重试机制和异常降级兜底机制，形成完整的闭环。重点实现了请求体缓存过滤器，通过装饰请求支持重复读取，同时设置合理的缓存策略防止内存溢出。该方案显著提升了微服务架构下对接第三方接口的稳定性。
2026-02-25 23:56:55
785
原创 消息队列消费性能优化：批量消费 + 手动 ACK 提升吞吐量
摘要：本文针对高吞吐场景下消息队列消费效率低下的问题，提出"批量消费+手动ACK"优化方案。通过分析传统单条消费模式的四大痛点，对比两种方案的核心差异，详细阐述了批量消费机制、手动ACK机制和消费节奏控制三大模块的设计思路。文章提供了基于Spring AMQP的完整实现方案，包括服务端核心逻辑和客户端监控系统，并总结了批量大小设置、等待时间优化等5个关键实践要点。该方案经实际验证可将消费速度提升10倍，CPU使用率降低60%，显著提升系统吞吐量和稳定性。
2026-02-22 23:58:11
859
原创 千万级数据批处理实战：SpringBoot + 分片 + 分布式并行处理方案
本文提出了一种基于SpringBoot和分布式协调的高性能并行处理方案，用于解决千万级数据批处理的性能瓶颈问题。传统单线程批处理存在效率低、资源浪费、容错差等痛点。该方案采用"分而治之"思想，通过三层架构（调度中心、分片协调器、执行节点）实现任务拆分和并行处理，支持ID范围分片和哈希分片两种策略。关键技术包括：利用Redis实现分布式协调和原子操作，集成Spring Batch构建健壮执行引擎，优化数据读取避免内存溢出。实验表明，该方案可将处理时间从天级缩短至小时级，提升系统性能和扩展性
2026-02-15 03:18:48
987
原创 SpringBoot + Redis 滑动窗口计数：打造高可靠接口防刷体系
本文针对互联网应用的接口防刷需求，提出基于SpringBoot与Redis ZSET的滑动窗口计数算法方案。该方案通过三层架构（请求入口→切面拦截→Redis存储）实现无侵入式防护，有效解决传统固定窗口算法的边界漏判问题。核心采用Redis ZSET存储请求时间戳，通过清理过期数据、实时统计请求数实现精准限流，并提供普通版与原子性版（Lua脚本）两种实现。方案支持多维度限流配置，异常时自动降级保障主业务，适用于登录、短信、支付等高危接口，可防御暴力破解、资源挤占等攻击，兼顾系统安全性与性能。
2026-02-15 03:02:13
803
原创 深度分析：RocketMQ 如何保证消息不丢失 —— 全链路防丢机制与生产实践
本文深入分析了RocketMQ如何通过全链路机制保证消息不丢失。文章指出消息丢失可能发生在三个阶段：生产者发送、Broker存储和消费者消费。针对每个阶段提出了解决方案：生产者应使用同步发送并开启重试；Broker需配置同步刷盘和同步主从；消费者必须确保业务处理完成后再ACK。最后强调消息可靠性是生产者、Broker和消费者三方协同的结果，给出了生产环境最佳实践配置方案，包括同步刷盘、同步主从等金融级保障措施。
2026-02-10 03:53:32
633
原创 深度分析 RocketMQ 四大核心消息：事务、顺序、批量、延时
消息类型核心解决问题核心机制性能典型场景事务消息分布式事务一致半消息 + 两阶段 + 回查中订单、支付、库存顺序消息消息严格有序同队列 + 单线程消费较低订单流程、状态机批量消息高吞吐、少 IO一次发送多条极高日志、数据同步延时消息延迟 / 定时执行定时调度 + 内部 Topic高超时关单、定时任务RocketMQ 的事务、顺序、批量、延时四大消息，覆盖了分布式系统90% 以上的复杂异步场景。事务消息保证数据一致顺序消息保证流程有序批量消息保证高吞吐延时消息实现定时能力。
2026-02-10 03:46:41
484
原创 深度分析 RocketMQ 幂等性设计与生产级实现方案
本文深入探讨了RocketMQ消息幂等性的设计与实现方案。首先分析了消息重复的必然性及其产生原因，包括Producer重试、Broker重投等场景。文章提出了幂等的核心概念，强调业务层必须自行实现去重机制。重点介绍了五种生产级幂等方案：数据库唯一索引、去重表+事务、Redis分布式锁、状态机幂等以及多级防御方案，其中状态机方案最为推荐。文章还提供了消费端编码模板，并总结了幂等设计的三大原则和生产最佳实践。最后强调幂等是分布式系统高可用的基础，通过合理设计可以实现“重复消息=安全跳过=最终一致“的效果。
2026-02-10 03:42:00
493
原创 深度分析 RocketMQ 消息存储机制 —— 高吞吐与高可靠的底层设计
RocketMQ 的高性能存储机制采用极简架构设计：所有消息全局顺序写入 CommitLog 文件，异步构建消费索引 ConsumeQueue 和查询索引 IndexFile。这种设计通过顺序写提升吞吐量，数据与索引分离确保写入不影响消费。消息写入流程包含同步写 CommitLog、异步构建索引、可选同步/异步刷盘策略。文件管理采用滚动生成和定时删除机制，保障性能稳定。同时支持主从同步和宕机自动恢复，兼顾高可用性。通过 mmap+PageCache+零拷贝技术实现磁盘性能最大化，是高性能消息中间件的典范设计
2026-02-10 03:34:17
845
原创 深度分析 RocketMQ 消息重试（重读）机制
RocketMQ的消息重试机制是分布式系统高可靠性的核心保障。当消费失败时，消息会自动进入专属重试队列（%RETRY%+消费组名），按照10s、30s、1m等18级延迟策略进行重试。默认最多重试16次，超过则转入死信队列（%DLQ%+消费组名）等待人工处理。生产环境必须注意：消费逻辑必须实现幂等性，合理设置重试次数（推荐3-5次），严格监控重试和死信队列，区分可重试与不可重试异常。该机制确保了消息至少投递一次（At Least Once），是构建高可靠消息服务的关键。
2026-02-10 03:22:16
477
原创 TCP 和 UDP 对比如何？
TCP和UDP是传输层两大核心协议。TCP面向连接、可靠但速度慢，通过三次握手、重传机制等保证数据不丢不乱，适用于网页、文件传输等场景。UDP无连接、不可靠但速度快，没有握手和拥塞控制，适用于游戏、直播等实时应用。关键区别在于：TCP保证数据完整性，UDP追求传输速度。实际应用中，HTTP/HTTPS用TCP，而HTTP/3基于UDP优化，体现了二者在不同场景下的取舍。
2026-02-08 01:15:36
472
原创 有了HTTP，为什么还需要WebSocket呢?
HTTP与WebSocket的区别及适用场景 HTTP协议存在单向通信、短连接等先天不足，无法满足实时通信需求，导致轮询等低效方案。WebSocket作为全双工、长连接的协议，实现了服务端主动推送、低延迟双向通信，显著降低了实时应用的开销。两者的核心区别在于通信方式（单向vs双向）、连接状态（短连接vs长连接）和服务端推送能力。典型场景中，HTTP适合资源获取，WebSocket则专精于聊天、直播、游戏等实时交互。两者互补共存，WebSocket通过HTTP升级建立连接，为现代Web应用提供了高效的实时通信
2026-02-08 01:08:00
639
1
原创 HTTP状态码与缓存机制
本文全面介绍了HTTP状态码和缓存机制。状态码分为5类：1xx(处理中)、2xx(成功)、3xx(重定向)、4xx(客户端错误)、5xx(服务端错误)，详细解析了200、304、401、404、500等常见状态码的含义。HTTP缓存分为强制缓存(直接使用本地缓存)和协商缓存(向服务器验证)，重点讲解了Cache-Control、ETag等核心字段，以及完整的缓存流程。文章还提供了企业级缓存策略建议，如HTML使用no-cache、静态资源设置长期缓存等，并解答了常见问题。掌握这些知识能有效提升Web性能优化
2026-02-08 01:02:17
527
原创 HTTP各版本演进与区别
HTTP协议演进历程摘要：HTTP/0.9（1991）仅支持GET请求，无状态无头；HTTP/1.0（1996）引入请求头/响应头和多种方法；HTTP/1.1（1999）成为主流，支持长连接和Host头但存在队头阻塞；HTTP/2（2015）采用二进制分帧和多路复用提升性能，但仍有TCP层阻塞；HTTP/3（2022）基于QUIC/UDP协议，彻底解决队头阻塞，支持0-RTT握手和连接迁移。当前HTTP/1.1仍广泛使用，HTTP/3正逐步成为未来标准。
2026-02-08 00:56:00
874
原创 有 HTTP 了为什么还要有 RPC？
HTTP与RPC在分布式系统中各有所长。HTTP作为通用协议，适合跨平台、异构系统间的通信，但其报文冗余、序列化效率低、缺乏服务治理能力等特性，难以满足微服务高并发、低延迟的需求。RPC框架通过自定义私有协议、高效二进制序列化、本地化调用体验和内置服务治理能力，针对性解决了分布式通信的痛点。RPC将远程调用封装为本地函数调用，显著提升开发效率和系统性能，更适合服务间高频调用的场景。二者并非替代关系，而是互补共存，HTTP侧重通用性，RPC专注高性能服务治理。
2026-02-07 00:36:22
730
原创 计网核心协议与IP地址分类
本文系统介绍了计算机网络核心协议与IP地址分类。首先阐述了数据链路层的MAC地址、网络层的IP地址和传输层的TCP协议三大核心标识/协议的功能特点与协同关系。其次解析了ARP/RARP协议在IP与MAC地址转换中的关键作用，以及DHCP协议实现IP自动配置的工作原理。最后详细分类说明了A/B/C/D/E五类IPv4地址的划分规则、结构特征及适用场景，并列举了特殊用途IP地址。这些内容构成了计算机网络寻址与通信的基础知识体系。
2026-02-07 00:24:48
799
原创 计网ping原理
摘要：ping命令是基于ICMP协议的网络连通性检测工具，通过发送回送请求报文(Type=8)和接收回送应答报文(Type=0)来测试主机可达性、延迟和丢包率。其工作流程包括DNS解析、报文构造、IP封装、网络传输、应答处理和结果统计。ping具有轻量无连接的特性，但不依赖端口且仅检测IP层连通性，成功不代表应用层服务正常，失败也不一定表示网络不通。常用参数可控制发送次数(-n/-c)和数据大小(-l/-s)，输出结果包含延迟、TTL和丢包率等关键指标。
2026-02-07 00:11:00
465
原创 UDP如何访问DNS?
DNS 默认首选 UDP 作为传输协议，主要因其无连接、高效率特性完美匹配 DNS 查询需求。UDP 无需握手降低延迟，小数据包传输效率高，服务器资源占用少可支撑高并发。DNS 通过客户端重试机制弥补 UDP 不可靠性。当响应数据超过 512 字节或进行区域传输时，DNS 会切换至 TCP。EDNS0 扩展机制进一步优化 UDP 传输能力。这种协议选择体现了业务需求与协议特性的精准匹配，UDP 的高效与 TCP 的可靠形成互补，共同支撑 DNS 服务的高性能运行。
2026-02-07 00:03:04
400
原创 计网：输入网址到网页显示
本文详细解析了从输入网址到网页显示的全过程，包括DNS解析、TCP三次握手、HTTP请求与响应、页面渲染以及TCP四次挥手等核心环节。重点阐述了DNS递归与迭代查询原理、TCP连接的可靠建立与断开机制、HTTP报文封装与传输流程，以及浏览器渲染DOM树和CSSOM树的步骤。文章还总结了网络优化策略如DNS缓存、CDN加速、HTTP/2多路复用等技术要点，为理解计算机网络工作原理和应对相关面试提供了系统性的知识框架。
2026-02-06 23:45:11
613
原创 计算机网络核心网络模型
本文系统梳理了计算机网络的两大核心模型：理论标准的OSI七层模型和工业实践的TCP/IP四层模型。OSI模型精细划分通信流程，包含物理层到应用层七层结构；TCP/IP模型则简化为应用层、传输层、网际层和网络接口层四层。文章详细对比了两者的分层差异、协议对应关系，并解析了数据封装/解封装的核心流程，最后总结了路由器、交换机等设备的工作层级以及ARP、TCP/UDP等关键协议的分层归属。作为网络通信的基础架构，这些模型为理解网络协议栈和实际开发提供了重要框架。
2026-02-05 23:50:41
930
原创 23种设计模式
本文系统介绍了后端开发必备的23种设计模式，分为创建型、结构型和行为型三大类。设计模式是前人总结的可复用解决方案，遵循七大设计原则，能有效提升代码的可复用性、可扩展性和可维护性。文章详细解析了单例、工厂、适配器、策略等高频模式的应用场景和实现要点，并提供了实战选型指南。同时强调要避免过度设计，理解设计原则比死记硬背模式更重要。掌握设计模式能帮助开发者从"会写代码"进阶到"写好代码"，构建高内聚低耦合的系统架构。
2026-02-04 23:52:44
566
1
原创 Redis 故障转移：哨兵vs集群
Sentinel 节点：独立运行的特殊 Redis 进程，不存储业务数据，仅负责节点监控、主观 / 客观下线判定、领头选举、故障转移执行，建议部署奇数台（3/5）防止脑裂；Master 主节点：处理业务读写请求，同步数据至从节点；Slave 从节点：默认只读，作为主节点副本，故障时成为新主候选节点。Redis 故障转移是高可用架构的核心环节，哨兵模式适合主从架构的轻量容灾，部署简单、运维成本低；集群模式适合分布式分片场景，兼具扩容与高可用能力。
2026-02-03 23:43:52
866
原创 对比一下RabbitMQ和RocketMQ
RabbitMQ和RocketMQ作为主流消息中间件，在设计理念、架构和性能上存在显著差异。RabbitMQ基于AMQP协议，以灵活路由和企业级集成为核心，采用队列独立存储模式，适合复杂消息分发场景；RocketMQ源自阿里电商业务，专注高吞吐和可靠性，采用存储与索引分离架构，支持亿级消息堆积，适合互联网高并发场景。
2026-02-02 23:59:07
1071
原创 SpringBoot+Caffeine+Redis实现多级缓存
本文系统介绍了多级缓存技术的核心概念、架构设计与实战应用。主要内容包括： 多级缓存定义与分层结构：通过本地缓存（Caffeine）+分布式缓存（Redis）+数据库缓存构建三级缓存体系，各层性能互补 核心优势：对比单一缓存，多级缓存可提升20倍QPS、降低60%延迟、减少87%数据库负载 设计原则：请求就近访问、数据分层存储、失效由上至下 主流架构：详细解析Caffeine+Redis二级缓存的读写流程和数据更新机制 实战实现：基于SpringBoot整合Caffeine和Redis，提供可落地的配置方案。
2026-02-01 21:51:17
1138
4
原创 Apache RocketMQ的原理与实践
摘要：Apache RocketMQ作为阿里开源的分布式消息中间件，具备高可靠性和高吞吐性能，适用于金融、电商等场景。其架构包含NameServer、Broker、Producer和Consumer四大组件，支持主从复制、分布式事务、顺序消息等核心特性。RocketMQ通过消息队列、分组标识等概念实现系统解耦和流量削峰，并提供消息回溯、死信队列等企业级功能，成为互联网后端开发的主流选择。
2026-01-31 23:55:51
914
原创 Redis 哨兵机制
Redis哨兵机制是官方提供的高可用解决方案，基于主从复制架构实现自动故障转移。核心设计目标包括监控节点状态、通知故障信息、自动故障转移和提供配置服务。哨兵集群由主节点、从节点和哨兵节点组成，采用"一主多从多哨兵"的分布式部署架构，建议至少3个哨兵节点。工作机制分为日常监控、故障判定和故障转移三个阶段：通过心跳检测监控节点状态，当主节点被多数哨兵判定为客观下线时触发故障转移，自动选举新主节点并完成主从切换。哨兵机制实现了秒级故障恢复和客户端无感知切换，有效解决了原生主从复制的单点故障问题
2026-01-30 00:49:08
687
原创 Redis 持久化机制
Redis持久化机制解析 Redis提供RDB和AOF两种持久化方式。RDB通过定时全量快照保存数据，采用fork子进程+写时复制机制实现，具有文件小、恢复快的优点，但存在数据丢失风险。AOF通过记录写命令实现持久化，支持不同同步策略，数据安全性更高但文件体积较大。实际生产环境推荐混合使用两种方式，并合理配置持久化参数，在数据可靠性和性能间取得平衡。
2026-01-30 00:42:43
605
原创 Redis 线程模型和网络模型
Redis高性能的核心在于其独特的线程模型与网络模型设计。线程模型采用"单线程核心+多线程辅助"架构，主线程处理核心命令执行，网络IO、持久化等耗时操作由多线程异步处理，既保证原子性又避免阻塞。网络模型基于Reactor模式，通过IO多路复用实现高并发处理，6.0+版本引入多线程网络IO进一步优化性能。这种设计充分发挥内存操作优势，避免线程切换开销，使Redis单核即可支持十万级QPS，同时保持代码简洁高效。
2026-01-30 00:36:29
810
原创 Redis缓存更新策略
缓存更新的本质，是在「性能」和「数据一致性」之间做权衡最终一致性是大部分业务的最优选择：除金融、支付、核心库存等强一致性场景外，90% 以上的业务都可容忍短暂的数据不一致，优先选择缓存过期自动淘汰或更新数据库后淘汰缓存**，兼顾性能和开发效率。删除缓存是比更新缓存更安全的选择：并发写场景下，更新缓存必然导致脏数据，而删除缓存能从根本上规避该问题，这是缓存更新的核心设计技巧。异常容错是缓存更新的必备环节：任何策略都要考虑操作失败的场景（如网络超时、服务宕机），通过重试机制和过期兜底，避免脏数据无限扩散。
2026-01-30 00:28:49
869
原创 Redis 过期删除与内存淘汰机制
Redis内存管理通过过期删除和内存淘汰两大机制协同工作。过期删除采用惰性删除与定期删除组合策略，在访问时检查和定时抽样清理过期键。内存淘汰在内存达到阈值时，根据配置策略（如LRU、LFU）主动删除键释放空间。二者触发条件不同但相互补充，确保Redis在有限内存下高效稳定运行。合理配置相关参数可优化内存使用效率，满足不同业务场景需求。
2026-01-30 00:25:20
786
原创 从原理、场景、解决方案深度分析Redis分布式Session
Redis分布式Session是解决分布式系统中Session共享的主流方案，通过将Session数据集中存储在Redis集群中，实现全局访问和高可用性。其核心原理包括：Session数据抽离到Redis、全局唯一SessionID、Redis键过期策略管理生命周期、原子性操作保证一致性。相比本地Session，具有全局共享、高容灾、易扩容等优势。
2026-01-29 00:26:09
1109
原创 从原理、场景深度分析Redis的分布式限流机制，根据不同场景设计合适的解决方案
Redis分布式限流利用Redis单线程原子性、高性能和共享存储特性，提供计数型（固定/滑动窗口）和令牌桶型两种核心方案，适用于接口限流、资源保护、业务防刷等场景。生产环境推荐Lua脚本实现原子化操作，或使用Redisson组件，前者适合自定义限流规则，后者内置令牌桶等高级算法。关键优势在于解决分布式系统全局控速问题，避免单机限流统计不一致。
2026-01-29 00:10:35
1073
原创 从场景思考并分析MySQL读写分离问题的解决方案
MySQL读写分离核心摘要 MySQL读写分离通过主库处理写操作、从库分散读请求来提升数据库并发能力，适用于读多写少（如电商查询、资讯平台）、读写压力隔离（报表统计）、异地就近访问等场景。 解决方案分层实施：微延迟业务可兼容；中延迟业务精细化路由（强实时读走主库）；高延迟需优化复制机制。同时需合理设计分发策略、处理事务一致性、确保高可用，并考虑分库分表兼容性。
2026-01-28 00:56:36
1176
原创 如何解决MySQL热点行更新时导致的问题
MySQL热点行更新问题在高并发场景下会引发锁竞争、CPU过载、事务超时等一系列性能问题。本文分析了四种解决方案：1）库存拆分法，通过将单行数据拆分为多行分散锁竞争；2）请求合并法，将多个更新请求合并为批量操作；3）写扩散法，将更新转为插入日志后异步处理；4）MySQL内核改造，在执行层实现轻量级排队。每种方案各有优劣，适用于不同业务场景，需结合数据一致性要求、延迟容忍度和开发成本进行选择。建议采用分层优化策略，综合应用层缓存、数据拆分和异步处理等手段实现最佳性能。
2026-01-28 00:39:12
566
原创 从线上排查流程、执行计划分析与根本原因定位分析解决MySQL的慢SQL问题
MySQL慢SQL分析与优化指南 摘要：MySQL慢SQL是数据库性能下降的主要原因，表现为执行时间超过阈值（默认1秒）。本文系统介绍了慢SQL的危害、常见场景和标准化排查流程。核心排查步骤包括：开启慢查询日志捕获问题SQL、紧急恢复业务、使用EXPLAIN分析执行计划、结合数据库状态补充分析。重点解读了EXPLAIN执行计划中的关键字段，特别是type访问类型（从最优const到最差ALL），强调至少要达到range级别。最后给出了优化验证方法和预防体系建议，形成完整的“排查-分析-优化-预防“闭环解决。
2026-01-27 19:56:55
1286
原创 MySQL锁机制的核心问题场景、线上排查以及解决方案
MySQL 锁机制是保证数据并发访问一致性的核心，但在生产环境中容易引发死锁、锁等待、锁冲突等问题。本文分析了六大核心锁问题：死锁、锁等待超时、锁竞争、行锁升级表锁、幻读和间隙锁阻塞，并提供了具体场景示例。针对死锁问题，重点介绍了跨事务加锁顺序不一致的典型场景，以及通过show engine innodb status排查死锁日志的方法。解决方案包括规范加锁顺序、缩短事务生命周期、捕获死锁异常重试等技术手段。对于锁等待超时问题，分析了长事务、慢SQL等典型场景，并提供了排查思路。
2026-01-27 19:54:50
1122
原创 从原理到性能优化深度分析MySQL的order by处理
摘要 MySQL的ORDER BY语句是实现数据排序的核心功能，其性能优化对数据库查询效率至关重要。本文深入分析了ORDER BY的两种底层实现方式：高效的索引排序和低效的文件排序，指出优化目标是尽可能使用索引排序。文章列举了五大典型使用场景（基础排序、多字段排序、分页查询、函数排序和联合查询排序）及其性能痛点，并剖析了四大常见性能问题的根源：未建索引、违反最左匹配原则、函数导致索引失效以及大偏移量分页查询。通过揭示这些原理和问题，为开发者提供了优化ORDER BY性能的理论基础和实践方向。
2026-01-26 01:50:44
667
原创 深入理解MySQL日志的六大核心类型
MySQL日志体系是保障数据库高可用、可恢复和性能调优的核心组件。主要包括六大类日志：事务日志（redo log和undo log）确保事务ACID特性，二进制日志（binlog）实现主从同步和数据恢复，慢查询日志用于性能优化，以及错误日志、查询日志和中继日志。redo log通过顺序写提升性能并保证持久性，undo log支持事务回滚和MVCC。binlog以三种格式记录数据修改，是分布式架构的基础。慢查询日志帮助定位性能瓶颈。掌握这些日志的原理和使用场景，能有效解决生产环境中的数据恢复、性能优化等问题。
2026-01-26 01:48:56
1004
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人