查询数据库性能和软件可靠性

Question

情况： 客户正在运行一个基于Web的财务应用程序，该应用程序的主要功能包括大量的内部和外部金融交易。 流程是自动化的。 我们在午夜执行多项cron工作任务，以将付款分配给适当的客户。 我们每月平均有2000至3000个新客户，目前总共有30,000个客户。 到目前为止，我们的交易表有将近900,000条记录，并且预计未来几个月会急剧增加。

技术：最初，我们使用LAMP环境，带有Codeignitor框架，用于查询的Laravel elequont ORM和Mysql。 托管：托管在AWS，T2小型实例中，未实现负载均衡器。 **此应用程序是三年前开发的。

问题： 当前，我们的客户在高峰时段面临停机时间，他们的客户在查看交易档案和统计数据时也面临加载时间问题。 而且，他们担心如果cron工作任务失败，他们将无法应对。 （进行了大量计算，并在大量客户中插入了金额）。

我们的计划： 因此，现在，我们计划以性能和容错为主要目标，从头开始对应用程序进行返工。而且此应用程序至少在其他方面必须可靠 六到八年。

技术：节点（Sails.js），Angular 5，带负载均衡器的AWS，AWS RDS（Mysql）

我们的方法：根据我们的分析，我们几乎没有发现造成性能下降的直接原因。最初，访问大量表的客户有许多统计信息。 大多数统计数据是当月的。因此，我们计划为此添加日志表，并仅将当前月份的数据保留在特定表中。addMethod

因此，可能会有这样的日志表，只会进行读取操作。

查询：

1. 将仅准备就绪的表拆分为单独的数据库是好事，还是可以将其包含在单个数据库中？
2. Mysql缓冲区高速缓存与Redis / memcache有何不同，在有更多流量流入时是否会发生任何内存消耗问题？
3. 在evey月底（如我所提到的日志文件所述）截断几张表的最佳方法是什么？
4. 我要朝正确的方向前进吗？

Answer 1

一百万行的大小适中，而不是“巨大”。由于您遇到了性能问题，因此我不得不相信，这是由于索引编制不佳和/或查询表述不佳所致。

1. 找出最麻烦的查询。有关使用mysqldumpslow -s t或pt-query-digest定位它们的建议，请参见this。
2. 提供SHOW CREATE TABLE和EXPLAIN SELECT ...来讨论如何改进它们。只需添加一个“复合”索引即可。

另一个可能的性能瓶颈可能是反复汇总旧数据。如果是这种情况，请考虑使用_building and maintaining Summary Tables的数据仓库技术。

关于您的四个问题，我暂时对每个问题说“不”。

各种框架往往使 small 应用程序易于开发，但在扩展时会遇到麻烦。尽管如此，仍然可以在不放弃框架的情况下解决某些问题。

AWS等为您提供了很多可靠性和 read 扩展能力。但是，我再说一遍，可能要看的地方是缓慢的查询，而不是您提出的各种想法。

关于定期截断，让我们在查看数据外观以及保留数据的业务需求之后再进行讨论。