SQL数据库困境:优化查询或写入?

在所有情况下不适用/不实际的共同策略是
“输入网关”方法
使用这种方法,所有的[实时]插入都会在一个表(或几个表)中完成,并且服务于[搜索]应用程序的功能可以从另一组表(具有许多索引和其他面向搜索的优化)中得到支持。在固定的(或可变的/基于负载的)时间间隔内,输入表中的行被传输到应用程序表,并从输入表中删除,以保持此输入网关的精简,意味着不需要太多索引。

这种方法的主要缺点当然是 应用程序数据在实时更新方面滞后 . 这种情况可以通过几种方式解决,通常是增加传输频率,或者让应用程序运行两次搜索/联合类型的搜索(导入“heaps”中的搜索通常足够快,即使没有/很少索引,由于其大小较小)

您的场景是什么——OLAP或OLTP(“搜索引擎”听起来像是查询比写新数据更频繁…)?

我也遇到过类似的情况,我在DTA建议的基础上添加了大量索引,结果发现我的ETL进程由于写入速度减慢而减慢到了停顿状态。除了尝试不同的方法并找到最适合我的平衡点之外,我没有什么经验可以遵循。

始终优化查询。

即使“写密集型”也不超过15%的写(我在某个地方读过)。例如:

• 更新..选择/搜索的位置是因为
• 带有唯一约束的插入需要检查约束是否重复
• 删除要求检查所有子表FK列

对于我们的OLTP系统,我的封底估计值至少为95%(每天系统500多万个插件),而对于其他系统则超过98%。