以下内容来自于 percona 2021/9/27 的
作为Percona的客户技术经理,面对众多的客户，虽然客户来自于不同的行业，但主要他们的诉求比较一致，那一堆的数据该怎么办？
虽然MYSQL 在处理大量数据的问题并不是一个新的挑战，但实际上并没有特别好的方式来回答客户的这些问题。 很明显每一个应用都是不同的，接下来我想讨论的是关于咱们更好的处理这些数据基于数据湖的思维方式。
1 KEEP MYSQL Instance Small
第一件要强调的事情就是MYSQL的实例一定要小，尽可能的小，这是一个非常普遍的问题，我们经常面对一些关于到底MYSQL 应该处理多大的数据尺寸的问题，曾经有人问，我可以在 MYSQL 中处理 20T 的数据吗？ 这显然是不能的，对我确认不能。
实际上MYSQL是可以存储大量的数据，但你不能把单独仅仅只考虑MYSQL的存储功能，因为一个数据库系统基本功能包含 存储，吸入和读取数据。随着数据的不断增长，数据读取会随着数据的增加而变得越来越困难。同时你还要考虑你的内存是否能处理这么多的数据。你要保证数据的读取和写入足够快，这是一个值得深思的问题，到底多大的尺寸的数据适合你的数据库系统，当然你也别忘记在你保证了上面的问题后，你存储大佬数据的时是否需要备份，或者对表进行ddl的操作，20T 你将挑战的是你的I/O。
实际上一些大型的电商将独立的MYSQL实例控制在 2-3T的标准，这样你可以获得一些
1 可控制的备份时间，DDL时间
2 普通的硬件还可以支持你的系统
3 并行加载数据的可行性
如果我们在能控制整体单体INSTANCE的大小的时候，这样的情况下，你整体的系统是可以被进行上面提出的操作，如备份，恢复，DDL操作等等，所以当一个数据库备份很慢的情况下，那不用问你遇到了硬件的瓶颈，如果你没有遇到这样的问题，说明你的IT 部分运营是成功的。 所以考虑一个INSTANCE的大小还要考虑 RTO的影响，你可以多快的恢复你的数据库。
2 Store Less Data
上面我们已经知道如果一个INSTANCE过大，你将遇到的挑战是什么了，下面我们就得想想怎么将单体数据库降低的问题了。
1 优化数据类型
（这个我不大想翻译，这是最基本的在设计应用系统中需要考虑的，但大多数企业基本上没做这个事情）
2 重新审视索引的膨胀 （大小）
1 尽量不要使用联合主键
2 去除冗余的索引
3 避免将主键设置成 varchar 类型 （当然很多企业还是这么干的）
3 清理无用的数据
1 对无用的数据进行删除
2 或者归档
（括号的话不是翻译，是自己写的，根据这么多年的工作经验，很多应用设计的时候都不考虑这个问题，尤其业务逻辑设计的时候，所以到了数据量非常大的时候，在集中的进行清理和归档，一般都是不撞南墙不回头）
以上的一些提示，有助于延迟你使用一些“特殊”高级技术的时间，当然在做完上面的这些事情后，数据库的尺寸还是很大那么我们就需要
Horizontal Sharding
对水平拆分是处理MYSQL大量数据的一种方式，当上面所有的操作都无效的情况下， 通过水平拆分将这些数据平均分配到不同的MYSQL 实例中。不幸的是，说起来容易做起来难。虽然MySQL有一些工具和选项(如Vitess)，但通常最好和最灵活的方法是直接将这种分片逻辑构建到应用程序中。分片可以是静态的(例如键模)，也可以是动态的(通过字典查找)，或者两者的混合方法。
说完这些，下面还需要考虑
4 Sharding Considerations
关于水平分割的一些思路，首先需要考虑的是选择有效的水平分割键，sharding key，如果选错了，那么很肯能你的数据分布不均匀，到不到平衡数据的要求，这就会重复上述的故事，某一个INSTANCE 变得又大又慢。
同时还不要忘记，在正确使用主键的同时，你还要明白不同的工作负载对你分片的影响，在数据分布到不同的分片后，单独在一个分片中获取数据是简单的，然后如果要去获取一些聚合型的数据，这就对这个分布式系统进行挑战，业务的负载需要重新被设计。
（广告部分忽略），所以每个应用都有自己的独特性，切记不要在数据增大时，仅仅就会扩展磁盘存储空间来解决问题。
注：原文地址 https://www.percona.com/blog/horizontal-scalability-for-mysql/
