MySQL可以合理地对数十亿行执行查询吗？-MySQL可以“处理”数十亿行。“合理地”取决于查询；让我们看看他们。
InnoDB（MySQL 5.5.8）是数十亿行的正确选择吗？-5.7进行了一些改进，但是5.5很好，尽管它
已经有6年8年历史了，并且几乎不再受到支持。数十亿行的最佳数据存储-如果您指的是“ Engine”，则为InnoDB。
在性能开始下降之前，MySQL数据库能达到多大？再次，这取决于查询。我可以向您展示一个将崩溃的1K行表。我已经处理了十亿行表格。
为什么使用大表的MySQL可能会变慢？-范围扫描导致I / O，这是最慢的部分。
Mysql可以处理将容纳约3亿条记录的表吗？-再说一次。限制大约在一万亿行。
（对于我的情况是innoDB表）增加innodb_buffer_pool_size（例如，最多80％的RAM）。另外，我在percona博客中找到了其他一些MySQL性能调整设置-是的
在表上有适当的索引（对查询使用EXPLAN）-好，让我们来看一下。在此 关键 区域中可能会犯很多错误。
分区表-“分区不是万能的！” 我在 我的博客中 竖琴 __
MySQL分片-目前是DIY
MySQL集群-当前最好的答案是一些基于Galera的选项（PXC，MariaDB 10，带有Oracle的DIY）。Oracle的“组复制”是一个可行的竞争者。
分区不支持
FOREIGN KEY
或“全局”UNIQUE
。您所谈论的UUID不仅会减慢系统速度，而且实际上会杀死它。 类型1 UUID 可能是一种解决方法。
插入和建立索引的速度-太多的变化无法给出一个答案。让我们看看您的初步想法
CREATE TABLE
以及打算如何输入数据。许多联接-“规范化，但不要过度规范化”。特别是，请勿标准化日期时间或浮点数或其他“连续”值。
做 汇总表
每天230万笔交易-如果那是230万次 插入 （30 /秒），则不会有太大的性能问题。如果更复杂，则可能需要RAID，SSD，批处理等。
处理这样的数据量-如果大多数活动都与“最近”的行有关，则buffer_pool将很好地“缓存”该活动，从而避免了I / O。如果活动是“随机的”，则MySQL（或 其他任何 人）将遇到I / O问题。
缩小数据类型有助于像您这样的表。我怀疑您是否需要4个字节来指定
fuel_type
。有多种1字节方法。
