有一个表存储了所有用户的余额信息。而很大一部分select和更新查询都与一条记录有关（例如，公司账户余额/一个机构用户经常进行交易），因此这些查询需要一个接一个地执行。你能做些什么来提高这些查询的性能？
以下是回答：
- 利用索引加快每个查询的搜索时间
- 分析查询计划以优化 SQL
- 在应用程序端进行批量更新，而不是一个一个地提交查询
没有“一个正确的答案”。
一些额外的信息和使用报告可以提供更好的信息，不仅是什么时候需要什么数据，而且是如何访问的。(联合查询引起的sql查询计划与直接查询不同)。另一个方面是将查询分解开来，看看真正需要的是什么。
在这种情况下中间件可能比 SQL 更聪明：消息队列。意思是，“服务”位于更新/读取事务之上，以便以正确的顺序处理它们（并在必要时进行节流）。
您仍然需要数据库。也许将索引保持在最低限度（不能让它们不断更新）。
- 确保所有搜索键都有索引。
- 切换到行级锁定以避免页面争用
- 分析同一记录上的多个操作以确定将保留所需序列化和/或使用乐观锁定的最松散隔离级别
- 将经常更新的列与静态/不经常更新的列横向分区
- 将最近/热数据与历史/冷数据垂直分区，以减少索引查找时间
- 更改频繁更新分区的存储层次结构级别，即移至 memory/optane/ssd
- 仪器和测量。更新与选择的查询百分比是多少？获取查询执行时间的分布图。它会导致什么具体问题？我们需要走多快？问题是偶尔出现还是总是出现？
- 您的表上有正确的索引集吗？索引过多会减慢更新速度。缺少索引会减慢选择速度。
- 应用程序中是否进行了适当的缓存？是否每次都需要从数据库中提取数据，或者在某些情况下可以使用陈旧的数据？
- 我们有哪些存储选项？我们可以将表移动到速度更快或受影响较小的存储介质上的不同表空间吗？由于热页的可能缓存，这不会对读取性能产生很大影响，但可能对写入性能有好处，并且可以让热读取与其他查询竞争更少。
- 拆分表有帮助吗？如果表非常大，我们可以将热行从表的大部分中分区。还有不参与热查询的列吗？这些可以被分解到一个单独的表中以减少选择和更新的大小——可能只有当这些列的大小很大时才有意义，但至少值得考虑。