1.
一天几十万，单一天来看数据量是不大。但是，如果你的数据长期放在同一个表中，数据也不小。假设一天50万笔，一年365天就是1.8亿笔（18250万）。如果存放的时间更长，数据量则更大。从上亿笔数据中取一段日期范围（1天，或是1周），需要良好的选择性，而且如果没有其它条件，选择出的数据量也不小。
SQL执行时，如果只有日期条件，而且日期存放的又是datetime类型，这个字段可能又没有建立索引，那要执行全表扫描（table scan）才能得到几十万或几百万笔数据。成本绝对是高。
建议：
1）查看查询计划，看是否是全表扫描。
2）可以考虑对日期字段增加索引----选择性未必好，加了之后还是要看查询计划，看是否用到了索引。
3）可以考虑将数据分表保存。按年、或按月保存---跨年、跨月的查询就需要分2个查询或多个查询执行。
4）如果SUM和group的字段不多，也可以考虑与日期一起建立索引，这样靠索引就可以进行统计（不建议，除非是表功能非常单一）
5）类似你问题2的方式，提前做好统计。形成按日统计表。（许多进销存系统中都有日结表、月结表等，就是为了可以快速统计某一天的库存，而不需要再根据进销存明细计算库存量）

2.
这是一个复杂的需求。慢的地方可能是查询慢、计算慢、关联查询慢、应用间有互相锁/阻塞导致等待等。。。你需要把你的需求详细说明下，同时看是否存在以上的情况。给你一些原则帮助你优化：

• 使用并行计算替代串行计算

• 尽可能以批的方式获取、处理数据

• 查询数据条件尽可能使用索引，请参考查询计划

• 关联查询尽可能整批进行，批的大小需要平衡

• 数据库连接时间尽量短---不要长连接，以减少并行时的互相影响

• 关注数据库锁与阻塞
  先这些吧。。。

几十万条数据不应该这么慢，你可以把sql语句亮出来瞧瞧

1. 单表太大的时候就需要分表。按日期分成一个个分区表。

2. 问题2可以考虑使用开源的Hive,不想用开源自己搭框架的话可以试试阿里云的odps，这两个系统是分布式计算框架，支持的类sql查询，类sql的表存储。