在 SQL 应用上，分布式实例高度兼容 MySQL 的协定和语法，但因为架构的差别，对于 SQL 有肯定的限度，同时为了更好地施展分布式的劣势，倡议业务在应用时尽量参考下文的倡议。
分布式实例提供程度扩容能力，适宜海量数据的场景。具备如下性能个性：
提供了灵便的读写拆散模式
反对全局的 order by、group by、limit 操作
聚合函数反对 sum、count、avg、min、max 等
反对跨节点（set）的 join、子查问
反对预处理协定
反对全局惟一字段，反对 sequence
反对分布式事务
反对两级分区
提供特定的 SQL 查问整个集群的配置和状态
分布式实例反对三种不同类型的表：
分表：即程度拆分表，该表从业务视角是一张残缺的逻辑表，但后端依据分表键（shardkey）的 HASH 值将数据分布到不同的节点（set）中。
单表：又名 Noshard 表，无需拆分，且没有做任何非凡解决的表，目前分布式实例将该表默认寄存在第一个物理节点组（set）中。
播送表：又名小表播送技术，即设置为播送表后，该表的所有操作都将播送到所有节点（set）中，每个 set 都有该表的全量数据，罕用于业务零碎的配置表等。
留神：
在分布式实例中，如果两张表分表键相等，这意味着，两张表雷同的分表键对应的行，肯定存储于雷同的物理节点组中。这种场景通常被称为组拆分（groupshard），会极大进步业务联结查问等语句的解决效率。
因为单表默认搁置在第一个 set 上，如果在分布式实例中建设了大量的单表，则会导致第一个 set 的负载太大。
除非凡状况外，倡议在分布式实例中尽量都应用分表。