https://cloud.tencent.com/developer/article/1999970
个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~
本文是“为什么我建议”系列第三篇，本系列中会针对一些在高并发场景下，我对于组内后台开发的一些开发建议以及开发规范的要求进行说明和分析解读，相信能让各位在面对高并发业务的时候避开一些坑。 往期回顾：
- 为什么我建议在复杂但是性能关键的表上所有查询都加上 force index
- 为什么我建议线上高并发量的日志输出的时候不能带有代码位置
一般现在对于业务要查询的数据量以及要保持的并发量高于一定配置的单实例 MySQL 的极限的情况，都会采取分库分表的方案解决。当然，现在也有很多 new SQL 的分布式数据库的解决方案，如果你用的是 MySQL，那么你可以考虑 TiDB（实现了 MySQL 协议，兼容 MySQL 客户端以及 SQL 语句）。如果你用的是的 PgSQL，那么你可以考虑使用 YugaByteDB（实现了 PgSQL 协议，兼容 PgSQL 客户端以及 SQL 语句），他们目前都有自己的云部署解决方案，你可以试试：
- TiDB Cloud
- YugaByte Cloud
但是对于传统分库分表的项目，底层的数据库还是基于 MySQL 以及 PgSQL 这样的传统关系型数据库。一般在业务刚开始的时候，会考虑按照某个分片键多分一些表，例如订单表，我们估计用户直接要查的订单记录是最近一年内的。如果是一年前的，提供其他入口去查，这时候查的就不是有业务数据库了，而是归档数据库，例如 HBase 这样的。例如我们估计一年内用户订单，最多不会超过 10 亿，更新的并发 TPS （非查询 QPS）不会超过 10 万/s。那么我们可以考虑分成 64 张表（个数最好是 2^n，因为 2^n 取余数 = 对 2^n - 1 取与运算，减少分片键运算量）。然后我们还会定时的归档掉一年前的数据，使用类似于 delete from table 这样的语句进行“彻底删除”（注意这里是引号的删除）。这样保证业务表的数据量级一直维持在
然而，日久天长以后，会发现，某些带分片键（这里就是用户 id）的普通查询，也会有些慢，有些走错本地索引。
查询越来越慢的原因
例如这个 SQL：
select * from t_pay_record
WHERE
((user_id = 'user_id1' AND is_del = 0
))
ORDER BYid DESC LIMIT 20这个表的分片键就是 user_id
一方面，正如我在“为什么我建议在复杂但是性能关键的表上所有查询都加上 force index”中说的，数据量可能有些超出我们的预期，导致某些分片表大于一定界限，导致 MySQL 对于索引的随机采样越来越不准，由于统计数据不是实时更新，而是更新的行数超过一定比例才会开始更新。并且统计数据不是全量统计，是抽样统计。所以在表的数据量很大的时候，这个统计数据很难非常准确。依靠表本身自动刷新数据机制，参数比较难以调整（主要是 STATS_SAMPLE_PAGES 这个参数，STATS_PERSISTENT 我们一般不会改，我们不会能接受在内存中保存，这样万一数据库重启，表就要重新分析，这样减慢启动时间，STATS_AUTO_RECALC 我们也不会关闭，这样会导致优化器分析的越来越不准确），很难预测出到底调整到什么数值最合适。并且业务的增长，用户的行为导致的数据的倾斜，也是很难预测的。通过 Alter Table 修改某个表的 STATS_SAMPLE_PAGES 的时候，会导致和 Analyze 这个 Table 一样的效果，会在表上加读锁，会阻塞表上的更新以及事务。所以不能在这种在线业务关键表上面使用。所以最好一开始就能估计出大表的量级，但是这个很难。
所以，我们考虑对于数据量比较大的表，最好能提前通过分库分表控制每个表的数据量，但是业务增长与产品需求都是不断在迭代并且变复杂的。很难保证不会出现大并且索引比较复杂的表。这种情况下需要我们，在适当调高 STATS_SAMPLE_PAGES 的前提下，对于一些用户触发的关键查询 SQL，使用 force index 引导它走正确的索引。
但是，有时候即使索引走对了，查询依然有点慢。具体去看这个 SQL 扫描的数据行数的时候，发现并没有很多。
+----+-------------+--------------+------------+-------+-----------------------------------------------------------------------------------------+-------------+---------+------+-------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------------+------------+-------+-----------------------------------------------------------------------------------------+-------------+---------+------+-------+----------+--------