今年在公司重构（写）了一个老项目，踩了无数的坑。

        中间好几次遇到问题，甚至感觉项目可能要失败了，好在最后终于成功上线了。

        虽然被坑的不要不要的，但也从中领悟到了不少东西，在这里记录一下，顺便分享给大家乐呵乐呵。

        先简单介绍下项目，一个面向C端用户的服务，主要提供包括动态、评论、圈子、好友、关注、Feed等常见的社区功能，另外还有其他一些个性化的功能。

        日活比较高，整个服务QPS上万。高频业务，单个接口QPS上千。单项业务数据量过亿，比如评论。

图1.qps监控图

        在上述高并发、海量数据的情况下，整个系统设计时需要注意的坑，和我总结的一些经验：

数据库层面

MySQL分库分表

因为是重写整个项目，包括重新设计底层数据库，必然要考虑到分库分表。

最初在网上参考了一些分库分表的原则，实际操作中，发现大部分资料都有些缥缈。

如果是简单的应用怎么分表，甚至不分都可以。所以这些原则你也不能说它是错的，但在你最需要参考的时候，这些原则往往不够深入。

分享下我个人总结的一些经验：

先说分库

分库的主要目标，应该是缓解主库（Master）的压力。

绝大部分服务都是读多写少，在读写分离，1主1备N从的情况下，即便为了保证一致性，部分读请求路由到主库，主库压力依旧很低。

通过监控服务的写请求量和数据库服务器的CPU压力等性能指标，只要主库压力不大，就没必要分库。读库如果压力大，直接加从库实例即可。

一种极端的情况，就是分表数量过多了，一个库里表数量递增，成万上亿了，那还是分库的好。

还有一点，从运维的角度考虑，单库冷备，数据不应该超过500GB。如果单库数据量达到1个TB，运维也不好备份，为了正常备份也要分库。

 图2.数据库监控图（图中蓝色线条代表主库，基本上是趴着不动躺平的）

再说分表

在请求量不大 或 数据量不大的情况下，分不分表都无所谓。

考虑mysql的性能、树的深度等，可以简单的认为单表500W左右即可。

但实际中往往需要结合具体的业务设计和查询场景。

比如，1张几千万数据量的订单表，如果业务上，只需要根据主键或唯一索引，每次查询一条记录，那么不分表也是完全可行的。

但有时出于运维需要，分表会更方便一些，比如研发人员可能会想手写一些SQL上去进行一些范围查询，为排查问题提供一些方便。（这里说的方便是指相对单表几千万，如果查询字段没有索引，范围查询基本不可用。当然从操作步骤上看，肯定比查1个表繁琐了）

特别需要注意的是，如果一项业务数据需要高频的用到 count语句查询总数 或  order by进行排序，我建议分的表越多越好，管他3721先分1000张表再说。

多分表的好处就是，只要表中的数据量足够少，即便你索引设计的不好，甚至查询完全不走索引，也不容易产生慢查询。哈哈哈！

小结：这次重构就被老系统的1000张表给坑了，因为每张表只有几万条数据，我觉得太浪费了,  想当然的缩到了20张表。

           但又没有很好的去分析查询场景，设计索引。导致上线时，只放了1%的量，就崩了，看监控全部都是慢查询。

           当然，最终我是通过优化索引来解决慢查询，而不是加分表数量。但在有些情况下，这也是一种思路。

MySQL索引、字段设计

之前自己设计表，总喜欢加些固定字段，比如create_time, create_user, is_delete等，因为运维方便。

重构了这个系统之后发现，在高并发海量数据的情况下，性能是首要问题，有时候多加这些字段反而成了负担。（当然，大部分情况下，create_time还是必要的）

字段能少则少，名字能短则短，类型能用tinyint就不要用int。