分布式数据库（Tencent Distributed SQL，TDSQL）是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施，为用户提供完整的分布式数据库解决方案。目前 TDSQL 已经为超过500+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。TDSQL 亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。
腾讯云分布式数据库（Tencent Distributed MySQL，TDSQL ）是基于分布式架构支持自动水平拆分的高性能数据库，为您有效解决业务快速发展时的数据库性能瓶颈，随着业务量的变化，您可以随时调整您的分布式 TDSQL 规格。
腾讯云 TDSQL 是基于分布式架构的数据库，高度兼容 MySQL、高性能、高可用、企业级安全与监控、可扩展、易用性为一体的数据库托管服务。
兼容大多数常用的 MySQL 语法
包括 MySQL 的语言结构、字符集和时区、数据类型、常用函数、预处理协议、排序、联合（join）、存储过程、索引、分区、事务、预处理协议、控制指令、等常用的 DDL、DML、DCL 和数据库访问接口。
支持（分布式）事务
通过两段提交的方式支持分布式事务，支持诸如转账、出单、支付等场景；跨节点事务性能约为单节点的 70%，高于开源分布式事务 XA 约 56%。目前仅开放 MySQL 5.7支持该能力。
支持（分布式）JOIN
TDSQL 支持多个物理节点之间的 JOIN（联合查询）操作，即分布式 JOIN。如果 JOIN 相关的表有 shardkey 相等条件，由于分表的一致性原则，会让这部分数据自动存储到同一物理节点，此时相当于单机 JOIN，性能最好。如果涉及到跨物理节点数据，此时 proxy 会先从其他节点拉取数据并缓存，由于涉及到网络数据传输，性能会损失。
支持JSON
TDSQL 支持存储 JSON 格式的数据，使得对 JSON处理更加有效，同时又能提早检查错误；如果您既希望使用 JSON类型，又对数据一致性，事务，JOIN 等传统数据库具备的能力也有一定要求的话，TDSQL 将是一个很好的选择，当然 TDSQL 的 JSON 是基于 MySQL 与 Mongodb 的使用仍有一些差异，如果您感兴趣，可以阅读 TDSQL 与 MongoDB 的 JSON 能力对比。
三种建表策略
分表：即水平拆分的表，通常适用于表规模大于 2000 万行、大于 50GB，且快速增长的表；
广播表：即所有操作都将广播到所有逻辑分片（Shard）中，这意味着每个分片都有该表的全量数据，通常适用于配置表，或需要频繁 JOIN 的表，该类表数据更新相对较少，广播表可以两个表的联合查询（JOIN）、事务收敛到单节点中，以提高性能；
单表：一些无需分片的表，通常适用于数据量较小的库表；由于单表并未拆分，这意味着单表使用完全兼容 MySQL。
全局唯一数字序列
与 AUTO_INCREMENT 类似。自增长序列为用户提供一个全局唯一数字 ID 服务，实现分布式环境下唯一键、主键等数据的全局唯一性。
透传命令
支持通过注释方式（hint）将 SQL 透传到指定目标分片，以提高性能和操作灵活性。
二级分区
在分表的基础上，还支持分区表方案。即在水平拆分的表，再支持一层逻辑分区，因此叫做二级分区；二级分区可以均衡数据分布和访问，可以提高查询效率，也支持诸如游戏历史战绩、IoT 传感器数据，需要定期删除历史数据等场景。
读写分离（从机只读）
TDSQL 默认支持读写分离能力，主从架构中的每个从机都能支持只读能力，如果配置有多个从机，将由网关集群（TProxy）自动分配到低负载从机上，以支撑大型应用程序的读取流量；读写分离的方案包括：只读账号，/*slave*/，只读实例三种方案。
线程池
TDSQL 默认支持线程池，腾讯对线程池的调度算法进行了优化，改进当系统处于重负载时，查询和更新请求在线程组间分布不均衡等极端情况，并且能够更好地利用计算资源，减少无谓的线程切换，减少请求在队列中的等待时间，及时处理请求。
高端硬件配置
TDSQL 基于 PCI-E SSD，提供至少高于 SATA 三倍的 IOPS 配置，强大 IO 性能保障数据库的访问能力；存储硬件采用 NvMe 协议，专门针对 PCI-E 接口的 SSD 设计，更能发挥出性能优势；单分片最大支持 245509 QPS(每秒访问次数)、384GB 内存和 6TB 存储空间。
性能并发线性增长
分布式架构的特性是随着 TDSQL 分片的增加，每个分片分别承担一部分分布式任务的处理，这样您的数据库性能等同于线性增长。
支持RocksDB
RocksDB 是新近开源的存储引擎，包括 FB 在内的大量公司都在使用 RocksDB，而 RocksDB 是一种基于LSM 树的存储引擎，其数据压缩率领先 InnoDB 引擎 60% 以上，即 InnoDB 压缩前 160GB 数据使用RocksDB 后仅需 62GB，相当于每 1000 行数据仅需1GB存储空间，极大节省数据库使用成本；另外 RocksDB 的写入性能也有较大提升，高并发情况下约为 InnoDB 的 5 倍以上。因此，RocksDB 特别适合物联网、日志等“写多读少”，且对容量比较敏感的业务。
分布式高可用
分布式系统架构本身就具有极高的可用性，即单一节点故障，并不影响集群整体可用性。而 TDSQL 在分布式架构的基础上，对每个分片都配置主从冗余，确保业务持续高可用。
三种数据复制方式
TDSQL 支持强同步（不可蜕化）、强同步（可蜕化）、异步复制三种方式。基于腾讯自研异步多线程强同步复制技术技术，极大提高了数据强同步复制性能。在强同步性能基本等同于异步的基础上，确保主从节点的数据强一致性。
透明故障转移
每一个分片和底层物理设备提供 7X24 小时持续监控。发生故障时，网关集群（TProxy）将及时从故障节点切换到正常节点。在主从切换时，VIP不变，这意味应用层无需做任何改动即可完成热备切换，业务对容灾切换无感知。
节点故障自动恢复
承载分片的物理节点故障，调度系统自动重试恢复节点，如果原节点无法恢复，将在 30 分钟内自动申请新资源，并通过备份重建（Rebuild）节点，并将节点自动加入集群，已确保分片长期来看保持主从容易。
支持跨可用区部署
主机和从机可分处于同城不同可用区，通过腾讯专线网络进行实时的数据复制。本地为主机，远程为从机，外部访问该数据时，首先访问本地的实例，若本地实例发生故障或访问不可达，则访问远程从机。跨可用区部署特性为 TDSQL 提供了多可用区容灾的能力，主机和从机切换过程对用户透明，避免了单 IDC 部署的运营风险。
金融级两地三中心方案
TDSQL 可提供同城双中心、两地三中心的部署架构。故障发生时，您可以在几分钟内将数据库恢复正常运行。
符合国家/国际/行业相关标准
TDSQL 现已代表腾讯云云数据库通过多项国家或国际认证，包括但不限于：ISO22301 认证、ISO27001 认证、ISO20000 认证、ISO9001 认证、可信云服务认证、信息安全等级保护（三级或以上）、CSA STAR 认证。
TDSQL 部分功能设计标准也参考 GBT 20273-2006 信息安全技术 数据库管理系统安全技术要求、JRT 0072-2012 金融行业信息系统信息安全等级保护测评指南；即使您的业务对数据库安全较为敏感，也可以完全放心的使用 TDSQL。
数据库内核级安全
针对诸如 SQL 注入、目录穿越攻击（Path Traversal）、非法提权、系统表覆盖攻击、插件引入等安全隐患，TDSQL 做了大量的安全优化，并在数据库集群内部提供内置数据库防火墙，从运维和使用角度都能帮助您的业务提高安全标准。
支持私有网络
TDSQL 允许您在私有网络（VPC）中运行数据库实例，这使您可以隔离数据库实例并通过行业标准加密的 IPsec VPN 或专线连接到您现有的数据中心。
数据库防火墙与多重安全防护
云数据库默认为每个数据库提供多重安全防护，在提供了外网访问功能的数据库实例遭到 DDoS 攻击时，帮助用户抵御各种攻击流量，保证业务正常运行。高效防御 SQL 注入、暴力破解等数据库攻击行为，极大减少用户因数据库攻击带来的业务中断和损失。
细粒度的权限控制
默认屏蔽超级管理员 root 账号，避免安全隐患；提供精确到表、函数、存储过程等对象级别的权限控制，让您分配的账号只能访问被授权的资源，并将风险控制在可预期范围内。
支持物理独享方案
在公有云、金融云、黑石数据库（专区）支持以独享物理集群（设备）全部资源部署数据库，这意味着您专享独立的物理设备，不与其他租户共用。独享集群满足您对资源独享、物理安全、行业监管等需求；购买独享集群后，通过腾讯云控制台，灵活创建多种自定义规格的数据库实例。
存储高可靠
提供在线的主从两份数据存储，确保线上数据安全。每日自动备份数据，云数据库可根据备份文件提供 3 天内的任意时间点回档。同时每天的冷备数据都会存储多份，以便于在灾难情况下进行数据恢复。您可以放心的将数据存储在 TDSQL 上，无需考虑数据丢失的问题。
全面的日常监控
日常监控支持 60 秒粒度，覆盖连接访问、数据库负载、查询缓存、存储引擎等七十余项重要指标，可全方位监控数据库运行状况。十五项数据库核心性能指标支持秒级的实时监控，可帮助您及时掌握实例运行状况，快速定位实例性能问题。自定义资源阈值告警，可帮助用户知晓 DB 运行中的问题。它将问题及时反馈给运维人员，帮助您快速响应数据库问题。提供慢查询分析报告和 SQL 完整运行报告下载，帮助您了解影响数据库性能的因素。
自定义告警
自定义资源阈值告警，可帮助用户知晓 DB 运行中的问题。它将问题及时反馈给运维人员，帮助您快速响应数据库问题。
性能分析日志
提供慢查询分析报告和 SQL 完整运行报告下载，帮助您了解影响数据库性能的因素。
弹性扩展
目前单一分片最大可支持 6TB 存储，如果性能或容量不足以支撑业务发展时，在控制台点击，即可自动升级完成。升级过程中，您无需关心分布式系统内的数据迁移，均衡和路由切换。升级完成后访问 IP 不变，仅在自动切换时存在秒级闪断，您仅需确保有重连机制即可。
自动再均衡（Rebalance）
增加分片或升级分片规格时，数据自动迁移，保证每个节点数据实现均衡分布；迁移过程服务不会停止，只会有几个分配存在秒级的只读。以提高大型业务维护效率，减少运营风险事件发生。
轻松管理海量数据库
提供命令行和 Web 两种方式管理分布式数据库，两种管理方式将海量数据库实例的运维工作简化为在页面点击即可完成，极大地降低了运维工作量。
多种网络接入方式
支持 VPC 网络和基础网络，还可配置数据库外网访问。通过这些接入方式，您可从腾讯云、IDC、私有云或其他云厂商处访问云数据库，从而满足多种环境下的数据库访问需求。
支持 API
提供完善的 API 体系，您可使用 API 轻松地将云数据库与内部监控、运营系统相结合，实现贴近业务需求、完全自动化的业务运维体系。 查看 API 说明。
分布式数据库 TDSQL（TencentDB for TDSQL）是部署在腾讯云上的一种支持自动水平拆分的，Shared Nothing 架构的分布式数据库。分布式数据库即业务获取的是完整的逻辑库表，而后端会将库表均匀的拆分到多个物理分片节点。目前 TDSQL 默认部署主备架构，且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，适用于 TB 或 PB 级的海量数据库场景。
| 特点 | OLTP | OLAP |
|---|---|---|
| 主要场景 | 日常交易处理 | 统计、报表、分析 |
| 面向业务 | 面向实时交易类，如电商交易、订单 | 面向统计分析的，如 ERP、BI 等 |
| 性能消耗 | 磁盘 IO | CPU |
| 实时性 | 实时读写要求高 | 实时读写要求低 |
说明：TDSQL 是一个面向 OLTP 业务的分布式数据库。
垂直切分也就是按功能切分，这种切分方法跟业务紧密相关，实施思路也比较直接，例如“京东 JD”等电商平台，将数据按功能切分为会员数据库、商品数据库、交易数据库、物流数据库等。
有时候，垂直拆分并不能彻底解决压力问题，因为单台数据库服务器的负载和容量也是有限的，随着业务发展势必也会成为瓶颈，解决这些问题的常见方案就是水平切分了。水平切分是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。
说明：TDSQL 是一个支持水平拆分的分布式数据库。
Shared Nothing 架构能够做到通过简单堆叠机器，对数据和访问容量进行扩展；share anything 架构虽然也能够满足大部分用户的数据库容量需求，但是本质上是小型机 + 共享存储，而且仍然会碰到容量和性能天花板，并且价格相对昂贵。如下图；
关系型数据库是一个二维模型，数据的切分通常就需要找到一个分片字段（shardkey）以确定拆分维度，再通过定义规则来实现数据库的拆分。
几种常见的分片键选择方案如下：
基于日期顺序。例如按年拆分，2015年一个分片，2016年一个分片。
优势：简单明了，易于查找。
劣势：当期（2016年）的热数据的服务器性能可能不足，而存储冷数据性能却闲置。
基于用户 ID 求模，将求模后字段的特定范围分散到不同库中。
优势：性能相对均衡，相同用户数据在一个库中。
劣势：可能导致数据倾斜（例如设计的是商户系统，某电子商城的一个商户数据能比几千个小商户的数据还多）。
将主键（primary key）求模，将求模后字段的特定范围分散到不同库中。
优势：性能相对均衡，不容易出现数据倾斜的问题，相同主键的数据在一个库中。
劣势：数据随机分散，某些业务逻辑可能需要跨分片 join 却不能直接支持。
在多张表分片方案前，也有几种方案：
Noshard：即不分片。
tableshard：即每张表分表时，仅根据自身情况，不考虑表间关系，随意选择分表键分表。
groupshard：即几张有关联的表，按相同的分表键进行设计，这样可以将相关的数据聚合在一台物理节点。
在分片的数据源管理方面，目前也有两种思路：
客户端模式：由业务程序模块中的配置来管理多个分片的数据源，分片的读写与数据整合在业务程序内进行。
中间件代理模式：在分片数据库前端搭建一个中间件代理，后端多个分片数据库对前端应用程序透明。
说明：当前 TDSQL 主流以自动水平拆分为基础，通过将 shardkey 求模，并通过代理网关（TProxy）按求模后值的特定范围分散到不同库中的分片方案。
面对互联网类业务百万级以上的用户量，单机数据库由于硬件和软件的限制，数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。
即使将物理硬件升级到几十颗 CPU，容量做到几十TB，然而 DDL、DML 的性能都会出现大幅下滑；况且，随着业务快速增长，可能您刚买的一台高端设备，还没用上几个月就会因性能不足而需要更换。
应用层分片将业务逻辑和数据库逻辑高度耦合，给当前业务快速迭代带来极大的开发工作量。而基于 TDSQL 透明自动拆分的方案，开发者只需要在第一次接入时修改代码，后续迭代无需过多关注数据库逻辑，可以极大减少开发工作量。
选择开源或 NoSQL 产品也能够解决数据库瓶颈，而且这些产品免费或者费用相对较低。但您可能需要注意开源方案或 NoSQL 的以下问题：
产品 bug 修复取决于社区进度，若遭遇严重 bug 您是否可以等待。
您的团队是否有熟悉并能持续维护该产品的人，且不会因为人事变动而影响项目。
关联系统是否做好准备。
您的业务重心是什么，投入资源来保障开源产品的资源管控和生命周期管理、分布式逻辑、高可用部署和切换、容灾备份、自助运维、疑难排查等是否是您的业务指标。
单分片最大性能可达超24万 QPS，整个实例性能随着分片数量增加线性扩展。
不存在中间件 + 数据库方案中的性能瓶颈，即 TProxy 也可以做线性扩展。
强同步性能与异步同步相当，能让您在数据不丢失的情况下，也拥有较高的性能。
经过腾讯各类核心业务10余年大规模产品的验证，包括社交、电商、支付、音视频等。
提供完善的数据备份、容灾、一键升级等功能。
完善的监控和报警体系，大部分故障都通过自动化程序处理恢复。
支持分布式数据库领域领先功能，如分布式多表 JOIN、小表广播、分布式事务、SQL 透传等。
除少量语法与原生 MySQL、MariaDB 不同外，使用起来如使用单机数据库，分片过程对业务透明且无需干预。
兼容 MySQL 协议（支持 MySQL、MariaDB 等内核）。
支持 Web 控制台，读写分离能力、专有运维管理指令等。
电商、金融、O2O、社交应用、零售、SaaS 服务提供商，普遍存在用户基数大（百万级或以上）、营销活动频繁、核心交易系统数据库响应日益变慢的问题，制约业务发展。
TDSQL 提供线性水平扩展能力，能够实时提升数据库处理能力，提高访问效率，峰值 QPS 达1500万+，轻松应对高并发的实时交易场景。微信支付、财付通、腾讯充值等都是使用的 TDSQL 架构的数据库。
在工业监控和远程控制、智慧城市的延展、智能家居、车联网等物联网场景下，传感监控设备多、采样率高、数据规模大。通常存储一年的数据就可以达到 PB 级甚至 EB，而传统基于 x86 服务器架构和开源数据库的方案根本无法存储和使用如此大的数据量。
TDSQL 提供的容量水平扩展能力，以及 tokudb 等存储引擎的压缩能力，可以有效的帮助用户以低成本（相对于共享存储方案）存储海量数据。
一般来说，作为云服务平台，存在大量的图片、文档、视频数据，数据量都在亿级 - 万亿级，服务平台通常需要将这些文件的索引存入数据库，并在索引层面提供实时的新增、修改、读取、删除操作。
由于服务平台承载着其他客户的访问，服务质量和性能要求极高。传统数据库无法支撑如此规模的访问和使用，TDSQL 超高性能和扩展能力并配合强同步能力，有效的保证平台服务质量和数据一致性。
政务机构、大型企业、银行等行业为了支持大规模数据存储和高并发数据库访问，对小型机和高端存储依赖极强。而互联网企业通过低成本 x86 服务器和开源软件即可做到商业数据库相同甚至更高的能力。
TDSQL 适用于诸如国家级或省级业务系统汇聚、大型企业电商和渠道平台、银行的互联网业务和交易系统等场景。
水平拆分方案，实际上是分布式数据库的基础原理，他的每个节点都参与计算和数据存储，且每个节点都仅计算和存储一部分数据。因此，无论业务的规模如何增长，我们仅需要在分布式集群中不断的添加设备，用新设备去应对增长的计算和存储需要即可。
水平切分（分表）：是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，形成“独立”的数据库“分片”。多个分片共同组成一个逻辑完整的数据库实例。
常规的单机数据库中，一张完整的表仅在一个物理存储设备上读写。
分布式数据库中，根据在建表时设定的分表键，系统将根据不同分表键自动分布到不同的物理分片中，但逻辑上仍然是一张完整的表。
在 TDSQL 中，数据的切分通常就需要找到一个分表键（shardkey）以确定拆分维度，再采用某个字段求模（HASH）的方案进行分表，而计算 HASH 的某个字段就是 shardkey。 HASH 算法能够基本保证数据相对均匀地分散在不同的物理设备中。
业务写入一行数据。
网关通过对 shardkey 进行 hash。
不同的 hash 值范围对应不同的分片（调度系统预先分片的算法决定）。
数据根据分片算法，将数据存入实际对应的分片中。
数据聚合：如果一个查询 SQL 语句的数据涉及到多个分表，此时 SQL 会被路由到多个分表执行，TDSQL 会将各个分表返回的数据按照原始 SQL 语义进行合并，并将最终结果返回给用户。
注意：在执行 SELECT 语句时，建议您带上 shardkey 字段，否则会导致数据需要全表扫描然后网关才对执行结果进行聚合。全表扫描响应较慢，对性能影响很大。
业务发送 select 请求中含有 shardkey 时，网关通过对 shardkey 进行 hash。
不同的 hash 值范围对应不同的分片。
数据根据分片算法，将数据从对应的分片中取出。
业务发送 select 请求没有 shardkey 时，将请求发往所有分片。
各个分片查询自身内容，发回 Proxy 。
Proxy 根据 SQL 规则，对数据进行聚合，再答复给网关。
当处理大数据量读请求的压力大、要求高时，可以通过读写分离功能将读的压力分布到各个从节点上。
TDSQL 默认支持读写分离功能，架构中的每个从机都能支持只读能力，如果配置有多个从机，将由网关集群（TProxy）自动分配到低负载从机上，以支撑大型应用程序的读取流量。
读写分离基本的原理是让主节点（Master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），让从节点（Slave）处理查询操作（SELECT）。
只读帐号是一类仅有读权限的帐号，默认从数据库集群中的从机（或只读实例）中读取数据。
通过只读帐号，对读请求自动发送到备机，并返回结果。
在只读帐号设置选项中，您可以设置【只读请求分配策略】，定义在备机故障（或延迟较大）时的“读“策略。
选择【主机】则备机延迟超时时从主机读取。
选择【直接报错】则备机延迟超时时报错。
选择【只从备机读取】则忽略延迟参数，一直从备机读取（一般用于拉取 binlog 同步）。
定义【只读备机延迟参数】，定义数据同步延迟时间，并与【只读请求分配策略】中的【主机】及【直接报错】两种策略配合使用。
在每条需要从机“读”的 SQL 前，增加/*slave*/ 字段，并且 mysql 后面增加 -c 参数来解析注释mysql -c -e "/*slave*/sql"，即可自动将“读”请求分配到从机，代码示例如下：
//主机读//select * from emp order by sal，deptno desc；
//从机读///*slave*/ select * from emp order by sal，deptno desc；
注意：
该功能仅支持从机读（select），不支持其他操作，非 select 语句将失败。
mysql 后面要增加 -c 参数来解析注释。
/*slave*/必须为小写，语句前后无空格。
从机出现异常而影响到 MAR（强同步）机制时，从机读操作将自动切换回主机。
TDSQL 支持在线实时扩容，扩容方式分为新增分片和现有分片扩容两种方式，整个扩容过程对业务完全透明，无需业务停机。扩容时仅部分分片存在秒级的只读或中断，整个集群不会受影响。
TDSQL 主要是采用自研的自动再均衡技术保证自动化的扩容和稳定。
控制台单击扩容后，系统根据负载和容量计算出 A 节点（实际上可能影响多个节点）存在瓶颈。
根据新加 G 节点配置，将 A 节点部分数据搬迁（从备机）到 G 节点。
数据完全同步后，A、G 节点校验数据库，存在一至几十秒的只读，但整个服务不会停止。
调度通知 proxy 切换路由。
基于现有分片的扩容相当于更换了一块更大容量的物理分片。
说明：基于现有分片的扩容没有增加分片，不会改变划分分片的逻辑规则和分片数量。
按需要升级的配置分配一个新的物理分片（以下简称新分片）。
将需要升级的物理分片（以下简称老分片）的数据、配置等同步数据到新分片中。
同步数据完成后，在腾讯云网关做路由切换，切换到新分片继续使用。
传统数据复制方式有如下三种：
异步复制：应用发起更新请求，主节点（Master） 完成相应操作后立即响应应用，Master 向从节点（Slave）异步复制数据。
强同步复制：应用发起更新请求，Master 完成操作后向 Slave 复制数据，Slave 接收到数据后向 Master 返回成功信息，Master 接到 Slave 的反馈后再应答给应用。Master 向 Slave 复制数据是同步进行的。
半同步复制：正常情况下数据复制方式采用强同步复制方式，当 Master 向 Slave 复制数据出现异常的时候（Slave 不可用或者双节点间的网络异常）退化成异步复制。当异常恢复后，异步复制会恢复成强同步复制。
当 Master 或 Slave 不可用时，以上三种传统数据复制方式均有几率引起数据不一致。
数据库作为系统数据存储和服务的核心能力，其可用性要求非常高。在生产系统中，通常都需要用高可用方案来保证系统不间断运行，而数据同步技术是数据库高可用方案的基础。
MAR 强同步复制方案是腾讯自主研发的基于 MySQL 协议的异步多线程强同步复制方案，只有当备机数据完全同步（日志）后，才由主机给予应用事务应答，保障数据正确安全。
原理示意图如下：
MAR 强同步方案在性能上优于其他主流同步方案，具体数据详情可参见 强同步性能对比数据。主要特点如下：
一致性的同步复制，保证节点间数据强一致性。
对业务层面完全透明，业务层面无需做读写分离或同步强化工作。
将串行同步线程异步化，引入线程池能力，大幅度提高性能。
支持集群架构。
支持自动成员控制，故障节点自动从集群中移除。
支持自动节点加入，无需人工干预。
每个节点都包含完整的数据副本，可以随时切换。
无需共享存储设备。
| 实例架构 | 定义 | 节点 | 特点 |
|---|---|---|---|
| 标准版（一主一从） | 每个分片提供主从双活部署的高可用架构 | 两个节点：一个 Master 节点，一个 Slave 节点 |
|
| 标准版（一主二从） | 每个分片提供主从多活部署的高可用架构 | 三个节点：一个 Master 节点，两个 Slave 节点 | |
| 金融定制版（一主一从） | 每个分片提供主从多活部署的高可用架构 | 两个节点：一个 Master 节点，一个 Slave 节点 |
|
| 金融定制版（一主二从） | 每个分片提供主从多活部署的高可用架构 | 三个节点：一个 Master 节点，两个 Slave 节点 |
公有云：
腾讯云目前提供多个可选地域，TDSQL 已支持在中国公有云机房部署。
金融云：
针对金融行业监管要求定制的合规专区，具有高安全，高隔离性的特点；已认证通过的金融行业客户可提工单申请使用专区，详见 金融专区介绍
使用 TDSQL 做功能性测试，且对性能没有特别要求：2个分片，每个分片配置为：内存/磁盘：2GB/25GB。
业务发展初期，总数据规模较小但增长快的选型：2个分片，每个分片配置为：内存/磁盘：16GB/200GB。
业务发展稳定，根据业务实际情况选型：4个分片，每个分片配置等于：当前业务峰值 * 增长率 / 4。
更多关于实例规格的详情，请参见 TDSQL 实例及分片配置。
TDSQL 目前版本不能通过命令行进行用户权限相关的设置，需要登录腾讯云管理中心进行网页操作。
TDSQL 目前版本对自定义函数、视图、触发器、外键、子查询等特性暂不支持。
对 MySQL 的语法兼容详情，请参见 使用限制。
使用分表时，在执行操作 select 时最好带上分表键（shardkey），路由将自动跳转到对应分片，效率较高。若没带上亦可执行，但系统将自动全表扫描，效率较低。
使用分表时，在执行操作 insert/replace 或 delete/update 时必须包含 shardkey，否则会拒绝执行操作。执行操作 insert/replace 需要指定 shardkey，指明将数据插入的物理分片位置。执行操作 delete/update 需要指明 shardkey，作为验证，避免误删。
分表键是在水平拆分过程中用于生成拆分规则的数据表字段，必须在建表时就指定好。TDSQL 建议分表键尽可能找到数据表中的数据在业务逻辑上的主体，并确定大部分（或核心的）数据库操作都围绕这个主体的数据进行，方可使用该主体对应的字段作为拆分键，进行分表（该分表方案名为 Group-Shard）。如下图所示：
按组分表方案可以确保不同分表的某些关联数据和复杂的业务逻辑运算，可以聚合到一个物理分片内。例如，某电商平台订单表和用户表都是基于用户维度（UserID）拆分，平台就很容易通过联合查询（不会存在跨节点 join，或分布式事务）快速计算某个用户近期产生了多少订单。
一些典型选择拆分键的应用场景如下：
面向用户的互联网应用，是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可使用用户对应的字段作为拆分键。
电商应用或 O2O 应用，是围绕卖家/买家维度来进行各种操作，那么业务逻辑主体就是卖家/买家，可使用卖家/买家对应的字段作为拆分键。但请注意，某些情况下几个超大卖家占到绝大多数交易额，会导致某几个分片的负载和压力明显高于其他分片。
游戏类的应用，是围绕玩家维度来做各种操作，那么业务逻辑主体就是玩家，可使用玩家对应的字段作为拆分键。
物联网方面的应用，则是基于物联信息进行操作，那么业务逻辑主体就是传感器/ SIM 卡，可使用传感器、独立设备、SIM 卡的 IMEI 作为对应的字段作为拆分键。
税务/工商类/社保的应用，主要是基于纳税人/法定代表人/居民的信息来开展前台业务，那么业务逻辑主体就是纳税人/法定代表人，可使用纳税人/法定代表人对应的字段作为拆分键。
以此类推，其它类型的应用场景，大多也能找到合适的业务逻辑主体作为拆分键的选择。但需要注意在选择分表键时有一定限制，详情参见 分表键选择限制。
一旦选择好分区字段（shardkey），就不能轻易更改。若需要修改一个表的分区字段，只能新建一个表。
若需要修改一个分表某一行中的 shardkey 值，需要先 insert 再 delete。直接操作 update 不能修改分区字段的值。
TDSQL 目前只支持单个分表键下的 JOIN 和 TRANSACTION，以及跨节点的 TRANSACTION，跨节点的 JOIN 暂不支持。