Database

CAP理论，指的是在一个分布式系统中， 
Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：
• 一致性（Consistency）
• 可用性（Availability）
• 分区容错性（Partition tolerance）
最多满足其中的两个特性。也就是下图所描述的。
分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。


* redo log是物理日志，记录内容是“在某个数据页上做了什么修改”，
  属于InnoDB存储引擎层，在事务过程中是不断写入的。
* bin log 是逻辑日志，记录内容是语句的原始逻辑，
  属于Server层，只在事务提交时才写入。
  
为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交方案。
两阶段提交：将redo log的写入操作拆成了两个步骤prepare和commit进行，
在事务执行期间，写入的redo log标记为prepare阶段，
待事务提交且bin log写入成功时，才将redo log标记为commit阶段。


Redolog vs Undolog 核心区别对比
1.目标不同 
  redo log：保证持久性，宕机恢复已提交事务； 
  undo log：保证原子性，事务回滚，支撑 MVCC 快照读。
2.记录内容不同 
  redo：物理修改，数据页变更； 
  undo：逻辑逆操作，修改前旧数据。
3.执行时机不同 
  redo：修改内存后写入，事务提交刷盘； 
  undo：修改数据之前先生成写入。
4.宕机恢复逻辑不同 宕机重启：
  * 有已提交事务但脏页未落盘 → 用 redo 重做恢复；
  * 有未提交事务 → 依靠 undo 回滚撤销操作。


不可重复读”与“幻读”是两个数据库常见的极易混淆的问题。
不可重复读指的是: 
    在一个事务开启过程中，当前事务读取到了另一事务提交的修改。
幻读则指的是: 
    在一个事务开启过程中，读取到另一个事务提交导致的数据条目的新增或删除。
    
MVCC对只有那些提交时间戳小于等于查询开始时刻系统版本号、
并且未被后续更新删除或覆盖过得记录才对该查询可见。    


binlog日志有三种格式：statement、row和mixed
* statement级别：优点是binlog文件小，缺点是主库的慢sql也会在从库上再出现一次，
  一些依赖环境或上下文的函数可能会产生不一致的数据
* row级别：缺点是文件大（一条语句如果涉及多行，会放大n倍），优点是无上述慢sql问题，不依赖环境或上下文
为了获取前后变化数据，canal建议使用row级别

主从同步流程（半同步）
* 从库在连接主库时，表明自己支持半同步复制
* 主库也需支持半同步复制，主库commit事务前会阻塞等待至少一个从库写入relay log的ack，直至超时
* 如果阻塞等待超时，则主库临时切换回异步同步模式，
  当至少一个从库的半同步追上进度时，主库再切换至半同步模式
  
* 普通场景：线上从库异步同步，高可用备份半同步
* 对一致性要求较高的大数据取数需求
  大数据取数可能导致从库cpu使用率飙升、ack变慢，可设置半同步所需ack数量为1，正常情况下高可用备份能很快ack，于是主库会commit并返回，
  而大数据取数复制慢一些也无所谓。这样就不会因为大数据取数ack慢而影响主库和业务了。

MySQL 分区支持把不同分区放到不同磁盘
分区类型：RANGE（按区间）、LIST（按枚举）、HASH（按哈希均匀分布）、KEY（按数据库哈希）。
* 以 InnoDB + RANGE 分区为例：
CREATE TABLE logs (
    id INT NOT NULL,
    ts DATETIME NOT NULL,
    content TEXT,
    PRIMARY KEY (id, ts)
) ENGINE=InnoDB
PARTITION BY RANGE (YEAR(ts)) (
    PARTITION p2024 VALUES LESS THAN (2025) DATA DIRECTORY = '/disk1/mysql_data',
    PARTITION p2025 VALUES LESS THAN (2026) DATA DIRECTORY = '/disk2/mysql_data',
    PARTITION p2026 VALUES LESS THAN MAXVALUE DATA DIRECTORY = '/disk1/mysql_data'
);

* Hash分区
CREATE TABLE goods(
    id INT,
    stock INT
) ENGINE=InnoDB
PARTITION BY HASH(id)
PARTITIONS 8; -- 分成8个分区

清理历史月份数据只需执行
ALTER TABLE orders DROP PARTITION p2024，
秒级完成，不会产生大量binlog引发主从延迟 。

分区分表

