在我的工作中，我们使用数据库（主要是MySQL 5.7.2；这是我无法更改的）。通常的任务是在价值数百万行的数据集上编写复杂的查询。它的完成方式是通过相互建立的MySQL查询流（每个查询都是一个临时表；下一个临时表则建立在先前的表上，依此类推）。由于涉及多列联接的行数以百万计，因此使用alter table语句对这些临时表执行索引。
现在，当我尝试了解dplyr的用法并探索管道的功能时，对于我们解决的这类问题，这似乎是一个极好的解决方案；也就是说，查询是彼此建立的。因此，我编写了利用dplyr功能的简单脚本。我将所有查询发送回MySQL以评估最终结果（最终结果只有几百行）。因此，所有处理都将在远程MySQL服务器上完成，而无需将数以百万计的行拉到本地R实例，并且仅结果集将被本地R实例拉出。
但是，我面临着需要索引的瓶颈；由于性能问题，它是绝对必要的。如我所见，我可以在dplyr中使用copy_to函数，这使我可以添加索引。这里有两件事困扰我：
我需要在远程MySQL服务器上创建一个新表来存储copy_to结果（在大多数情况下，我们只允许使用临时表）。
即使我设法以某种方式编写了一个永久表，copy_to函数也不允许我像在MySQL中那样定义自己的索引名；而要使用的默认名称对于MySQL来说太长了（索引名称长度引发错误）。
任何与dplyr一起使用索引的建议将不胜感激。理想情况下，我想要类似下面粗体所示的内容：
Tbl1％>％filter（...）％>％mutate（...）％>％left_join（Tbl2，by（“ col1” =“ col1”，“ col2” =“ col2”）％>％ add_index（col_from_tbl1，col_from_tbl2）％>％其他操作
顺便说一句，我看到长索引名的一种解决方案是将copy_to到新表中；然后使用DBI :: dbSendQuery添加带有我选择的名称的索引；这可行。但是，索引的需求非常频繁。这使使用管道的优雅消失了，因为我需要停在管道链的中间，复制到新表中，然后使用dbSendQuery添加索引；然后再次开始使用管道。拥有清晰易读的代码的整个要点都消失了。