为什么要垂直分表

问题 在以前，一张核心表的字段可能有上百个字段，这种肯定是有问题的，至于什么问题，后面分析 什么是垂直分表垂直分表则是将一张大表按“列”拆分为两张以上的小标，通过主外键关联来获取数据。 举例这是一张商品表拆分前与拆分后 拆分后的SQL变换 拆表原因先来看我们的InnoDB的存储结构 我们每一页(Page)默认的大小为16K，保存我们 页的叫做区(Extent)(1M)，我们一个区能够存储64

HashMap

Put方法流程 JDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。 JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于等于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为

分库分表

时机 前提，项目业务数据越来越多，或者业务发展比较迅速(单表的数据量达1000W或10G以后) 优化已经解决不了性能问题(主从读写分离、查询索引…) IO瓶颈(磁盘IO、网络IO)、CPU瓶颈(聚合查询、连接数太多) 拆分策略 垂直 垂直分库 垂直分表 水平 水平分库 水平分表 垂直分库以表为依据，根据业务将不同表拆分到不同库中 特点： 按业务对数据分级管理、维护、监控、扩

线程池

核心参数 执行流程 有哪些常见队列 场景一 场景二 场景三 这个@Async注解的使用在实习的时候坤哥代码也有用到过，相对来说用起来更加优雅 总结 如何控制某个方法允许并发访问线程数量Semaphore [ ‘scme ,for]信号量，是JUC包下的一个工具类，底层是AQS，我们可以通过其限制执行的线程数量使用场景: 通常用于那些资源有明确访问数量限制的场景，常用于限流。 在多线程中提

ReentrantReadWriteLock

读写锁定义读写锁定义为：一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程(读写互斥、读读共享) 锁演化过程 它只允许读读共存，而读写和写写依然是互斥的，大多实际场景是“读/读”线程间并不存在互斥关系，只有”读/写”线程或”写/写”线程间的操作需要互斥的。因此引入ReentrantReadWriteLock。 总结一个ReentrantRea