在项目初期，我们部署了三个数据库A、B、C，此时数据库的规模可以满足我们的业务需求。为了将数据做到平均分配，我们在Service服务层使用uid%3进行取模分片，从而将数据平均分配到三个数据库中。

会员系统是一种基础系统，跟公司所有业务线的下单主流程密切相关。如果会员系统出故障，会导致用户无法下单，影响范围是全公司所有业务线。所以，会员系统必须保证高性能、高可用，提供稳定、高效的基础服务。

有个项目的数据量高达五千万，但是因为报表那块数据不太准确，业务库和报表库又是跨库操作，所以并不能使用 SQL 来进行同步。当时的打算是通过 mysqldump 或者存储的方式来进行同步，但是尝试后发现这些方案都不切实际：

毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱么日常遇到的80%甚至90%的性能问题。

作为在后端圈开车的多年老司机，是不是经常听到过，“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要考虑数据迁移了”，“你这个表数据都马上要到 2000w 了，难怪查询速度慢”

导读 文章首发于作者微信公众号【码猿技术专栏】Mysql性能优化：为什么你的count(*)这么慢？ 在开发中一定会用到统计一张表的行数，比如一个交易系统，老板会让你每天生成一个报表，这些统计信息少不了sql中的count函数。 但是随着记录越来越多，查询的速度会越来越慢，为什么会这样呢？Mysql内部到底是怎么处理的？ 今...