• 
  O MySQL pode razoavelmente realizar consultas em bilhões de linhas? -- O MySQL pode 'lidar' com bilhões de linhas. "Razoavelmente" depende das consultas; vamos vê-los.
  
• 
  O InnoDB (MySQL 5.5.8) é a escolha certa para vários bilhões de linhas? -- 5.7 tem algumas melhorias, mas 5.5 é muito bom, apesar de ser quase 6 8 anos e à beira de não sendo mais suportado.
  
• 
  Melhor armazenamento de dados para bilhões de linhas - Se você quer dizer 'Engine', então InnoDB.
  
• 
  Quão grande um banco de dados MySQL pode chegar antes que o desempenho comece a se degradar -- Novamente, isso depende das consultas. Posso mostrar-lhe uma tabela de 1K linhas que irá derreter; Trabalhei com tabelas de bilhões de linhas que zumbem.
  
• 
  Por que o MySQL pode ser lento com tabelas grandes? -- varreduras de intervalo levam a E/S, que é a parte lenta.
  
• 
  O MySQL pode lidar com tabelas que conterão cerca de 300 milhões de registros? -- novamente, sim. O limite é algo em torno de um trilhão de linhas.
  
• 
  (para tabelas InnoDB que é o meu caso) aumentando o innodb_buffer_pool_size (por exemplo, até 80% da RAM). Além disso, encontrei algumas outras configurações de ajuste de desempenho do MySQL aqui no blog Percona - sim
  
• 
  ter índices adequados na tabela (usando EXPLAIN em consultas) -- bem, vamos vê-los. Há muitos erros que podem ser cometidos neste crítico área.
  
• 
  particionando a tabela -- "Particionar não é uma panacéia!" Falo disso em meu blog
  
• 
  MySQL Sharding - Atualmente isso é DIY
  
• 
  Clustering MySQL -- Atualmente a melhor resposta é alguma opção baseada em Galera (PXC, MariaDB 10, DIY w/Oracle). A "Replicação de Grupo" da Oracle é um concorrente viável.
  
• 
  O particionamento não suporta FOREIGN KEY ou "global" UNIQUE .
  
• 
  UUIDs, na escala que você está falando, não apenas desacelerarão o sistema, mas na verdade o matarão. UUIDs tipo 1 pode ser uma solução.
  
• 
  Velocidade de inserção e construção de índice -- Existem muitas variações para dar uma única resposta. Vamos ver sua tentativa CREATE TABLE e como você pretende alimentar os dados.
  
• 
  Muitas junções - "Normalize, mas não normalize demais". Em particular, não normalize datetimes ou floats ou outros valores "contínuos".
  
• 
  Crie tabelas de resumo
  
• 
  2,3 milhões de transações por dia -- Se forem 2,3 milhões de inserções (30/s), então não há muito problema de desempenho. Se for mais complexo, pode ser necessário RAID, SSD, lote, etc.
  
• 
  lidar com esse volume de dados -- Se a maior parte da atividade estiver com as linhas "recentes", o buffer_pool fará o 'cache' da atividade, evitando assim a E/S. Se a atividade for "aleatória", o MySQL (ou qualquer um else) terá problemas de E/S.
  
• 
  Encolher os tipos de dados ajuda em uma tabela como a sua. Duvido que você precise de 4 bytes para especificar fuel_type . Existem várias abordagens de 1 byte.