本文档总结使用 TiDB 时的一些最佳实践，主要涉及 SQL 使用和 OLAP/OLTP 优化技巧，特别是一些 TiDB 专有的优化开关。建议先阅读讲解 TiDB 原理的三篇文章（讲存储，说计算，谈调度），再来看这篇文章。前言数据库是一个通用的基础组件，在开发过程中会考虑到多种目标场景，在具体的业务场景中，需要根据业务的实际情况对数据的参数或者使用方式进行调整。TiDB 是一个兼容 MySQL 协
TiDB特点高可用水平拓展事务SQL支持TiDB架构和MySql不同，TiDB是一个分布式的数据库而不是单个进程,所以整个TiDB是由以下角色组成: TiKV, PD, TiDB, TiSpark。每个角色都是部署在多台机器上的进程组成的集群。TiKV PD TiDB功能TiKVTiKV负责数据的存储,对外而言，它就是一个提供key-value存储的引擎。但它存储的并不是离散的Key,而在一个范围
背景最近在给一个物流系统做TiDB POC测试，这个系统是基于MySQL开发的，本次投入测试的业务数据大概10个库约900张表，最大单表6千多万行。这个规模不算大，测试数据以及库表结构是用Dumpling从MySQL导出，再用Lightning导入到TiDB中，整个过程非常顺利。系统在TiDB上跑起来后，通过Dashboard观察到有一条SQL非常规律性地出现在慢查询页面中，打开SQL一看只是个单
首先谈谈 Schema 设计的一些比较好的经验。由于 TiDB 是一个分布式的数据库，可能在表结构设计的时候需要考虑的事情和传统的单机数据库不太一样，需要开发者能够带着「这个表的数据会分散在不同的机器上」这个前提，才能做更好的设计。和 Spanner 一样，TiDB 中的一张表的行（Rows）是按照主键的字节序排序的（整数类型的主键我们会使用特定的编码使其字节序和按大小排序一致），即使在 CREA
作者：leeray
一、引言 日志一直是溯源系统运行错误的重要存在。TiDB 也不例外在系统中进行日志的记录。我们经常遇到的有两种。一种是 tidb.log 格式，记录系统运行时各类日志。另外一个就是慢查询日志，一般以 tidb-slow.log 命名。日志等级一般分为 5 种。从低到高依次是：“DEBUG”、“INFO”、“WARNNING”、“ERROR”、“CRITI
作者： 代晓磊_Mars
库表命名规范 表名规范 表名小写，禁止驼峰，比如 ad_Audit,jobSeq 等等，过长的可以用下划线（_）分割 字段名规范 禁止使用 mysql 的关键字，比如 order，group、show、slave 等 详见mysql官网：https://dev.mysql.com/doc/refman/8.0/en/keywords.html 索引命名
表分区，注意事项确认表中是否存在唯一键(包括主键) ，如果存在，那么唯一键 中，必须包含分区表达式中用到的所有列如果表中不存在唯一键 ，那么第1条规则也就不需要遵守了分区列是主键列，那么分区列不可以是 NULL
分区表达式中列的数据类型，要与表中列的数据类型相符合删除分区一定会删除分区中所有数据，不会自动转移数据
MAXVALUE按时间分区默认左开右闭区间。1 表分区 RANGE-- 创建表
CR
TiDB数据库schema设计之索引设计索引的KV映射原理索引的设计索引的创建联合索引索引覆盖表达式索引不可见索引索引使用的注意事项运维技巧 索引的KV映射原理首先回顾一下表的行数据的KV映射原理：对于聚簇表，TiDB会将表的编号加上主键作为Key，其余列作为Value。# 假设Col1是主键列（聚簇索引）
Key: tablePrefix{tableID}_recordPrefixSep{Co
“搜索”是内容类App产品非常重要的一个功能，“全文检索”是支持它不可或缺的一项基本能力。目前业界很多公司产品的业务数据已经向 TiDB 迁移了，但目前在 TiDB 上只能使用 SQL Like 对内容进行简单的检索。即便不考虑性能问题，SQL Like 仍然无法实现搜索场景下常见的信息检索需求，单纯使用 Like 会导致查询到有歧义的结果或满足搜索条件的结果无法返回。由于TiDB 全文检索能力的
TiDB 是什么？TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。TiDB怎么来的？著名的开源分布式缓存服务 Codis 的作者，PingCAP联合创始人& CTO ，资深 infrastructure 工程师的
从存储层读取数据是 SQL 计算过程中最为耗时的部分之一，TiDB 目前支持从不同的存储和不同的索引中读取数据，索引选择得是否合理将很大程度上决定一个查询的运行速度。本章节将介绍 TiDB 如何选择索引去读入数据，以及相关的一些控制索引选择的方式。读表在介绍索引的选择之前，首先要了解 TiDB 有哪些读表的方式，这些方式的触发条件是什么，不同方式有什么区别，各有什么优劣。读表算子读表算子触发条件适
索引用于在查询时提高效率之用。可以为每张表的某个字段定义索引来提高在该字段上的查询效率。由于数据库要处理的数据量非常大，而内存因为价格昂贵，而容量有限，且必须满足一定的实时性，因而对其中的数据的存储及索引方式进行研究，找出有效的数据组织方式是非常有必要的。磁盘数据库系统的典型的索引技术是B-tree索引。B-tree结构的主要目的是减少完成数据文件的索引查找所需要的磁盘I/O的数量。B-tree
本文介绍如何定位和解决读写热点问题。TiDB 作为分布式数据库，内建负载均衡机制，尽可能将业务负载均匀地分布到不同计算或存储节点上，更好地利用上整体系统资源。然而，机制不是万能的，在一些场景下仍会有部分业务负载不能被很好地分散，影响性能，形成单点的过高负载，也称为热点。TiDB 提供了完整的方案用于排查、解决或规避这类热点。通过均衡负载热点，可以提升整体性能，包括提高 QPS 和降低延迟等。常见热
TiFlash 是 TiDB 的分析引擎，是 TiDB HTAP 形态的关键组件，TiFlash 源码阅读系列文章将从源码层面介绍 TiFlash 的内部实现。在前面的源码分析中对 TiFlash 的计算层和存储层都进行了深入的分析，其中 TiFlash DeltaTree 存储引擎设计及实现分析 (Part 1) TiFlash DeltaTree 存储引擎设计及实现分析 (Part
一、数据库优化器原理预处理阶段针对点查进行优化（直接下推到SQL执行器。优化原因：优化方式单一，使用频率最高。）构造初始的逻辑执行计划
常量折叠表达式简化子查询处理（子查询转换为表连接）逻辑优化列剪裁分区剪裁聚合消除MAX/MIN优化投影消除外连接消除谓词下推连接顺序调整物理优化扫描方式
全表扫描索引扫描-索引选择算子物理实现方式
聚合算子连接算子排序算子是否将算子下推到存储层
在这我们将关系模型简单理解为 Table 和 SQL 语句，那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。假设我们有这样一个表的定义：CREATE TABLE User {ID int,Name varchar(20),Role varchar(20),Age int,PRIMARY KEY (ID)，Key idxAge (age)};
Mysql索引-B树/B+树tip 索引好处初体验：select count(*) from ydl_user; -- 5.429
select * from ydl_user where user_id = 1000000; -- 0.355s
select * from ydl_user where user_name = 'Jennifer Susan Johnson'; -- 4.7
TiDB特点高可用水平拓展事务SQL支持TiDB架构 和MySql不同，TiDB是一个分布式的数据库而不是单个进程,所以整个TiDB是由以下角色组成: TiKV, PD, TiDB, TiSpark。每个角色都是部署在多台机器上的进程组成的集群。TiKV PD TiDB功能TiKV TiKV负责数据的存储,对外而言，它就是一个提供key-value存储的引擎。但它存储的并不是离散的Key,而在一个
1.Tidb总体体系架构 2. Tidb Server架构介绍2.1 TIDB server TIDBserver的模块功能简介：处理客户端的连接，是由 Protocol Layer 负责的。SQL 语句的解析和编译，是由 Parse + Compile 负责，解析和编译完成后交给
表普通表可被alter table修改删除表:drop tablerange分区表概念：指定创建表中的（sales_date date）作为分区依据进行分区PARTITION BY RANGE(sales_date)分区表的分区是和表一起创建的，不能分开执行创建。PARTITION BY range(age_id)( PART p1 STARTING(0) ENDING(10), PAR
