ITPub博客

TiDB 作为新一代分布式关系型数据库，从诞生第一天起拥抱 MySQL 生态，不断地兼容 MySQL 5.7 和 MySQL 8.0，为用户带来更加顺畅的迁移和使用体验。本文将介绍 TiDB 7.4 DMR 在 MySQL 8.0 兼容方面的新进展，探讨 TiDB 如何从根本上解决 MySQL 用户面临的各种挑战。

本文的主角 -- TiFlash 是 TiDB HTAP 形态的关键组件，它是 TiKV 的列存扩展，通过 Raft Learner 协议异步复制，但提供与 TiKV 一样的快照隔离支持。我们用这个架构解决了 HTAP 场景的隔离性以及列存同步的问题。自 5.0 引入 MPP后，也进一步增强了 TiDB 在实时分析场景下的计算加速能力。

我们集结社区的集体智慧，共同创作了《TiDB 6.x in Action》，今天，这本书正式发布啦！

随着数字化进程的加速，云和开源扮演着越来越重要的角色： 在中国，2020 年公有云部署模式的关系型数据库超过传统部署模式 ；在全球，2021 年开源数据库的流行度首次超越商业数据库 。2022 年 6 月 13 日，TiDB 6.1 发版；6 月 15 日，云数据库 TiDB 正式上线阿里云心选商城。此前，TiDB 上线了亚马逊云科技 Marketplace（中国区）

本文包含：TiDB 性能优化概述TiDB 性能分析和优化OLTP 负载性能优化实践Performance Overview 面板重要监控指标详解1、TiDB 性能优化概述https://tidb.net/blog/1731b9772、TiDB 性能分析和优化本文介绍了基于数据库时间的系统优化方法，以及如何利用 TiDB Performance Overview 面板进行性能分析和优化。通

1.目标:试用TiDB v5.1.2与TiDB v6.0.0 TiKV 节点重启后 leader 平衡加速，提升业务恢复速度对比2.硬件配置:角色cup/内存/硬盘TiDB&PD16核/16G内存 /SSD200G3台TiKV16核/32G内存 /SSD500G3台Monitor16核/16G内存/ SSD50G1台3.拓扑文件配置TiDBv5.1.2拓扑文件参数配置server_conf

结论先行TiDB 6.0正式提供了数据放置框架（Placement Rules in SQL ）功能，用户通过 SQL 配置数据在 TiKV 集群中的放置位置，可以对数据进行直接的管理，满足不同的业务场景需要。如：1.冷热分离存储，降低存储成本TiDB 6.0正式支持数据冷热存储分离，可以降低SSD使用成本。使用 TiDB 6.0的数据放置功能，可以在同一个集群实现海量数据的冷热存储，将新的热数据

对数据库而言，合适的字符集和规则能够大大提升使用者运维和分析的效率。TiDB 从 v4.0 开始支持新 collation 规则，并于 TiDB 6.0 版本进行了更新。本文将深入解读 Collation 规则在 TiDB 6.0 中的变更和应用。引这里的“引”，有两层含义，这第一层是“引言”，从 TiDB v6.0 发版说明  中可以了解到，TiDB 6.0 引入了很多新特性，同时也引

背景最近在给一个物流系统做TiDB POC测试，这个系统是基于MySQL开发的，本次投入测试的业务数据大概10个库约900张表，最大单表6千多万行。这个规模不算大，测试数据以及库表结构是用Dumpling从MySQL导出，再用Lightning导入到TiDB中，整个过程非常顺利。系统在TiDB上跑起来后，通过Dashboard观察到有一条SQL非常规律性地出现在慢查询页面中，打开SQL一看只是个单

背景介绍    某一天早上来到公司，接到业务同学反馈，线上某个SQL之前查询速度很快，从某个时间点开始查询速度突然变慢了，希望DBA帮忙查看下。业务同学反馈的原话如下：    看到这个问题，我第一时间询问了业务对这个表的基本操作，得到的反馈如下：这个表的SQL语法没有发生过变化这个表的表结构近期未发生变更这个表是个日志表，近期只有写入insert，没有大量d

TiKV节点缩容不掉，通常遇到的情况：1、经常遇到的情况是：3个节点的tikv集群缩容肯定会一直卡着，因为没有新节点接受要下线kv的region peer。2、另外就是除缩容tikv外，剩下的KV硬盘使用情况比较高，到达schedule.high-space-ratio=0.6的限制，导致该tikv的region无法迁移。但是今天要讨论的是：我先执行了扩容，然后再进行的缩容，仍然卡着就说不过去了。

