MySQL-MVCC MySQL通过ReadView和undo log实现了MVCC ReadView 创建该ReadView的事务id（creator_trx_id） 创建该ReadView时，当前活跃且未提交事务id列表（m_ids） 创建该ReadView时，最小活跃未提交事务id（min_trx_id） 创建该ReadView时，下一个事务id（max_trx_id） 记录的隐

MySQL深分页问题1. 什么是深分页问题深分页的性能瓶颈源于MySQL处理LIMIT的机制。当执行： 1SELECT * FROM tabLe LIMIT 1000000, 20 MySQL需要先定位到第1000000条记录，然后再取出接下来的20条记录。这个过程需要跳过前面的100万条记录，即使有索引，这种跳跃操作的成本也是非常高的。随着偏移量的增加，查询时间会线性增长，这就是深分页问题的根

MySQL索引优化手段假设有一张表 user，三个字段 id (主键索引) 、 age(非唯一索引)、name(联合索引idx_name_age)、gender、empid（联合索引idx_gender_empid）。 表中现有数据： id: 10, age: 10_v1, name: aaa，gender: M，empid: 10 id: 11, age: 10_v2, name: bbb，g

LongAdder相比AtomicLong的优势LongAdder相比AtomicLong最核心的优势在于大幅降低了高并发场景下的CAS竞争开销。当多个线程频繁对AtomicLong进行递增操作时，所有线程都会竞争同一个内存位置，导致大量CAS失败重试，性能急剧下降。这就像几十个人同时去抢一把锁，成功率极低，大家都在空转浪费CPU。 LongAdder采用分段累加策略巧妙地解决了这个问题。它的核心

为什么HashMap的键值可以为null，而ConcurrentHashMap不行？根本原因：二义性问题，无法判断get(key)返回的Null值到底是因为不存在这个key，还是因为这个key对应的value就是Null 1. HashMapHashMap允许一个Null key和多个Null value，为什么HashMap没有二义性问题？ 因为HashMap是为单线程设计的，在单线程的情况下，

多线程手撕1. 单例模式123456789101112131415161718class Singleton{ public static volatile Singleton singleton; private Singleton(){ } public static Singleton getInstance(){ if(

知识获取与分享平台 知识社区App，支持发布知识、点赞/收藏、关注取关、首页Feed展示、AI生成摘要等等。项目各模块进行了充分详细的设计以满足高并发和高可用需求 一、认证系统 开发JWT双令牌认证系统，采用RS256签名 + Redis刷新令牌白名单，实现15分钟访问令牌 + 7天刷新令牌的安全会话管理，支持即时令牌撤销，兼顾高安全和高性能。 1.1 有状态身份验证和无状态身份验证

Redis为什么这么快？原因 Redis基于内存的数据存储，内存的读写速度远高于硬盘 Redis提供了高效的数据结构 Redis使用了单线程模型处理命令执行，避免了多线程上下文切换开销、以及资源同步开销 Redis采用了高效的IO多路复用模型 Redis 客户端和服务端之间使用 RESP (Redis Serialization Protocol) 协议通信 为什么要用单线程？多线程难道不会更快

MVCC导致索引覆盖失效场景MVCC（多版本并发控制）确实会导致索引覆盖失效，从而触发回表。 很多开发者认为只要 SQL 的字段都在联合索引里，就一定能走“索引覆盖（Using index）”，但在高并发写场景下，这并不绝对。 其根本原因在于 MySQL InnoDB 存储引擎的二级索引（Secondary Index）结构设计。 核心原因：二级索引“不完整”在 InnoDB 中，MVCC 的实

MySQL日志1. undo log1.1 undo log的实现在事务提交之前，每当InnoDB引擎对一条记录进行增、删、改操作时，要把操作之前的信息记录到undo log中。如果事务还没提交就发生了崩溃，那么就可以通过undo log回滚到之前的数据。 一条记录的每一次更新操作产生的undo log格式都有一个roll pointer指针和trx_id事务id： 通过trx_id可以知道是那