MySQL在实际场景应用中的问题和思路

1、分表

分为横向分表和纵向分表，横向分表直观来说即画一条水平线将大表分成若干个子表，每个子表的字段是相同的；纵向分表偏向于按照业务逻辑分表，每个子表有不同的字段。

举例来说，现有用户表：t_user，记录注册登录信息（字段有username，password等），记录个人信息（字段有realname，idcard等），记录用户订单信息（字段有order，status等）。

首先进行纵向分表，按照业务逻辑将用户表拆成三张表：注册登录信息表、个人信息表、订单表。每张表都包含UID字段，根据UID作为表的CURD条件。

纵向分表的好处是，避免大表数据稀疏。比如100人注册，完成填写个人信息有50人，但真正下单只有1个人，这样50行数据的个人信息相关字段、99行的订单信息相关字段都为空。但分表后也会使原本一条SQL即可查询到的信息要用3条SQL才能查询到，所以这里强调纵向分表需要按照业务逻辑分表，即登录接口不需要获取订单信息，订单接口也不需要验证登录信息，才会认为这种分表处理是合理的。

然后随着用户数量继续增加还会进行横向分表，如根据UID尾数将1张表分为10张表：user_base 拆成 user_base_0 ~ user_base_9，横向分表后可以有效解决单表数据量过大问题，但查询条件非UID时，应用层完成一次查询，底层需要查询10张表（union操作）。所以需要从实际业务角度出发，保证绝大多数的操作是以UID作为条件的，这样只需查询指定的一张表即可。

其他分表规则，还可能按照更新