假设我有一个包含15列MyTable的表和一个UPDATE
查询,如下所示:
UPDATE MyTable SET relevancy = 1, ruleName = 'myRule'
WHERE colOne = 'some condition' AND colTwo = 5 ...
AND (RELEVANCY <> 1 OR RELEVANCY IS NULL)
...
表示WHERE
条件中15列的任意组合(即,它可以是col14和col10,col1或col11和col14,等等)
我们要做的是我们有一个大约1M +行的表,我们根据列值设置这些“过滤规则”,将特定行的相关性设置为1,这样用户可以这样说:我想要所有这些来自MyTable的数据,col1值为'hello'。此UPDATE语句也在循环中运行(~20次)。
优化此查询的方法有哪些?假设还没有像索引那样进行优化(我们还没有这个,因为我们不确定索引哪些列。)
答案 0 :(得分:0)
加速SELECT查询的一条经验法则是索引JOIN表达式或WHERE子句中使用的每一列。
权衡是UPDATE和DELETE查询更改行和部分或全部索引。因此添加索引通常会降低更新速度。
有15列和100万行,我的猜测是,通过添加索引获得的速度不会被dbms必须更新索引所损失的速度完全抵消。但我可能是错的。
但索引很便宜。更新统计信息。在添加索引之前测量性能。添加索引。再次测量性能。决定是保留索引还是删除它们。
索引可以包含多个列。例如,如果colOne和colTwo通常一起出现在WHERE子句中,则可以通过在列对上创建一个索引而不是创建两个索引(每列一个索引)来获得更好的性能。测量,索引,再次测量。
大多数SQL dbms支持EXPLAIN queryname or SQL statement
的某些变体。找出dbms支持的内容,并使用它来衡量性能。
答案 1 :(得分:0)
我看不出查询本身有什么明显错误,所以简短的回答是,如果不首先运行它并查看查询计划,就无法对其进行优化。由于关系数据库工作的方式很难通过查看查询来预测性能是什么样的,因为它取决于许多其他隐藏因素,例如数据分布,统计信息,提供的参数和其他隐藏的内部结构
那就是说,我很难理解使用这种方法而不仅仅是进行正常选择的好处 - 我可以看到的唯一好处是它可以防止编号很差的索引基于SELECT
列(可能始终正确编入索引)的用户执行RELEVANCY
的列。
此外,您指定的架构似乎将MyTable
限制为一次只应用一条规则,因此无论如何您都需要在更改过滤器时执行此UPDATE
。
你想要实现的目标是什么?
如果您无法事先确定用户将要查询的内容,那么您在索引方面唯一可以做的就是索引所有列(单独)并希望获得最佳效果。
对于许多列,由于需要更新的索引数量很多,因此在更新或插入此表时可能会开始看到运行时性能损失,但替代方案很可能是每次用户搜索列时都会进行表扫描没有编入索引。
如果您准备在每个案例的基础上更改索引,如果您开始遇到某些查询问题,这也会有所帮助。