一、前言         OceanBase和TiDB作为国内2款的比较流行的兼容MySQL协议的开源数据库使用者也越来越多，两种数据库不仅在架构原理上有较大差异，在开源方式上有较大的不同：         TiDB 采用的Apache L

对于很多现代人来说，在忙碌的工作中，一顿口味不错、能量满满、质量可靠且快速方便的汉堡、薯条、炸鸡的确是不错的选择。更何况快餐中富含的盐、糖、脂肪和碳水化合物也更容易让人产生满足感。但在享受快餐所带来的快乐时，你是否也曾想过，快餐企业在运营成百上千家门店的同时是如何做到线上买券、线下提货，在家下单、快递上门，手机下单、门店取货等一系列高级别数字化操作的？业务重心从线下到线上：餐饮连锁企业经营新模式疫

在了解IndexLookUp执行过程前，先介绍下mysql索引扫描的执行作为对比(此处借用网络图)，一条SQL执行时在存储引擎侧首先通读取索引中符合条件记录的主键(可能涉及ICP、组合索引部分列等)，然后根据主键去表中读取记录，之后将记录返回给server层，再由server层根据其他条件进行过滤后返回客户端。上述过程中索引扫描和回表操作都是在存储引擎侧完成。    &nbsp

1.背景最近刚学习完PCTP，对TiDB的各种读写有了粗略的了解，但是要想研究的更细节一些的东西， 肯定离不开学习源码，学习源码的话大家可以参考官方的TiDB源码系列文章，但是官方的文章 都是18年发的，可能会有些滞后，所以大家可以参考这个以及结合源码去学。TiDB源码系列解读文章：官方源码解读博客地址然而学习源码肯定编译调试源码是最有效的学习途径，经过这几天的学习，以及请教开发大佬， 成功

当大家看到这个标题时，就已经知道了下面几点：（1）出了撒子问题？ok，集群所有KV节点存储硬盘使用80%以上，凌晨触发频繁报警，搞DB的兄弟们还能不能愉快的睡觉？（2）谁搞的？ok，GC不干活。（3）真正导致问题的原因是啥？OK，TiCDC背锅。完了，看到这里本篇文章就基本介绍完了，会不会被劝退？但是老铁千万别走，且听我将细节娓娓道来，后面有“干货”，我会说明我到底做了啥子操作降低硬盘使用；GC为

写这篇文章更多的是像一篇年终回忆，春节之前一直有这么个想法来回顾这一年我和TIDB奇妙的缘分，但是总被俗务缠身搁置到现在，直到表妹前段时间约稿，我知道不得不开始了。人群中多看了你一眼应该是好多年以前，偶然在某个技术公众号上第一次看到TiDB这个词，那时候还是一个刚工作没多久的小开发，并不能理解TiDB背后强大的设计思想，只留下一个模糊的印象：和MySQL类似的一个新的开源数据库，仅此而已。当时也并

一、文档目的在使用 TiDB Cloud 过程中，通常大家面临的第一个难题便是如何将现有集群的数据导入至 TiDB Cloud  集群中，”很幸运“地是 TiDB Cloud 上提供了多种方式可以帮助大家完成这一过程，大家可以自行到官网上查看。本文档提供了将 AWS S3 中数据导入至 TiDB Cloud  集群的操作步骤，供大家参考。说明：目前在免费的 TiDB Cloud

前言岁月是一把杀猪刀，我把近几年对TiDB的回忆、思考、理解、定义写成一段真实的故事，做为国产数据库人气一哥成长的见证者，我看着他一路成长，希望TiDB后面的路可以越走越顺。2018年初识TIDB,那是2018年8月份，当时基于国产数据分析产品调研的背景，我在网上东寻西找，搜查奇珍异宝，然后TiDB跃入眼前。2017 易观 OLAP 算法大赛，TiDB居然获得冠军，这个比赛我有关注过，没有想到是T

1      前言      随着国内互联网企业的快速发展，传统的oracle数据库架构在成本和扩展性上已不能满足要求，更多的企业将目光转向了开源的MySQL数据库，由于MySQL本身是一个单机数据库其本身并不具备横向扩展能力，于是出现了应用侧的分库分表方案。进一步的又开发出分库分表中间件，由中间件完成分库分表的管理，