s***s
发帖数: 1301 | 1 这两天check 一个t-sql query,发现这个query总是选择不是最优的index，
如果指定最优的index，performance就会好很多。但是我们不想在query里这么做（
with
index = ....)，这个query是production的code, 将来万一改变index,可能会导致
performance变动，增加维护工作困难。
不知道是什么原因sql server为什么总是不能选择最优index， 是plan被cached了吗？
有什么方法可以让sql server更新它的plan呢？ |
B*****g
发帖数: 34098 | 2 google:
http://msdn.microsoft.com/en-us/library/ms174283%28v=sql.105%29
【在 s***s 的大作中提到】
: 这两天check 一个t-sql query,发现这个query总是选择不是最优的index，
: 如果指定最优的index，performance就会好很多。但是我们不想在query里这么做（
: with
: index = ....)，这个query是production的code, 将来万一改变index,可能会导致
: performance变动，增加维护工作困难。
: 不知道是什么原因sql server为什么总是不能选择最优index， 是plan被cached了吗？
: 有什么方法可以让sql server更新它的plan呢？
|
s***s
发帖数: 1301 | 3 测试了， FREEPROCCACHE 不work，还是选择不好的index.
还有别的命令可以试试吗？
谢谢。
【在 B*****g 的大作中提到】
: google:
: http://msdn.microsoft.com/en-us/library/ms174283%28v=sql.105%29
|
a9
发帖数: 21638 | 4 你是在生产上测试的还是测试环境上测的？
如果数据量不一样的话，是有可能的。
【在 s***s 的大作中提到】
: 这两天check 一个t-sql query,发现这个query总是选择不是最优的index，
: 如果指定最优的index，performance就会好很多。但是我们不想在query里这么做（
: with
: index = ....)，这个query是production的code, 将来万一改变index,可能会导致
: performance变动，增加维护工作困难。
: 不知道是什么原因sql server为什么总是不能选择最优index， 是plan被cached了吗？
: 有什么方法可以让sql server更新它的plan呢？
|
s***s
发帖数: 1301 | 5 测试环境上测的，数据量是一样的。
实在是很奇怪为啥总是选择不是最优的index. :(
还有什么方法可以试试吗？
谢谢！
【在 a9 的大作中提到】
: 你是在生产上测试的还是测试环境上测的？
: 如果数据量不一样的话，是有可能的。
|
B*****g
发帖数: 34098 | 6 statistics了吗？
【在 s***s 的大作中提到】
: 测试环境上测的，数据量是一样的。
: 实在是很奇怪为啥总是选择不是最优的index. :(
: 还有什么方法可以试试吗？
: 谢谢！
|
e****7
发帖数: 4387 | 7
我刚才也是想提这个，update statistics, 看了你那个枪铁，没敢说：)
【在 B*****g 的大作中提到】
: statistics了吗？
|
k********e
发帖数: 702 | 8 update statistics是必须的。当然，其实更应该先defrag/reindex一下（尤其是
cluster index），信不信由你。
另外，高版本的SQL可以绑定execution plan，当然，你index hint也可以。没什么不
好的。query optimizer本来就不能保证100%最优。
对了，我是web developer。我都知道这个。 |
B*****g
发帖数: 34098 | 9 最简单就是把所有index都recreate，哈哈
【在 k********e 的大作中提到】
: update statistics是必须的。当然，其实更应该先defrag/reindex一下（尤其是
: cluster index），信不信由你。
: 另外，高版本的SQL可以绑定execution plan，当然，你index hint也可以。没什么不
: 好的。query optimizer本来就不能保证100%最优。
: 对了，我是web developer。我都知道这个。
|
e****7
发帖数: 4387 | 10
牛
【在 k********e 的大作中提到】
: update statistics是必须的。当然，其实更应该先defrag/reindex一下（尤其是
: cluster index），信不信由你。
: 另外，高版本的SQL可以绑定execution plan，当然，你index hint也可以。没什么不
: 好的。query optimizer本来就不能保证100%最优。
: 对了，我是web developer。我都知道这个。
|
|
|
e****7
发帖数: 4387 | 11
不能吧，占用太多资源，同时还增加query optimizer 的工作量。
【在 B*****g 的大作中提到】
: 最简单就是把所有index都recreate，哈哈
|
B*****g
发帖数: 34098 | 12 test, haha
【在 e****7 的大作中提到】
:
: 不能吧，占用太多资源，同时还增加query optimizer 的工作量。
|
e****7
发帖数: 4387 | 13
切，我说呢
【在 B*****g 的大作中提到】
: test, haha
|
i****a
发帖数: 36252 | 14 is this query in a stored procedure?
【在 s***s 的大作中提到】
: 这两天check 一个t-sql query,发现这个query总是选择不是最优的index，
: 如果指定最优的index，performance就会好很多。但是我们不想在query里这么做（
: with
: index = ....)，这个query是production的code, 将来万一改变index,可能会导致
: performance变动，增加维护工作困难。
: 不知道是什么原因sql server为什么总是不能选择最优index， 是plan被cached了吗？
: 有什么方法可以让sql server更新它的plan呢？
|
e****7
发帖数: 4387 | 15
LZ didn't mention, assumed not, otherwise re-compile the proc will force the
query optimizer to re-create exe plan.
【在 i****a 的大作中提到】
: is this query in a stored procedure?
|
i****a
发帖数: 36252 | 16 that's what I am trying to get at. try recompile
also can get the cached execution plan to see what SQL is doing
the
【在 e****7 的大作中提到】
:
: LZ didn't mention, assumed not, otherwise re-compile the proc will force the
: query optimizer to re-create exe plan.
|
p********l
发帖数: 279 | 17 看一下你的Query里面有没有Implicit Cast，很多时候就是因为这个而没有选择最优的
index
【在 s***s 的大作中提到】
: 这两天check 一个t-sql query,发现这个query总是选择不是最优的index，
: 如果指定最优的index，performance就会好很多。但是我们不想在query里这么做（
: with
: index = ....)，这个query是production的code, 将来万一改变index,可能会导致
: performance变动，增加维护工作困难。
: 不知道是什么原因sql server为什么总是不能选择最优index， 是plan被cached了吗？
: 有什么方法可以让sql server更新它的plan呢？
|
e****7
发帖数: 4387 | 18
good one
【在 p********l 的大作中提到】
: 看一下你的Query里面有没有Implicit Cast，很多时候就是因为这个而没有选择最优的
: index
|