维度	数据库分区 (Partitioning)	水平分表/分库 (Sharding)
架构复杂度	低。对应用透明，无需改代码。	高。需引入中间件，改造 SQL，处理分布式 ID。
数据规模	千万级 ~ 亿级 (受限于单机性能)。	十亿级 ~ 百亿级 (可无限横向扩展)。
查询性能	依赖分区裁剪，若未命中分区键则全表扫描。	路由精准，单表数据少，索引效率高。
运维难度	简单。原生支持备份、迁移。	复杂。扩容需数据迁移 (Resharding)，需监控各节点均衡。
典型场景	日志系统、流水记录、冷热数据明显的业务。	核心交易链路 (订单、支付)、高并发用户中心。
事务支持	支持本地 ACID 事务。	跨库事务需借助 TCC、Seata 等分布式事务方案，成本高。

决策建议

先优化，再拆分 ：
在考虑分表前，先检查是否可以通过 索引优化 、 SQL 改写 、 读写分离 或 垂直分表 （将大字段拆分）解决问题。
很多系统在 2000 万数据量下，通过良好的索引设计依然能跑得飞快。

小步快跑 ：
Step 1 : 单表 + 索引优化。
Step 2 : 读写分离 + 缓存 (Redis)。
Step 3 : 如果主要是历史数据查询慢，使用  分区表  进行冷热分离。
Step 4 : 如果单机 IO/CPU 瓶颈或写入并发过高，再启动  分库分表 。

不要为了分表而分表 ：
分表是“银弹”的反面——它引入了分布式系统的几乎所有难题（一致性、可用性、分区容错性）。
只有当业务规模真正触达单机物理极限时，才值得付出这个代价。

如果你现在的业务正处于“犹豫要不要分表”的阶段，建议先评估： 
你的慢查询是因为数据量大导致索引失效，还是因为并发太高导致锁竞争？  
前者可能只需优化索引或归档，后者才更需要分库分表。  


1. 优先选分区表的场景
核心特征：90%的查询都带订单时间条件，需要按月做数据归档清理，团队没有分布式数据库运维经验。

2. 必须选分表的场景
核心特征：单表数据量突破5000万行，大促期间峰值写入QPS超过2000，需要跨多台物理机分散写入压力。
方案收益：
* 按用户ID哈希拆分成16张子表，单表数据量降到200万行以内，单表查询性能回到毫秒级 。
* 写入请求分散到多个独立表，彻底突破单实例CPU、磁盘IO的硬件瓶颈，支持线性扩展 。
* 可配合分库策略，将不同分表部署到不同物理节点，实现异地多活容灾。
 
3. 混合架构最优实践
核心特征：对于年订单量破亿的超大规模电商系统，推荐采用「分区+分表」的组合方案：
方案收益：
* 先按业务维度分库，将订单库独立部署，和用户库、商品库物理隔离。
* 按用户ID哈希拆分成4张子表，分散高并发写入压力
* 子表按订单时间做RANGE分区，按月拆分冷热数据。

既保留了分区表对历史数据的便捷管理能力，又通过分表突破了单机性能上限，是互联网级业务的主流选型思路。

别再问我向量数据库是啥了，看完这篇你就全明白了

向量数据库：原理、索引技术与选型指南

向量数据库是一种专门用于存储、管理和查询高维向量数据的数据库系统。它是大语言模型（LLM）、生成式AI以及语义搜索的核心基础设施。
以下是关于向量数据库的全面解析：
1. 什么是向量？为什么需要专门的数据库？
 • 向量的本质：在AI领域，向量（Vector/Embedding）是一串长长的数字列表（通常有几百到上千个维度），用于表示文本、图像、音频等非结构化数据的“特征”或“语义”。
 • 传统数据库的局限：传统关系型数据库（如MySQL）擅长处理精确匹配的结构化数据（如数字、日期），但在面对复杂的语义理解、模糊匹配或多模态数据（如判断两张不同风格的猫的图片是否相似）时无能为力。

2. 核心工作原理
向量数据库的核心功能是高效的相似性搜索。
向量化：通过嵌入模型（Embedding Model）将文字、图片等转化为向量。
 1. 存储与索引：将向量及其对应的元数据（如原始文本、标签、ID）存入数据库。为了实现快速查找，数据库会使用特定的算法（如 HNSW、IVF）对向量进行“分组”或“建图”，这被称为近似最近邻（ANN）搜索。
 2. 检索：当用户输入查询时，系统会将其转化为向量，并在数据库中计算与已有向量的“距离”（如余弦相似度），找出最匹配的结果。

