共计 1481 个字符，预计需要花费 4 分钟才能阅读完成。
如何抉择实例规格?
应用 TDSQL MySQL 版 做功能性测试，且对性能没有特地要求：2 个分片，每个分片配置为：内存 / 磁盘：2GB/25GB。
业务倒退初期，总数据规模较小但增长快的选型：2 个分片，每个分片配置为：内存 / 磁盘：16GB/200GB。
业务倒退稳固，依据业务理论状况选型：4 个分片，每个分片配置等于：以后业务峰值 * 增长率 / 4。
更多对于实例规格，请参见 TDSQL MySQL 版 实例及分片配置。
TDSQL MySQL 版 与 传统 MySQL 语法之间的区别有哪些？
TDSQL MySQL 版 目前版本不能通过命令行进行用户权限相干的设置，须要登录 控制台 进行操作。
TDSQL MySQL 版 目前版本暂不反对自定义函数、视图、触发器、外键等个性。
对 MySQL 的语法兼容详情，请参见 应用限度。
分表键有何作用？
应用分表，在执行操作 select 时，倡议带上 shardkey 字段，proxy 依据该字段的 hash 值间接将 SQL 申请路由至对应的数据库实例进行解决；否则就须要发送给集群中所有的数据库实例执行，而后 proxy 依据数据库返回的后果集进行聚合，影响执行效率。
应用分表，在执行操作 insert/replace 时，字段必须蕴含 shardkey，否则会拒绝执行该 SQL，因为 proxy 不晓得将该 SQL 发往哪个后端数据库。
应用分表，在执行操作 delete/update 时，为平安思考，执行该类 SQL 时，必须带有 where 条件，否则拒绝执行该 SQL 命令。
如何抉择分表键？
分表键是在程度拆分过程中用于生成拆分规定的数据表字段，必须在建表时指定好。TDSQL MySQL 版 倡议分表键尽可能找到数据表中的数据在业务逻辑上的主体，并确定大部分（或外围的）数据库操作都围绕这个主体的数据进行，方可应用该主体对应的字段作为拆分键，进行分表（该分表计划名为 Group-Shard）。如下图所示：
按组分表计划能够确保不同分表的某些关联数据和简单的业务逻辑运算，能够聚合到一个物理分片内。例如，某电商平台订单表和用户表都是基于用户维度（UserID）拆分，平台就很容易通过联结查问（不会存在跨节点 join，或分布式事务）疾速计算某个用户近期产生了多少订单。
一些典型抉择拆分键的利用场景如下：
面向用户的互联网利用，是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可应用用户对应的字段作为拆分键。
电商利用或 O2O 利用，是围绕卖家 / 买家维度来进行各种操作，那么业务逻辑主体就是卖家 / 买家，可应用卖家 / 买家对应的字段作为拆分键。但请留神，某些状况下几个超大卖家占到绝大多数交易额，会导致某几个分片的负载和压力显著高于其余分片。
游戏类的利用，是围绕玩家维度来做各种操作，那么业务逻辑主体就是玩家，可应用玩家对应的字段作为拆分键。
物联网方面的利用，则是基于物联信息进行操作，那么业务逻辑主体就是传感器 /SIM 卡，可应用传感器、独立设施、SIM 卡的 IMEI 作为对应的字段作为拆分键。
税务 / 工商类 / 社保的利用，次要是基于纳税人 / 法定代表人 / 居民的信息来发展前台业务，那么业务逻辑主体就是纳税人 / 法定代表人，可应用纳税人 / 法定代表人对应的字段作为拆分键。
以此类推，其它类型的利用场景，大多也能找到适合的业务逻辑主体作为拆分键的抉择。但须要留神在抉择分表键时有肯定限度，详情参见 分表键抉择限度。
分表键是否更换？
一旦抉择好分区字段（shardkey），就不能轻易更改。若须要批改一个表的分区字段，只能新建一个表。
若须要批改一个分表某一行中的 shardkey 值，须要先 insert 再 delete。间接操作 update 不能批改分区字段的值。
