共计 659 个字符,预计需要花费 2 分钟才能阅读完成。
在 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 的负载太大。
除非凡状况外,倡议在分布式实例中尽量都应用分表。
正文完