3. 核心应用场景
 • RAG（检索增强生成）：通过向量数据库检索企业内部私有文档，提供给大模型作为上下文，从而有效解决大模型“幻觉”和知识过时的问题。
 • 语义搜索引擎：不再依赖关键词匹配，而是理解用户的查询意图（例如搜索“开心”，也能检索出包含“快乐”、“高兴”的内容）。
 • 个性化推荐系统：分析用户的历史行为向量，快速匹配出用户可能感兴趣的商品、视频或新闻。
 • 多模态检索：通过文字搜索图片，或通过图片搜索相似图片。 

4. 主流向量数据库盘点
根据不同的技术架构和业务需求，当前市场上有多种开源及商业托管方案可供选择：
Milvus：云原生、高扩展性的分布式开源数据库，非常适合百亿级海量向量的处理。
 • Qdrant：基于 Rust 编写，性能极高，非常适合高并发、低延迟的生产环境。
 • Weaviate：开源的原生向量搜索引擎，支持将向量与结构化数据进行强大的混合搜索。
 • Pinecone：流行的全托管云服务，开箱即用，适合中小型项目快速验证。
 • Chroma：轻量级的开源工具，专门为开发者在本地或小型项目中集成 LLM 应用而设计。

---------------
向量数据库的核心是通过高维向量进行语义相似度匹配。为了在数十亿数据中实现毫秒级查询，底层依赖各种近似最近邻（ANN）算法进行索引和降维聚类。以下是常见技术的核心解析：

HNSW (Hierarchical Navigable Small World)
 o 原理：构建层状的“跳表”图结构，越上层节点越稀疏，越底层越密集。查询时从上层粗略搜索，逐层深入至底层。
 o 特点：当前业界查询质量和召回率的天花板。内存占用极高，但查询速度极快。

IVF (Inverted File Index)
 o 原理：借鉴传统数据库思想，使用K-Means将向量空间划分为多个“Voronoi单元”（聚类中心）。查询时仅比对距离最近的几个簇，避免全库扫描。
 o 特点：查询速度快，支持动态增删改，可通过调整探查簇数量平衡速度与召回率。

PQ (Product Quantization)
 o 原理：将高维向量拆分成多个子向量，对每个子向量进行聚类并用中心点量化编码。通过压缩向量位数来大幅缩减内存占用。
 o 特点：极大地压缩了内存，常与IVF结合使用（IVFPQ），但计算过程中存在信息损失。

Annoy (Approximate Nearest Neighbors Oh Yeah)
 o 原理：基于随机超平面将空间反复二分，构建多棵二叉树森林。搜索时只在几何位置相近的树叶中进行局部匹配。
 o 特点：Spotify开源的算法，内存占用低，单机构建极其方便，但召回率略逊于HNSW。

LSH (Locality-Sensitive Hashing)
 o 原理：通过哈希函数将相似的高维向量映射到同一个桶（Bucket）中，查询时只需在特定的哈希桶内比对。
 o 特点：检索速度极快，更适用于传统的布尔查找或海量数据的初步过滤。

RP (Random Projection)
 o 原理：通过高维向低维的随机映射投影（如Johnson-Lindenstrauss引理），在基本保持向量间相对距离不变的情况下，压缩向量维度。
 o 特点：常作为预处理步骤，用于降低后续其他索引的计算复杂度。

DBSCAN (Density-Based Spatial Clustering of Applications with Noise)
 o 说明：这是一种基于密度的聚类算法，不属于近邻检索索引。它根据数据点在空间中的密集程度自动划分聚类簇，并能有效识别异常点。在向量处理中，常用于数据去重或无监督分类，而非向量检索。

结合使用
在实际应用中，通常会将多种技术结合起来使用以实现最佳性能。
例如，可以先使用DBSCAN进行初步聚类，然后对每个簇使用Annoy或HNSW进行高效搜索。或者使用IVF结合PQ来减少存储需求并加速查询速度。
每种技术都有其特定的应用场景和优势，选择合适的组合取决于具体的数据特性、查询需求以及性能要求。

总结
选择合适的向量数据库技术组合取决于你的具体需求，包括数据规模、查询类型、实时性要求以及存储效率等。
通过结合使用这些技术，你可以构建出既快速又高效处理大规模向量数据的系统