lfeishumomol的博客

索引是提高数据库查询效率的数据结构。常见索引底层结构包括二叉树、红黑树、B树和B+树。二叉树在递增数据下会退化为链表，效率降至O(n)。红黑树虽避免退化，但树高仍较大。B树通过多叉结构减少树高，但节点同时存储数据和索引。B+树是优化版本，仅非叶节点存索引，叶节点存数据并双向链接，既降低树高又提升范围查询效率，是数据库索引的主流选择。

摘要： 阿里云OSS前端直传方案相比传统后端中转上传，在性能、成本、扩展性方面优势显著。通过PostPolicy签名或STS临时凭证，可实现安全上传，避免AK/SK泄露风险。Policy策略严格限制上传路径、大小等条件，配合上传回调机制，确保业务可控。高阶玩法如生命周期规则可自动清理未完成文件，结合日志记录提升安全性。前端直传OSS已成为行业标配，尤其适合高并发、大文件场景，开发者需掌握其安全机制以充分发挥优势。技术演进中，拒绝进步才是最大风险。

Spring AOP（面向切面编程）通过将横切关注点（如日志、权限、事务）模块化，解决了传统编程中代码重复和耦合度高的问题。典型应用场景包括自动记录操作日志：通过自定义注解标记方法，利用环绕通知在方法执行前后自动记录参数、耗时、异常等信息，并异步保存。这种方式使业务代码保持简洁，实现了非侵入式的功能增强。AOP的核心价值在于分离系统功能与业务逻辑，提升代码可维护性和扩展性。

Spring IOC的工作流程解析：从配置到依赖注入，Spring容器通过控制反转机制自动管理对象的创建和依赖关系。核心流程包括解析配置生成BeanDefinition、注册到容器、反射实例化单例Bean、完成依赖注入等步骤，最终通过@Autowired或getBean()获取实例。这种设计降低了代码耦合度，提高了可维护性和扩展性，让开发者更专注于业务逻辑的实现。面试时可简明阐述这三个阶段，强调IOC带来的解耦优势。

MySQL联合索引是面试高频考点，其本质是在多个列上创建的B+树索引，按字段顺序排序存储。核心是最左前缀原则：查询必须包含索引最左连续列才能生效。例如索引(name,age,position)，仅查询name或name+age能走索引，而单独查age或position则无效。联合索引优势在于提升多条件查询性能、支持覆盖索引，但存在写入开销大、列序敏感等缺点。实际业务中，可通过ETL预计算配合联合索引实现高效查询，如按日期-公司-员工ID创建主键索引来优化报表查询性能，体现"空间换时间"的

MySQL面试重点：存储引擎与索引设计 摘要：MyISAM与InnoDB的核心区别在于事务支持、锁粒度和索引结构。InnoDB采用聚簇索引，数据与主键索引一体存储，查询效率更高；而MyISAM使用非聚簇索引，需回表查询。主键设计推荐趋势递增的ID（如雪花算法），避免UUID导致的性能问题。在分库分表场景下，雪花ID能保证全局唯一且易于路由。哈希索引虽查询快但不支持范围操作，适合特殊场景。InnoDB凭借事务支持、行级锁和聚簇索引优势，成为现代应用的首选存储引擎。

本文深入解析了Java中Thread、ThreadLocal和ThreadLocalMap的关系及实现原理。ThreadLocal通过ThreadLocalMap为每个线程存储本地变量，采用弱引用避免内存泄漏。主要应用场景包括用户上下文传递、数据库事务管理、日志追踪ID等。使用时需注意在finally块或AOP中调用remove()清理资源，特别是在线程池环境下，防止内存泄漏和数据污染。推荐结合try-finally或Spring AOP实现自动清理机制，确保线程安全。

本文探讨了数据库删除操作的两种方式：逻辑删除和物理删除。逻辑删除通过标记数据为"已删除"状态保留数据，适用于需保留历史、关联性强或审计要求的场景；物理删除则彻底移除数据，适用于临时数据清理。重点介绍了MyBatis-Plus中实现逻辑删除的正确方法：使用@TableLogic注解配置删除标记字段，并推荐进行全局配置。文章强调删除前必须校验参数合法性、数据存在性，并根据业务场景选择合适的删除方式，核心原则是"能不删就不删，能逻辑删就不物理删"。

锁升级是指 JVM 在运行时根据对象的使用情况，对对象的锁状态进行动态优化的过程。它不是“升级为更重的锁”，而是从轻量级锁逐步升级到重量级锁的过程，以在不同竞争程度下取得性能平衡。步骤锁类型触发条件1无锁状态初始状态2偏向锁第一次加锁（单线程）3轻量级锁多线程交替访问（CAS）4重量级锁线程竞争激烈（锁膨胀）

文章摘要：慢SQL处理是开发和面试中的常见问题。核心解决思路包括：1)使用EXPLAIN分析执行计划，检查索引使用情况；2)排查索引缺失或失效；3)评估引入Redis缓存热点数据；4)优化SQL写法，避免SELECT*、深分页等问题；5)必要时考虑分库分表架构升级。系统性的排查应涵盖执行计划分析、索引优化、缓存引入、SQL改写和架构调整等多个维度，而非简单"加索引"。（149字）

本文对比分析了数据库索引中常用的数据结构。二叉树在小规模数据中表现良好，但存在退化风险；红黑树通过自平衡特性解决了退化问题，但树高仍较大。B树通过多路搜索降低了树高，但数据存储效率不高。B+树在此基础上进一步优化，将数据集中存储在叶子节点，非叶子节点仅存索引，显著提高了范围查询效率和磁盘利用率。这些特性使B+树成为数据库索引的首选结构，能够有效降低树高、减少I/O操作，特别适合处理大规模数据。

本文探讨数据库分库分表的时机与B+树索引结构特性。当单表数据量预计三年内超500万条或2GB时，建议实施分库分表策略，以解决查询性能下降、备份困难等问题。文章详细分析了B+树三层结构下的存储容量计算，指出理论上单表可存储约4亿条记录，但实际需考虑页分裂、索引开销等因素。最终强调应结合业务需求，在数据量接近500万条时提前规划分库分表，确保系统高效运行和维护便利。

一致性 (Consistency)：所有节点必须同时返回相同的数据。可用性 (Availability)：非故障节点在合理时间内返回合理的响应。分区容错性 (Partition Tolerance)：即使网络分区发生，系统仍然能够正常工作。构建高可用系统架构是一项复杂的任务，涉及读写分离、CAP 定理的应用以及数据分片等多种技术手段。通过合理的架构设计和工具选型，可以在保障系统稳定性的同时，提升性能和可扩展性。