一、什么是TiDB
TiDB（读作“Ti-D-B”，Ti 代表 Titanium）是一款由 PingCAP 公司研发的开源分布式关系型数据库，因其在架构和理念上的领先性，被认为是全球最具影响力的分布式数据库之一。
简单来说，TiDB的核心价值在于它兼容 MySQL，但同时解决了传统单机数据库在数据量巨大时面临的性能瓶颈、扩展困难和运维复杂等问题。
🧭 核心架构："存储与计算分离"
TiDB的架构是其强大能力的核心，通过"存储与计算分离"的设计，多个组件各司其职，协同工作。
TiDB Server（计算层）：无状态的SQL处理层，负责处理客户端连接、解析SQL并生成分布式执行计划。可以根据负载轻松地水平扩展。
Placement Driver (PD) 集群（调度与元数据管理层）：整个集群的"大脑"，负责存储系统元数据、调度数据分布、分配全局唯一的时间戳（TSO）。
TiKV（行存储引擎）：分布式键值存储引擎，负责存储具体数据。数据被自动切分为Region（默认约96MB~144MB/个），并使用Raft 共识算法在多个节点间复制（默认3副本），确保数据强一致性和高可用。
TiFlash（列存储引擎）：列式存储引擎，与TiKV保持数据强一致，专门用于加速在线分析查询，实现真正的HTAP能力。TiDB优化器会根据SQL特性，智能选择从TiKV或TiFlash读取数据。
此外，TiDB团队在2025年发布了全新的TiDB X架构，它进一步解耦计算与存储，将对象存储作为核心，实现真正按使用量计费和极致的弹性伸缩。
✨ 核心特性：为海量数据而生
TiDB的这些特性让它能更好地应对复杂的数据挑战。
水平弹性扩展：通过增加 TiDB Server 或 TiKV 节点，可以在线、无感地提升集群的计算或存储能力。TiDB X 更进一步，实现秒级弹性伸缩。
金融级高可用：通过 Raft 协议，数据在多个节点间维护多副本。即使少数节点宕机，系统也能自动切换，确保99.999%的高可用性和数据一致性。
实时 HTAP：通过 TiKV（行存）和 TiFlash（列存）双引擎，一套系统可同时处理交易和分析，避免传统ETL带来的延迟。
MySQL 高度兼容：兼容 MySQL 5.7 和 8.0 的协议，应用可像访问 MySQL 一样无缝接入，现有 MySQL 生态工具（如Navicat、DBeaver）基本也都兼容。
Cloud Native 化：云原生设计使其天然适应多云/混合云环境，可通过 TiDB Operator 在 Kubernetes 上自动化部署和运维。
助力 AI 应用：自 7.0 版本开始，TiDB 集成向量搜索功能，可作为 AI 应用的内存数据库，支撑检索增强生成等场景。
💼 应用场景：谁在使用TiDB？
TiDB被广泛应用于海量数据、高并发、高可用性等要求苛刻的场景，典型案例如下：
金融行业
微众银行：使用超80个集群，服务超3亿用户，最大集群数据量超200TB，峰值23.7万QPS，实现核心系统全面分布式改造。
中泰证券：用一套 TiDB 集群替换多套 MySQL 主备架构，已承载70-80个核心系统。
杭州银行：采用云原生部署，构建新一代核心系统。
互联网与科技
美柚：支撑千万级日活用户核心系统，实现降本增效。
盛天网络：核心系统升级后，查询耗时提升10倍。
其他行业
蔚来汽车：处理单表超20亿条的车联网和业务数据，解决 MySQL 性能瓶颈。
吉奥时空：报表查询速度比原有系统快3倍，系统高可用达99.9%。
此外，TiDB 还广泛应用于政务、制造、物流、游戏及三甲医院等关键行业的业务系统升级中。
📌 特别关注：TiDB vs MySQL
TiDB 看似 MySQL，但在应对大规模数据和运维上存在本质差异。
核心差异
设计定位：TiDB 是为大规模、分布式环境设计的；而 MySQL 是单机的。
扩展性：TiDB 支持自动水平扩展；而 MySQL 需要手动进行分库分表。
高可用：TiDB 基于Raft 协议，提供自动故障转移；而 MySQL 通常需要手动配置主从切换。
HTAP：TiDB 通过 TiFlash 引擎原生支持；而 MySQL 需要依赖外部工具，存在时效性延迟。
存储引擎：TiDB 使用 TiKV 和 TiFlash；而 MySQL 使用InnoDB。
License：TiDB 采用Apache 2.0协议；而 MySQL 社区版使用GPLv2。
如何选择
如果您的业务刚刚起步，MySQL 是简单、成熟的选择。而当您遇到 MySQL 的瓶颈（如单表超过1TB或遇到性能、运维难题），TiDB 的优势便会凸显。
需要注意的是，TiDB 并非 MySQL 的直接替代品，它在语法和功能上有约80%的高度兼容，但仍存在约20%的不兼容点。为避免应用报错，迁移前务必将TiDB不兼容的MySQL功能（如存储过程、触发器、自定义函数、全文索引、空间数据类型等）进行改造，具体不兼容清单可参考 官方文档。
⚠️ 一个关键陷阱：主键设计不当导致性能暴跌
很多开发者会将MySQL的单机主键设计模式（如雪花ID）直接套用在TiDB上，这会导致严重的性能问题。
错误示例：使用
BIGINT的雪花算法ID做主键。由于这种ID是随机的，TiDB 写入时会在所有存储节点之间频繁分裂和迁移 Region，导致写入性能可能比 MySQL 慢几十倍。正确实践：应使用AUTO_INCREMENT的自增主键。这样数据能在一个 Region 内顺序写入，避免跨节点的随机IO，最大化性能。迁移时务必检查所有主键（特别是业务主键）的设计。
从技术上说，TiDB 的诞生受到 Google Spanner 和 F1 论文的启发，第一代 GA 版本是v1.0（2017年10月发布），最新版本是 v8.5.5，具有里程碑意义的新架构版本TiDB X则在 2025 年发布。总结来看，TiDB 通过巧妙的分层架构、高度兼容 MySQL 的生态和强大的扩展能力，为企业全面拥抱数字化和智能化提供了一个坚实、可靠的现代数据库解决方案。
什么是raft算法？
Raft 协议是一种旨在解决分布式系统中数据一致性的共识算法。它的核心目标是通过一种易于理解的方式，让多个服务器在面临节点故障和网络中断时，依然能像一个整体一样可靠地运作。
简单来说就是在分布式系统中保证安全和高可用性。
raft的三个机制：
领导者选举 (Leader Election)：在集群中选出一个“负责人”来做出所有决策，避免了多个节点争吵不休的局面。Raft 通过一种基于随机超时时间的机制来快速决定由谁当选，确保了集群的稳定。
这个领导者选举很有意思，我给大家简单讲解一下：
如果当领导者宕机的时候，跟随者们会根据这个随机超时时间最短的 假设B服务器 这个过程是被动的，B的超时时间到期了 此时没有收到领导者发来的心跳，证明宕机 此时B会通知其他跟随者 来进行投票选举，其他跟随者会根据他的日志与自己的日志比较 如果B的日志比较新 也就是数据比较全 那么 该跟随者会投票给B 最后获得半数以上票权的B会成为新的领导者。
如果投票在半数一下，那么他不会成为领导者，等待其他服务器超时时间结束 再发起投票 依次类推选出领导者。
日志复制 (Log Replication)：领导者负责接收所有来自客户端的操作请求，并将其记录在日志中。它会将这些日志条目发给集群中的所有其他节点，通过一套校验机制确保它们完全一致。
安全性 (Safety)：这是贯穿选举和日志复制过程的“铁律”，用来应对各种异常情况并保证数据安全与系统稳定。例如，它通过限制投票规则，确保只有包含所有已提交日志的节点才能成为领导者，有效防止了数据丢失。
如果阅读起来还是有困惑的话：官方给出了动画演示地址 如下视觉化网站:官方动态演示(thesecretlivesofdata.com/raft) 和可视化演示(www.kailing.pub/raft)[reference:38][reference:39][reference:40]reference:38[reference:40])
新的问题：该集群保证了可用性和安全性，但是日志一直在增加 造成的日志无限增长和快照开销如何解决？
答：定期为状态机拍照 删除当前快照之前的所有日志 快照作为日志的压缩，减少磁盘空间的占用。通过控制快照的拍照时间和频率来减少快照的开销。
在本地免费测试是可行的，TiDB 也支持存储和搜索向量数据。
你可以使用官方工具TiUP，在本地 macOS 或 Linux 环境免费部署一套 TiDB 测试集群。同时，TiDB 本身也内置了向量搜索功能，可以将向量数据作为一列存储在你的表中。
💻 如何在本地免费测试 TiDB？
TiDB 官方提供的TiUP包管理器包含一个playground组件，它能帮你在单机上快速模拟出一套完整的 TiDB 集群，专门用于开发和测试。
以下是基于TiUP快速搭建并体验 TiDBv8.5.2（推荐）的步骤：
1. 安装 TiUP在你的终端中执行以下命令进行安装，之后可能需要根据提示重启终端或执行source命令使配置生效：
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
2. 启动本地测试集群执行以下命令来启动一个最小化的 TiDB 测试集群。该集群将包含 1 个 TiDB、1 个 TiKV、1 个 PD 和 1 个 TiFlash（用于支持向量搜索）实例。
tiup playground
这时，你会在终端看到类似这样的输出，表示集群已成功启动，并提供了访问信息。
CLUSTER START SUCCESSFULLY, Enjoy it ^-^ Connect TiDB: mysql --host 127.0.0.1 --port 4000 -u root -p --no-password
3. 访问 TiDB 数据库保持运行tiup playground的终端不要关闭。打开一个新的终端窗口，使用tiup client命令连接数据库。
tiup client
连接成功后，你就可以输入 SQL 语句进行尝试了，例如在mysql提示符下执行：
CREATE DATABASE my_test; USE my_test; SELECT "Hello, TiDB!" as greetings;
更多部署选项
除了使用playground，还有几种其他方式可供选择：
数据持久化：默认关闭后数据丢失，若要保留数据，可增加 tag 参数启动：
tiup playground --tag <your-tag>。指定组件：可以指定 TiDB 版本来模拟更真实的分布式环境，例如
tiup playground v8.5.2 --db 2 --pd 3 --kv 3 --tiflash 1。云上免费资源：如果不想在本地部署，也可以考虑 TiDB Cloud 提供的免费Serverless云服务，可作为快速的入门选择。
🧠 深入解析：TiDB 的向量搜索功能
TiDB 的向量功能开辟了新的数据维度，它并非简单的存储，而是一套完整的解决方案。
什么是向量搜索？
简单来说，它是一种基于数据语义而非关键词的搜索技术。它通过 AI 模型（如 BERT）将文本、图像等非结构化数据转换成一组有代表性的浮点数序列（称为“向量”或“Embedding”）。搜索时，系统会计算查询向量与库中所有向量的“相似度”（如距离），并返回最匹配的结果。
例如，用户在电商网站搜索“舒适的鞋子”，向量搜索能理解其语义，返回“柔软”、“缓震”等相关的鞋款，而非仅限包含“舒适”二字的商品。其典型应用场景包括检索增强生成、语义搜索和推荐系统。
TiDB 向量存储与操作
TiDB 提供了专门的VECTOR数据类型来存储向量，你可以用它来为表格定义一个向量列。
1. 创建表并定义向量字段
-- 定义一个固定为 3 维的向量列 CREATE TABLE test_vector ( id INT PRIMARY KEY, doc TEXT, embedding VECTOR(3) );
注意：
TiDB 支持
VECTOR(D)固定维度和VECTOR可变两种类型，但只有固定维度的列才能创建向量索引以加速搜索。
VECTOR列最多支持 16383 维。
2. 插入向量数据直接使用带方括号的字符串格式插入向量值。
INSERT INTO test_vector (id, doc, embedding) VALUES (1, '苹果公司', '[0.1, 0.2, 0.3]'), (2, '香蕉水果', '[0.4, 0.5, 0.6]'), (3, '小狗动物', '[0.7, 0.8, 0.9]');
如果尝试向VECTOR(3)列中插入一个 2 维或 4 维的向量，数据库会直接报错。
3. 执行向量搜索TiDB 提供了VEC_COSINE_DISTANCE()（余弦距离）和VEC_L2_DISTANCE()（欧氏距离）等距离函数来计算向量相似度。此场景下，较小的距离表示较高的相似度。
-- 搜索最接近 '[0.1, 0.2, 0.8]' 的前两行数据 SELECT id, doc, vec_cosine_distance(embedding, '[0.1, 0.2, 0.8]') as distance FROM test_vector ORDER BY distance LIMIT 2;
4. 利用索引优化搜索性能对于包含大量数据的表，创建向量索引可以极大地提升查询性能。TiDB 目前支持HNSW算法，这是一种非常高效的近似最近邻（ANN）搜索索引。
-- 在创建表时就为 embedding 列创建一个 HNSW 索引 CREATE TABLE product_embeddings ( id INT PRIMARY KEY, description TEXT, features VECTOR(128), VECTOR INDEX idx_features ((VEC_COSINE_DISTANCE(features))) USING HNSW );
使用向量索引的搜索召回率通常可保持在90% 以上。
TiDB 向量功能与专业向量数据库对比
为了帮你更好地理解其定位，这里简要对比一下 TiDB 与专业向量数据库（如 Milvus、Pinecone 等）：
核心优势：TiDB 的强项在于数据集成。它将向量能力无缝融入成熟的关系型数据库体系，你可以使用熟悉的 SQL 操作混合数据（例如
WHERE条件同时筛选price > 100和向量相似度），避免维护两套系统的复杂性和数据不一致问题。局限性：作为“Beta”实验特性，TiDB 的向量功能相对较新，目前支持的索引类型主要为 HNSW，在索引算法多样性（如 IVF）、
JOIN等复杂查询的性能以及一些高级功能上，可能不如纯粹的向量数据库成熟。
因此，如果你已有 TiDB 生态，或希望简化架构，TiDB 的向量功能是一个很具吸引力的融合方案；如果你的应用场景对向量检索性能有极致要求，专业的向量数据库可能仍是首选。
