SQL数据库困境:针对查询还是写入进行优化？
我正在做一个个人项目(搜索引擎)，有点进退两难。目前，它针对向搜索索引写入数据进行了优化，而对于搜索查询，它的速度明显变慢。
DTA (数据库引擎优化顾问)建议添加几个索引视图，以加快搜索查询速度。但这不利于向DB写入新数据。
看起来我不能没有另一个！
这显然不是一个新问题。解决这个问题的好策略是什么？
回答 3
Stack Overflow用户
发布于 2009-12-09 15:31:33
一种常见的策略，并不是在所有情况下都适用/实用，是
“输入网关”方法
使用这种方法，所有的实时插入都是在一个表(或几个表)中完成的，而为搜索应用程序提供服务的是另一组表(具有许多索引和其他面向搜索的优化)。以固定(或可变/基于加载)的时间间隔，将输入表中的行传送到应用程序表，并从输入表中删除，以便保持该输入网关精简，这意味着不需要太多索引。
这种方法的主要缺点当然是在实时更新方面，应用程序数据的滞后。这种情况可以通过几种方式解决，通常是通过增加传输频率，或者让应用程序运行两次搜索/联合类型的搜索(导入“堆”中的搜索通常足够快，即使没有/只有很少的索引，因为它的大小更小)
Stack Overflow用户
发布于 2009-12-09 15:20:52
你的场景是什么-- OLAP还是OLTP (“搜索引擎”听起来查询比写新数据更频繁……)？
我遇到过类似的情况，我在DTA建议的基础上添加了大量索引，结果发现由于写入速度减慢，我的ETL进程变慢到了停顿状态。除了尝试不同的东西并找到最适合我情况的平衡之外，我没有任何经验可以遵循。
Stack Overflow用户
发布于 2009-12-09 15:22:22
总是针对查询进行优化。
即使是“密集写入”也不会超过15%的写入(我在某处读到的)。例如：
- UPDATE..WHERE是select/search，因为带有唯一约束的WHERE
- INSERT需要检查duplicates
- DELETE的约束要求检查所有子表FK列
我对我们的联机事务处理系统的估计是最低95%的阅读率(每天系统5次million+插入)到超过98%的其他系统
https://stackoverflow.com/questions/1872142
复制相似问题
腾讯云开发者
