justlpf的专栏

类别值集群名称tidb-test集群版本v6.3.0。

New-Order：客户输入一笔新的订货交易；Payment: 更新客户账户余额以反映其支付状况;Delivery: 发货(模拟批处理交易);Order-Status: 查询客户最近交易的状态；Stock-Level: 查询仓库库存状况，以便能够及时补货。

TiDBCPU 运算性能测试磁盘 IO 性能测试调度程序性能测试内存分配及传输速度测试POSIX 线程性能测试数据库性能测试（OLTP 基准测试，需要通过 /usr/share/sysbench/ 目录中的 Lua 脚本执行，例如 oltp_read_only.lua 脚本执行只读测试）

常见的increment类型自增主键就是按顺序递增的，默认情况下，在主键为整数型时，会将主键值作为RowID ，此时RowID也为顺序递增，在大量insert时就会形成表的写入热点。同时，性能监控图表也显示，在负载高的时刻，是几台机器同时高，而不再是单独一台升高，这说明我们的优化手段是有效的，TiDB作为分布式数据库的优势得以真正体现。对此，在进行TiDB优化时，我们从表结构入手，对以自增ID作为主键的表进行重建，删除自增ID，使用TiDB隐式的_tidb_rowid列作为主键，将。

事务隔离级别是数据库事务处理的基础，中的 “I”，即 Isolation，指的就是事务的隔离性。SQL-92 标准定义了 4 种隔离级别：读未提交 (READ UNCOMMITTED)、读已提交 (READ COMMITTED)、可重复读 (REPEATABLE READ)、串行化 ()。实现了快照隔离 (Snapshot Isolation, SI) 级别的一致性。为与 MySQL 保持一致，又称其为“可重复读”。该隔离级别不同于和。在 TiDB v3.0 中，事务的自动重试功能默认为禁用状态。

TiDB 对应的是 Google F1， 是一层无状态的 SQL Layer ，兼容绝大多数 MySQL 语法，对外暴露 MySQL 网络协议，负责解析用户的 SQL 语句，生成分布式的 Query Plan，翻译成底层 Key Value 操作发送给 TiKV ， TiKV 是真正的存储数据的地方，对应的是 Google Spanner ，是一个分布式 Key Value 数据库，支持弹性水平扩展，自动的灾难恢复和故障转移（高可用），以及 ACID 跨行事务。“Rust”，由web语言的领军人物。

9、列数支持太少，只支持100列，和oralce/mysql的1000列少太多（Oracle 最大列数为 1000；MySQL对于每个表具有4096个列的硬限制, 其中InnoDB每个表的限制为1017列, 最大行大小限制为65,535字节）5、内存使用有问题，GO语言导致不知道回收机制什么时候运作。6、数据写入的时候，tidb压力很大, tikv的CPU也占用很高。1、对硬盘要求很高，没上SSD硬盘的不建议使用。2、不支持分区，删除数据是个大坑。4、删除表数据时不支持别名。3、插入数据太大也会报错。

在的架构中，所有数据以一定 key range 被切分成若干 Region 分布在多个 TiKV 实例上。随着数据的写入，一个集群中会产生上百万个甚至千万个 Region。单个 TiKV 实例上产生过多的 Region 会给集群带来较大的负担，影响整个集群的性能表现。

TPC-C 是一种衡量 OLTP 系统性能和可伸缩性的基准测试项目。它由一系列的 OLTP 工作流组成，包括查询，更新及队列式小批量事务在内的广泛数据库功能。它模拟了一个典型的 OLTP 应用环境中的活动，这些活动由一系列复杂的事务组成。适当复杂的 OLTP 事务在线和延迟事务执行模型多用户适当的系统和应用执行时间大量的磁盘输入和输出事务完整性（ACID）随机的数据访问数据库由各种大小，属性和关系的表组成。

TPC-C 模拟了一个比较有代表意义的 OLTP 应用环境：在线订单处理系统。假设有一个大型商品批发商，拥有 N 个位于不同区域的仓库，每个仓库负责为 10 个销售点供货，每个销售点有 3000 个客户，每个客户平均一个订单有 10 项产品。由于一个仓库中不可能 存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是 分布的。N 是一个可变参数，测试者可以随意改变 N，以获得最佳测试效果。tpcc有5种事务，测试完成后会输出这5种事务的吞吐量和延迟。

