用户存有海量数据的表应该按照数据规模进行拆解，表的数据将拆解成多个数据分区独立存储，通常的设计原则是：
主键（Primary Key）
单实例数据库不要求表一定要有主键，但是对于分布式数据库，主键则是必须的，以保证一行数据是全局唯一的，避免迁移过程出现问题。如果用户没有特殊的性能需求或业务耦合问题，则应将主键设计为无意义的整数值或者自增的数值。
分区键（Partition Key）
用户的分区表必须按照一种维度进行数据划分，用户在按照分区键维度进行查询时，就能做到线性性能增长，分区键通常有如下选择方法：
- 按业务ID切分，如用户ID、商品ID等，适合每个业务ID的数据较均匀且查询简单的场景；
- 按多个业务维度切分，用户建立多张表存入相同数据，但是每张表按照不同业务维度切分，查询时根据过滤条件选择不同的表，以提升访问性能，适合查询复杂且单一切分方式不能满足需求的场景；
- 按自增主键切分，若表分区方式为分区表，主键为自增，且该字段同时为分区键，则此时写入为随机分区，按照非主键查询时需要读取所有分区，适合有数据偏斜且写多读少的场景；
- 至少保证在分区键上有一个索引。
业务列
其它的列统归为此类，仅用于存储数据，通常要考虑：
- 列不宜过长，够用即可，临时加载的长列会消耗额外内存，影响查询性能；
- 准确定义列的类型，避免查询时使用的类型与表定义的类型不匹配，从而进行类型转换，以致不能正确使用索引；
- 优先使用timestamp类型代替其它时间日期类型，且使用时严格遵守MySQL的时间日期格式。
主键索引
若主键是自增类型，则主键索引不会对整体性能优化有改善，若主键与业务相关，则可以对最频繁使用的SQL语句的查询条件建立主键索引，这样可以提升性能。
辅助索引
其他情况下，如果不能通过将SQL语句拆解成单分区的，且不能利用主键进行索引优化时，需要对全部分区进行扫描，此时可以对这部分全分区扫描的语句的查询条件建立索引，使得在每个分区上进行访问时，仍然能取得较高的性能
说明 HybridDB for MySQL目前暂不支持广播表（广播表的数据在每个数据分区均有相同副本，用于与分区表进行join）。