我有一个运行中的99.9％的AWS Aurora数据库集群专注于写入。在高峰时，它将以每秒2-3k的速度运行。
我知道Aurora在默认情况下已针对写入进行了某种程度的优化，但是我想作为AWS的一个相对较新的参与者问-Aurora进行写入性能的一些最佳做法/技巧是什么？
最佳答案
根据我的经验，Amazon Aurora不适合运行写入流量大的数据库。至少在2017年左右的实施中。也许随着时间的推移它会有所改善。
我在2017年初为繁重的应用程序制定了一些基准测试，我们发现在给定应用程序和数据库的情况下，RDS(非Aurora)在写性能方面远远优于Aurora。基本上，Aurora比RDS慢两个数量级。亚马逊声称Aurora具有高性能的说法显然完全是市场驱动的废话。
2016年11月，我参加了在拉斯维加斯举行的Amazon re:Invent session 。我试图找到一位知识渊博的Aurora工程师来回答我有关性能的问题。我所能找到的是初级工程师，这些工程师被命令重复宣称Aurora比MySQL快5-10倍的说法。
在2017年4月，我参加了Percona Live session ，并看到了有关如何使用标准MySQL和CEPH为开源分布式存储层开发类似于Aurora的分布式存储体系结构的演讲。这里有一个关于同一主题的网络研讨会:https://www.percona.com/resources/webinars/mysql-and-ceph，由我看到的工程师Yves Trudeau共同主持。
将MySQL与CEPH结合使用的清楚之处在于，工程师不得不禁用MySQL change buffer，因为无法缓存对二级索引的更改，同时也无法分配存储。对于具有辅助(非唯一)索引的表的写入，这引起了巨大的性能问题。
这与在使用Aurora对应用程序进行基准测试时看到的性能问题一致。我们的数据库有很多二级索引。
因此，如果您绝对必须将Aurora用于具有高写入流量的数据库，则建议您首先要做的是删除所有二级索引。
显然，如果需要索引来优化某些查询，这将是一个问题。当然，无论是SELECT查询，还是某些UPDATE和DELETE查询都可以使用二级索引。
一种策略可能是制作您的Aurora群集的非Aurora只读副本，并仅在该只读副本中创建辅助索引以支持SELECT查询。根据https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/的说法，我从未做过，但是显然有可能
但这仍然无济于事，您的UPDATE / DELETE语句需要二级索引。对于这种情况，我没有任何建议。您可能不走运。
我的结论是，我不会选择将Aurora用于繁重的写入应用程序。也许将来会改变。
关于mysql - 优化AWS Aurora实例的写入性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/46383763/