- 博客(87)
- 收藏
- 关注
RSS订阅原创 Redisson分布式锁 和 乐观锁的使用场景
本文分析了礼品卡管理系统中激活操作的并发控制方案。传统使用Redisson分布式锁在大批量激活时存在性能问题，包括Redis连接开销大、内存占用高和网络延迟累积。Redisson锁更适合锁定整个业务流程（如订单创建、会员充值等复合操作），而礼品卡激活更适合采用版本号乐观锁机制。乐观锁通过添加version字段实现无锁并发控制，具有开销低、扩展性好和精确冲突检测等优势，能有效处理大批量礼品卡激活场景，同时保证数据一致性。应根据业务场景特点选择合适的并发控制方案。
2025-12-02 02:42:41
371
原创 为什么仅靠“版本号”不够？为什么需要以“消费房间”为粒度的分布式锁？
本文分析了在创建订单过程中使用乐观锁和分布式锁的差异。乐观锁（版本号）仅能保证单次更新的原子性，无法保护多步骤业务流程的完整性，存在数据不一致风险。而分布式锁（如Redisson）能保护整个业务流程，通过以"消费房间"为粒度加锁，既确保订单创建期间禁止修改，又不影响其他房间操作。文章指出，这种方案符合DDD聚合一致性边界原则，是保障高并发场景数据一致性的最佳实践。最后强调技术选型应基于业务本质，分布式锁在该场景下比乐观锁更精准高效。
2025-12-02 02:16:02
352
原创 Redis相关面试题
Redis性能优异主要基于三点：1）纯内存操作，读写速度远快于磁盘；2）核心命令单线程执行，避免多线程开销；3）I/O多路复用技术（如epoll）高效处理海量连接。6.0+版本虽引入多线程网络I/O，但命令执行仍保持单线程以确保原子性。持久化等后台任务由子进程处理，不影响主线程性能。
2025-11-24 22:48:22
193
原创 Spring、Spring MVC 和 Spring Boot ，mybatis 相关面试题
MyBatis中#{}和${}的核心区别在于安全性：#{}采用预编译机制防止SQL注入，将参数视为纯数据；${}是直接字符串替换，存在SQL注入风险。最佳实践是优先使用#{}，仅在动态表名/列名等特殊场景谨慎使用${}，但必须配合严格的白名单校验。例如雪花ID分表时，应由服务端解析安全后缀而非直接使用用户输入，确保${}使用的安全性。
2025-11-24 19:54:16
349
原创 redis 和 数据库如何保持一致性问题
摘要：在数据库与缓存双写场景中，常规"先更新数据库再删缓存"策略在并发操作下可能出现数据不一致问题。通过延迟双删策略（先删缓存→更新数据库→延迟100ms→再删缓存）可有效解决这一问题，确保更新期间回填的脏数据被清除。典型场景分析显示，当多个写请求与读请求并发时，延迟双删能保证最终数据一致性，避免缓存中留存旧值的情况。
2025-11-24 03:41:36
232
原创 如何用 Redis 实现千万级实时积分排行榜？
摘要：针对千万级实时排行榜系统，本文提出分桶方案解决传统ZSet大Key问题。方案采用三个核心结构：1)Hash存储用户积分映射；2)按分数区间分桶的ZSet；3)Hash记录各桶人数。通过Lua脚本实现原子操作，查询时先定位用户所在桶，再累加更高分桶人数与桶内更高分人数得出精确排名。该方案支持同分并列，单次操作延迟低于2ms，内存占用优化显著（千万用户约1GB），有效解决了大ZSet导致的性能瓶颈和运维问题。
2025-11-23 23:50:55
912
原创 为什么有了乐观锁，我们仍选择 Redisson 悲观锁？
本文探讨了在并发控制中混合使用悲观锁与乐观锁的实践方案。通过分析读写分离延迟、业务流程完整性、用户体验等维度，指出在低并发场景下，Redisson分布式悲观锁能有效解决乐观锁的局限性：避免主从延迟导致的误判、确保业务流程原子性、将失败转化为等待提升用户体验。同时保留MySQL乐观锁作为兜底防线，形成纵深防御体系。这种设计虽增加轻微性能开销，但显著提升了系统可靠性和业务一致性，实现了"慢成功优于快失败"的工程权衡。
2025-11-23 00:14:24
478
原创 在技师上钟系统中实现WebSocket集群架构，以及如何结合RocketMQ来处理定时任务，从而构建一个高可用、可扩展的实时通知系统
摘要 本文介绍了技师上钟系统中WebSocket集群和RocketMQ定时任务的技术实现方案。系统采用基于Redis和RocketMQ的WebSocket集群架构，通过多节点维护会话连接，结合消息广播实现实时通知。关键技术点包括：1) WebSocket配置注册多个处理器；2) 集群实现通过本地会话检查和Redis全局存储；3) 心跳检测机制保持连接活跃；4) RocketMQ处理定时任务。该方案实现了高可用、可扩展的实时通信系统，满足技师上钟业务场景的需求。
2025-11-19 03:18:10
1084
1
原创 开发中常见的数据加密方式：不可逆加密 和 可逆加密 以及对称加密与非对称加密的关系和区别
加密技术可分为三类：不可逆加密（哈希算法）用于密码存储和数据校验，推荐bcrypt等安全算法加盐处理；对称加密（如AES）适合高频加密，但需严格管理密钥；非对称加密（RSA/ECC）用于安全通信和数字签名。实际应用中，HTTPS采用混合加密机制，业务系统则通过签名验证实现身份认证。三类技术各司其职，需根据场景组合使用，兼顾安全与效率。密钥管理和算法选择是保障系统安全的关键。
2025-11-18 20:54:46
674
原创 收银台系统如何实现跨库分布式事务？——基于本地消息表与 MQ 的最终一致性实践
本文介绍了金融级系统中解决跨库一致性的轻量级方案。针对收银台用户权益支付场景，采用"本地消息表+XXL-JOB+RocketMQ"的组合方案替代分布式事务框架Seata，通过事务内同步写入业务数据和消息记录，由定时任务异步补偿消息投递，最终实现可靠消息驱动型的最终一致性。该方案具有强一致性、服务解耦、高可用和轻量可控等优势，已在生产环境支撑数亿级交易，验证了其稳健性。
2025-11-16 22:33:44
805
原创 腾讯二面：如何保证MQ消息不丢失？重复消费如何保证幂等，本地消息表配合MQ实现最终一致性？
腾讯二面记录：针对MQ消息可靠性问题，主要考察两方面：1）防止消息丢失，需通过生产者确认、Broker持久化、消费者确认机制实现端到端保障；2）处理重复消费，可通过业务唯一标识、数据库乐观锁或Redis原子操作实现幂等控制。面试重点在于系统架构设计中对消息可靠性与一致性的解决方案。
2025-11-16 21:34:54
735
原创 一锁、二判、三更新：Redisson 锁、MySQL 乐观锁、状态机别再混淆了！一文讲清它们到底解决什么问题
本文剖析了Redisson分布式锁、MySQL乐观锁和状态机的核心区别与应用场景：Redisson锁通过悲观策略控制同步请求的并发访问；MySQL乐观锁通过version字段实现无锁并发控制，适合批量任务和重试场景；状态机则通过WHERE条件防止非法状态跳转，尤其适用于异步流程。三者各司其职，最佳实践是"一锁、二判、三更新"的组合策略：同步请求优先使用Redisson锁，异步场景依赖数据库WHERE条件双重校验。文中通过真实案例展示了在支付回调、数据迁移等场景下的正确应用方式，强调安全兜
2025-11-15 07:27:00
1063
原创 跨年查不到订单？一个雪花 ID 分库路由引发的“时间穿越” Bug
《跨年订单消失之谜：时间错位引发数据库路由故障》 摘要：某系统在跨年时发生诡异故障——用户查询正常但订单详情404。排查发现，系统采用按年分库策略，订单ID使用含时间戳的雪花算法。跨年前查询2023年的订单，跨年后系统却默认查询2024年库，导致路由错误。解决方案是重构路由逻辑：通过解析雪花ID中的生成时间决定查询库，而非依赖当前时间。这个小故障揭示了分布式系统中"时间上下文错位"的经典陷阱，同时反映出雪花ID虽然具备反推时间优势，但也存在存储和索引性能问题，需要权衡取舍。（149字）
2025-11-15 04:41:54
208
原创 Redis 读写分离架构下用 Redisson 上锁安全吗？并发读会出问题吗？
本文探讨Redis主从架构下Redisson分布式锁的安全性问题。对于主从复制延迟导致的锁丢失问题，指出Redis作为AP系统的局限，但强调可通过数据库状态机(如带条件的SQL更新)实现业务兜底。同时解释Redisson锁操作不受从节点影响，所有锁操作都通过Lua脚本在主节点执行，确保原子性。建议金融等关键业务可选用ZooKeeper，而常规业务通过数据库状态机+Redis锁的组合即可保障数据一致性。
2025-11-15 04:20:25
910
原创 中小公司别被微服务“绑架”了！不拆微服务，也能高可用：中小团队的轻量级分布式单体实践
本文分享了一种适合中小团队的“轻量级分布式单体”架构方案。该方案在保留单体应用优势的同时，通过中间件实现分布式能力：使用JWT+HttpClient处理服务调用，Redisson分布式锁保障并发安全，按年分库控制数据规模，OSS直传优化文件处理。相比传统微服务，该架构开发调试更简单、性能更稳定（核心接口P99<80ms），运维成本更低（无需注册中心/配置中心/网关）。文章强调架构选择应匹配团队规模（10人以下）和业务阶段（日均数十万订单），认为简单可靠的方案比盲目追求技术先进性更重要。
2025-11-15 01:07:29
749
原创 RocketMQ消费组详解：构建高可用消息消费系统
RocketMQ消费组是构建高可用消息系统的核心机制。本文通过电商订单系统Demo，详细解析消费组的关键特性：1) 同一消费组内消费者分摊消息处理，避免重复消费；2) 支持集群和广播两种模式；3) 提供故障自动转移能力；4) 实现业务隔离和水平扩展。文章展示了订单创建、日志记录等典型场景的代码实现，分析了负载均衡机制和容错原理，并提供了命名规范、分组策略等最佳实践。合理使用消费组能显著提升系统处理能力、容错性和可维护性。
2025-11-13 21:07:36
620
原创 RocketMQ微服务架构实践：从入门到精通完整指南
本文以电商场景为例，系统介绍RocketMQ在微服务架构中的应用实践。通过小明水果店的业务场景（订单处理、库存扣减等），展示如何使用RocketMQ实现服务解耦和异步处理。文章涵盖基础概念（生产者、消费者、Topic）、项目结构设计，并提供了核心代码示例，包括订单创建消息发送和库存扣减消费逻辑。通过具体案例讲解RocketMQ如何提升系统性能与可靠性，适合开发者从入门到进阶系统学习。完整代码可通过指定链接下载实践。
2025-11-13 20:13:15
932
原创 RocketMQ 中顺序消费的实现及面试回答
摘要：RocketMQ在常规场景（如日志、通知）支持并发消费以提高吞吐量，但在订单处理等关键业务中需保证顺序消费。实现方式：生产端通过订单ID取模将相关消息路由至同一队列；消费端使用MessageListenerOrderly同步处理，确保同一队列消息按序执行。这种"归堆+排队"机制既能保证特定业务顺序，又不影响其他消息的并行处理能力。
2025-11-13 03:01:52
389
原创 用 RocketMQ 写个“自动取消订单并释放库存” —— 从发消息到防翻车全攻略
文章摘要： 本文详细介绍了如何利用RocketMQ实现电商订单30分钟未支付自动取消的高可靠方案。核心方案包括：通过延迟消息触发超时处理，消费者采用数据库条件更新实现幂等操作，死信队列兜底异常消息，并通过本地消息表（Outbox模式）保证订单创建与消息发送的最终一致性。文章对比了同步/异步发送的适用场景，强调幂等设计、重试机制和监控告警的重要性，最终构建了一个能应对高并发、网络抖动和服务器故障的稳健系统。
2025-11-13 00:17:31
995
原创 ThreadLocal 在项目中的应用
本文摘要：ThreadLocal是Java线程本地存储机制，通过为每个线程维护变量副本实现线程安全的数据共享。文章结合消息中心项目，展示了ThreadLocal在管理用户登录信息和第三方应用凭证等场景的应用实践，重点分析了其核心原理、典型实现模式（如SecurityContextHolder）及生命周期管理策略。特别强调了使用规范，包括必须及时remove()防止内存泄漏，以及异步场景下ThreadLocal的局限性（需使用InheritableThreadLocal）。通过拦截器机制确保线程上下文的安全创
2025-11-03 21:48:03
992
原创 Nginx相关调试命令大全
本文整理了Nginx调试与运维的实用命令大全，包括基础访问测试、服务管理、日志查看、权限检查、SSL证书验证、网络防火墙检查以及故障排查方法。涵盖从配置语法检查到实时日志监控，从SSL证书验证到网络连通性测试等关键运维操作。同时提供了常见问题速查表，如502错误、403禁止访问、SSL证书错误等典型问题的解决方案。适用于大多数Linux环境下的Nginx部署与维护工作，帮助管理员快速定位和解决问题。
2025-10-29 03:17:39
272
原创 通过HTML演示JVM的垃圾回收-新生代与老年代
摘要：JVM内存管理主要分为新生代和老年代。新生代包含Eden区和两个Survivor区（S0、S1），采用8:1:1比例分配。新对象首先分配在Eden区，触发MinorGC时存活对象复制到Survivor区，经过多次GC(年龄达到阈值)后晋升老年代。Survivor区通过复制算法筛选长期存活对象，避免老年代过早填满。大对象可能直接进入老年代。GC分为MinorGC(新生代)、MajorGC(老年代)和FullGC(整堆)，其中FullGC应尽量避免。该机制有效管理对象生命周期，优化内存使用效率。
2025-10-03 11:44:41
1093
1
原创 索引底层数据结构为什么不选择二叉树，红黑树和B树而是选择B+树呢
索引是提高数据库查询效率的数据结构。常见索引底层结构包括二叉树、红黑树、B树和B+树。二叉树在递增数据下会退化为链表，效率降至O(n)。红黑树虽避免退化，但树高仍较大。B树通过多叉结构减少树高，但节点同时存储数据和索引。B+树是优化版本，仅非叶节点存索引，叶节点存数据并双向链接，既降低树高又提升范围查询效率，是数据库索引的主流选择。
2025-09-10 18:47:39
276
原创 1000万数据下 IN 查询性能实测，MySQL索引陷阱：IN查询为何“失效”？
摘要：本文通过实战案例分析了MySQL中IN查询的性能差异及优化方案。当IN查询条件命中复合索引的最左前缀时（如report_date），查询速度较快（0.8s）；而跳过最左列直接查询staff_id会导致全表扫描（3.015s）。优化建议包括：为高频字段单独建索引（提升120倍）、控制IN列表长度（<1000）、使用覆盖索引减少回表操作，以及通过EXPLAIN监控执行计划。关键结论是：IN查询性能取决于索引设计，需遵循最左前缀原则，避免超长IN列表触发优化器改用全表扫描。
2025-09-06 17:46:27
521
原创 JMeter下载安装及使用入门
Apache JMeter是一款开源性能测试工具，主要用于测试Web应用、FTP服务器、数据库等服务的性能表现。文章以JMeter5.5为例，介绍了其四步使用方法：1)创建测试计划；2)添加线程组；3)配置取样器参数；4)查看测试结果。重点讲解了参数化测试的实现方法，包括创建CSV测试数据文件、配置CSV数据文件设置以及在测试中引用参数值。此外还介绍了接口测试用例的编写要点，包括业务功能验证、参数边界测试、异常场景测试等，并列举了JMeter的常用功能模块如响应断言、HTTP请求、聚合报告等。
2025-09-03 23:39:10
895
原创 用 MyBatis-Plus MetaObjectHandler 统一处理公共字段,减少重复代码
MyBatis-Plus的MetaObjectHandler可自动处理公共字段赋值问题，如创建时间、更新时间、创建人等。通过实现该接口，系统能在插入或更新时自动填充这些字段，无需手动设置。自定义处理器会检查字段是否存在且为空，再自动填充默认值（如ID、逻辑删除标志等）。这有效减少代码冗余，提高规范性，但对于需要提前获取ID的业务场景（如订单关联），仍需手动赋值。该方案平衡了自动化与灵活性，使系统更健壮。
2025-09-02 14:06:17
413
原创 MyBatis 连表查询优化：用 resultMap + autoMapping 绑定嵌套查询对象
本文介绍了如何通过MyBatis实现商品属性分组与属性项的关联查询，重点演示了如何利用resultMap和autoMapping="true"简化XML配置。文章首先展示了需求场景和BO对象设计（包含嵌套类），然后对比了传统手动映射字段和优化后的自动映射方案。通过autoMapping特性，MyBatis能自动将下划线命名的数据库字段映射到驼峰命名的Java属性，显著减少了重复配置，提高了开发效率和代码可维护性。该方法特别适用于字段名遵循下划线转驼峰命名规则的场景。
2025-08-31 00:23:11
431
原创 记一次雪花算法 ID 精度丢失的Bug：前端接收到的 Long 被“四舍五入”了？
本文分析了雪花算法ID在前后端传输中精度丢失的问题，指出根本原因是JavaScript的Number类型无法精确表示19位Long型整数。作者提出了一种SpringBoot全局配置方案：通过Jackson将Long类型序列化为字符串，确保前端接收时保持完整精度。文章对比了多种解决方案，推荐采用全局配置+按需排除的方式，既能一劳永逸解决问题，又保持了代码的简洁性。这种方案无需修改实体类，对现有系统侵入性小，是处理大整数传输问题的有效方法。
2025-08-28 19:53:58
1018
原创 记一次糟糕的 MyBatis-Plus 查询设计：那个“非得查 COUNT”的分页坑
《MyBatis-Plus分页设计的性能陷阱与优化实践》摘要： 文章揭示了MyBatis-Plus分页查询的两大痛点：1）默认强制COUNT查询导致性能浪费；2）参数Map设计造成前后端协作困难。作者通过实践提出优化方案：采用类型安全的Query对象替代Map参数提升可维护性，并通过PageResult封装实现逻辑隔离。尽管受限于框架无法完全避免COUNT查询，但建议通过职责分离（独立list/count方法）和减少分页插件使用来优化性能。核心观点指出：框架的便利性可能违背设计原则（如迪米特法则），高并发场
2025-08-27 21:24:10
899
原创 大数据量场景下，深度分页的解决方案
大数量级场景下，深度分页查询面临性能瓶颈。本文针对电商订单表等大数据量场景，分析传统分页方式（如LIMIT 19980,20）导致的I/O资源浪费和查询效率问题，提出四种优化方案：1）游标分页（基于有序字段避免OFFSET扫描）；2）延迟关联（通过子查询减少回表）；3）覆盖索引优化（创建包含查询字段的联合索引）；4）数据预取与缓存。这些方案可显著提升查询性能，特别适用于高频查询场景。同时建议将列表查询与详情查询分离，对大量ID查询采用分批处理或缓存优化。
2025-08-27 01:59:44
825
原创 记一次 P6Spy + Druid 冲突排查：DBType not support : null 的根源与解决
文章摘要：在集成P6Spy进行SQL性能监控时，项目启动报错"DBType not support: null"。问题根源在于P6Spy修改了JDBC URL前缀（jdbc:p6spy:mysql），导致Druid的WallFilter无法识别数据库类型。解决方案包括：1）开发环境可移除WallFilter；2）生产环境建议保留WallFilter的安全防护功能。该问题体现了中间件集成时URL代理机制引发的兼容性问题。
2025-08-26 16:21:13
509
原创 零侵入式 SQL 监控：用 P6Spy 快速定位数据库问题
P6Spy是一个无侵入式的JDBC代理框架，能够实时拦截并记录数据库操作，帮助开发者快速定位SQL问题。它通过伪装成JDBC驱动，在不修改业务代码的情况下捕获完整SQL语句和执行时间。集成步骤简单：添加依赖、修改数据源配置、创建spy.properties文件即可使用，支持自定义日志格式。特别适合开发测试环境调试MyBatis/Hibernate等ORM框架的SQL执行，但生产环境需谨慎使用以避免性能损耗。该工具是Java开发者排查数据库问题的利器，能有效替代传统打印日志的调试方式。
2025-08-26 01:20:09
928
原创 使用 HandlerMethodReturnValueHandler 在SpringBoot项目 实现 RESTful API 返回值自动封装，简化开发
Spring MVC 提供了接口，允许我们在控制器方法执行后、响应写出前，对返回值进行拦截和处理。我们可以利用它来自动包装返回结果。
2025-08-25 22:21:55
644
原创 阿里云 OSS 前端直传实战：表单上传 + Policy 模式详解
在现代 Web 应用中，用户上传图片、视频等文件已成为标配功能。如果所有文件都经过后端中转，不仅增加服务器带宽压力，还可能导致性能瓶颈。阿里云 OSS（Object Storage Service）提供了强大的对象存储能力，支持，真正做到“上传不走后端”。本文将带你深入实践使用实现前端直传，并对比STS Token模式，分析其优劣。同时，我们将展示如何通过 Nacos 动态配置管理 OSS 参数。
2025-08-24 23:58:47
1133
原创 前端直传OSS真不安全？一篇讲透阿里云OSS直传
摘要： 阿里云OSS前端直传方案相比传统后端中转上传，在性能、成本、扩展性方面优势显著。通过PostPolicy签名或STS临时凭证，可实现安全上传，避免AK/SK泄露风险。Policy策略严格限制上传路径、大小等条件，配合上传回调机制，确保业务可控。高阶玩法如生命周期规则可自动清理未完成文件，结合日志记录提升安全性。前端直传OSS已成为行业标配，尤其适合高并发、大文件场景，开发者需掌握其安全机制以充分发挥优势。技术演进中，拒绝进步才是最大风险。
2025-08-24 15:45:36
1341
原创 Spring 面试指南：深入理解 AOP（面向切面编程）
Spring AOP（面向切面编程）通过将横切关注点（如日志、权限、事务）模块化，解决了传统编程中代码重复和耦合度高的问题。典型应用场景包括自动记录操作日志：通过自定义注解标记方法，利用环绕通知在方法执行前后自动记录参数、耗时、异常等信息，并异步保存。这种方式使业务代码保持简洁，实现了非侵入式的功能增强。AOP的核心价值在于分离系统功能与业务逻辑，提升代码可维护性和扩展性。
2025-08-22 16:28:23
1191
1
原创 Spring面试宝典：Spring IOC的执行流程解析
Spring IOC的工作流程解析：从配置到依赖注入，Spring容器通过控制反转机制自动管理对象的创建和依赖关系。核心流程包括解析配置生成BeanDefinition、注册到容器、反射实例化单例Bean、完成依赖注入等步骤，最终通过@Autowired或getBean()获取实例。这种设计降低了代码耦合度，提高了可维护性和扩展性，让开发者更专注于业务逻辑的实现。面试时可简明阐述这三个阶段，强调IOC带来的解耦优势。
2025-08-21 22:05:50
1241
原创 MySQL面试题：联合索引是什么？最左前缀原则你真的懂吗？
MySQL联合索引是面试高频考点，其本质是在多个列上创建的B+树索引，按字段顺序排序存储。核心是最左前缀原则：查询必须包含索引最左连续列才能生效。例如索引(name,age,position)，仅查询name或name+age能走索引，而单独查age或position则无效。联合索引优势在于提升多条件查询性能、支持覆盖索引，但存在写入开销大、列序敏感等缺点。实际业务中，可通过ETL预计算配合联合索引实现高效查询，如按日期-公司-员工ID创建主键索引来优化报表查询性能，体现"空间换时间"的
2025-08-19 00:29:29
809
原创 MySQL面试题：MyISAM vs InnoDB？聚簇索引是什么？主键为何要趋势递增？
MySQL面试重点：存储引擎与索引设计 摘要：MyISAM与InnoDB的核心区别在于事务支持、锁粒度和索引结构。InnoDB采用聚簇索引，数据与主键索引一体存储，查询效率更高；而MyISAM使用非聚簇索引，需回表查询。主键设计推荐趋势递增的ID（如雪花算法），避免UUID导致的性能问题。在分库分表场景下，雪花ID能保证全局唯一且易于路由。哈希索引虽查询快但不支持范围操作，适合特殊场景。InnoDB凭借事务支持、行级锁和聚簇索引优势，成为现代应用的首选存储引擎。
2025-08-18 21:26:30
775
原创 MySQL面试高频题：遇到慢SQL，你第一反应是什么？
文章摘要：慢SQL处理是开发和面试中的常见问题。核心解决思路包括：1)使用EXPLAIN分析执行计划，检查索引使用情况；2)排查索引缺失或失效；3)评估引入Redis缓存热点数据；4)优化SQL写法，避免SELECT*、深分页等问题；5)必要时考虑分库分表架构升级。系统性的排查应涵盖执行计划分析、索引优化、缓存引入、SQL改写和架构调整等多个维度，而非简单"加索引"。（149字）
2025-08-18 20:27:18
374
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人