TIDB 社区版 商业版

随着国内互联网企业的快速发展，传统的oracle数据库架构在成本和扩展性上已不能满足要求，更多的企业将目光转向了开源的MySQL数据库，由于MySQL本身是一个单机数据库其本身并不具备横向扩展能力，于是出现了应用侧的分库分表方案。进一步的又开发出分库分表中间件，由中间件完成分库分表的管理，避免了应用侧的复杂性，分库分表虽然一定程度解决了扩展性的问题，但也存在着其他比较严重的问题，比如：必须指定分库键、分布式事务支持能力差、全表扫描性能影响、在线扩展能力不足等，实际上分库分表更多的只是一个路由功能。

TiDB是一个开源的NewSQL数据库，支持HTAP（Hybrid Transactional and Analytical Processing），既支持事务型操作，也支持数据分析。同时TiDB和MySQL的大多数协议都是兼容的。支持水平扩展，强一致性和高可用。TiDB的目标是提供一个一站式数据库解决方案。包括OLTP(Online Transactional Processing), OLAP (Online Analytical Processing), and HTAP services。

参考文章：TiDB on Kubernetes 最佳实践随着 Kubernetes（K8s） 的全面成熟，越来越多的组织开始大规模地基于 K8s 构建基础设施层。然而，考虑到数据库在架构中的核心地位与 K8s 在有状态应用编排上的短板，仍有不少组织认为在 K8s 上运行核心数据库会带来颇高的风险。事实上，在 K8s 上运行 TiDB 不仅能实现企业技术栈的统一，降低维护成本，还能带来更高的可用性与安全性。本次分享将介绍 TiDB 在 K8s 上的运维管理系统 TiDB Operator，再从各类故障场.

参考文章：OLTP、OLAP与HTAPOLTPOn-Line Transaction Processing联机事务处理过程(OLTP)也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理结果的一个重要指标是系统性能，具体体现为实时请求-响应时间(Response Time)

参考文章：Elasticsearch对比TiDB笔者做过的一个项目中，同时用到了Elasticsearch和Tidb两种存储相关的产品。这两者适用的场景有些差异，但其实又有交集。前者偏向搜索，后者则主打分布式存储。下面根据自己的理解从不同维度分析下二者的相同点和不同点。对比维度 Elasticsearch TiDB 产地 公司现在的名称是Elastic， 其实它的员工遍布世界各地，一般认为公司的总部是阿姆斯特丹 公司是PinCap，在北京，是国内的公司。 版本历

对比TiDB和MySQL在大表复杂join方面，TiDB比MySQL快很多（至少三倍），这应该得益于TiDB的 分布式架构，把逻辑计算下推到各个数据节点并行执行导致的。由于TiDB有着很好的水平分布式扩展，突破了单实例容量的限制，和分库分表比，应该有着更好的优势。TiDB会降低开发和运维的复杂度，在2020到来之前，我继续调研这个数据库。目前计划先把tidb作为MySQL从库使用，架构如下：...

参考文章：日均数据量千万级，MySQL、TiDB 两种存储方案的落地对比盖娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。初期的MySQL存储方案在系统设计之初，基于对数据量的预估以及简化实现方案考虑，我们选用了高可用的 MySQL RDS 存储方案，当时的匹配逻辑主要通过 SQL 语句来实现，包含..

参考文章：一个长耗时SQL在TiDB和Mysql上的耗时测试之前看到的TiDB和MySql的性能对比都是大量短耗时请求下的压测，单机情况下TiDB和MySql的确有些差距，不过笔者最近碰到的场景更多是sql要扫描的行数不小的情况下单sql比较耗时的问题，所以自己做了个简单测试这类型sql的耗时。TiDB单机环境部署按照官方文档(https://pingcap.com/docs-cn/dev/how-to/get-started/deploy-tidb-from-docker-compose/)

参考文章：TiDB 和 MySQL的差异站在业务开发的视角，TiDB 最吸引人的几大特性是：支持 MySQL 协议（开发接入成本低）； 100% 支持事务（数据一致性实现简单、可靠）； 无限水平拓展（不必考虑分库分表）。 基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。TiDB 事务和 MySQL 事务的差异...

参考文章：TiDB 简介1.什么是 TiDBTiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP