|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
возьмем пример из хелпа и немножко подправим Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
и дейсвительно использование такой же команды на большой таблице "вызывает тормоза" вопрос: delete sql в принципе не оптимизируется или всетаки можно что-то сделать? тогда что можно сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:04 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
ой в строке DELETE слово force лишнее что с ним что без него план оптимизации не меняется ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:09 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейО, а при чем тут delete? Дело не в нем, ав отсутствии нужных индексов. Которые нужны не только для delete. Создайте примерно такой дополнительный индекс Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:13 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
я поступил так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Rushmore optimization level for intermediate result: none Rushmore optimization level for table myproducts: none Joining table myproducts and intermediate result using index tag Prodid и прежние тормоза на больших таблицах ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:17 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейО, Вы мое сообщение читали? А выполнить предложенное пробовали? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:22 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
ну да прикольно: картинка изменилась: DELETE MyProducts FROM MSRPList WHERE MSRPList.ProdID = MyProducts.ProdID AND MSRPList.discontinued = .t. Using index tag Disc to rushmore optimize intermediate result Rushmore optimization level for intermediate result: partial Rushmore optimization level for table myproducts: none Joining table myproducts and intermediate result using index tag Prodid появилось какаято оптимазация промежуточного результата но она мне не особо нужна, мне нужна оптимизация самого delete поэтому подскажите пожалуйста как оптимизировать DELETE MyProducts FROM MSRPList WHERE MSRPList.ProdID = MyProducts.ProdID ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:44 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Я так понимаю фокс делает полный скан по MyProducts проверяя наличие MSRPList.ProdID по индексу MSRPList.ProdID. Отсюда и тормоза при большой таблице MyProducts. Если MSRPList небольшая таблица, то можно примерно так: Код: plaintext 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:49 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейОDELETE MyProducts FROM MSRPList WHERE MSRPList.ProdID = MyProducts.ProdID AND MSRPList.discontinued = .t. ... DELETE MyProducts FROM MSRPList WHERE MSRPList.ProdID = MyProducts.ProdID Не понял: MSRPList.discontinued = .t. оно надо или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:50 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Dima TЯ так понимаю фокс делает полный скан по MyProducts проверяя наличие MSRPList.ProdID по индексу MSRPList.ProdID. Отсюда и тормоза при большой таблице MyProducts. ну я тоже так понимаюDima T Если MSRPList небольшая таблица мой аналог MyProducts довольно большая таблица и полный скан да по сети это несколько минут - неустраивает т.е. вы считаете что delete sql неоптимизируется в принципе? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:53 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Выражение в WHERE местами поменять не пробовали ? WHERE MyProducts.ProdID=MSRPList.ProdID У меня сразу full показало - правда на 8-ке ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:56 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Dima TНе понял: MSRPList.discontinued = .t. оно надо или нет? не надо. в моем случае аналогичного поля вообще нет - это не совсем точный пример из хелпа ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 14:56 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
piva, а у меня 8-ка такой синтаксис вообще не понимает и запускаю на 9ке SP2 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:00 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейОт.е. вы считаете что delete sql неоптимизируется в принципе? Похоже что так при таком использовании. Мой пример можно на такой заменить: Код: plaintext 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:24 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейОпоявилось какаято оптимазация промежуточного результата но она мне не особо нужна, мне нужна оптимизация самого delete поэтому подскажите пожалуйста как оптимизировать DELETE MyProducts FROM MSRPList WHERE MSRPList.ProdID = MyProducts.ProdIDА что тут еще оптимизировать? Здесь может мпомочь только уменьшения количества удаляемых записей. Вам не нравится Rushmore optimization level for table myproducts: none ? Так у Вас ни одного ограничения на эту таблицу нет. Что оптимизировать? Определение идентификаиторов удаляемых записей идет по индексам: Rushmore optimization level for intermediate result: full Joining table myproducts and intermediate result using index tag Prodid Что оптимизировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:25 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:28 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
прошелмимо, круто!!! DELETE MyProducts FROM MSRPList WHERE MyProducts.ProdID= MSRPList.ProdID && AND MSRPList.discontinued = .t. Using index tag Del to rushmore optimize intermediate result Rushmore optimization level for intermediate result: full Using index tag Del to rushmore optimize table myproducts Rushmore optimization level for table myproducts: full Joining table myproducts and intermediate result using index tag Prodid здорово... но ... тогда придется держать такой экзотический индекс по delete() только ради удалений впрочем это уже мне решать ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:42 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейО здорово... но ... тогда придется держать такой экзотический индекс по delete() только ради удалений впрочем это уже мне решать его нужно не держать, а создавать. он не экзотический, а в усмерть обычный. прочитайте про бинарные индексы и откройте для себя, это то из новшеств, которое Вы упустили. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:46 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
АлексейО, оптимизатор выбирает какой-то способ выполнения запроса, этот способ однозначно быстрее самого медленного (скан в скане), но не факт что выбран самый быстрый вариант. Оптимизатор не учитывает все факторы влияющие на скорость, например таблица в сети или локально лежит. Поэтому в случаях где критична скорость выполнения кода стараюсь перепробовать все возможные способы. АлексейОтогда придется держать такой экзотический индекс по delete() Скорость померь в реальных условиях. Почти уверен что время работы запроса увеличится. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2010, 15:55 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
Оптимизация вовсе не равнозначна ускорению. "Как правило", да, ускоряет. Но как поведет себя на практике, надо проверять. Как ни странно, но FULL оптимизация может привести к замедлению, а не к ускорению выполнения запроса. Как уже заметил Dima T надо проверять на практике, ускорился или замедлился запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2010, 11:20 |
|
оптимизация delete sql
|
|||
---|---|---|---|
#18+
ВладимирМ, я это прекрасно понимаю, мало того: самый быстрый delete sql в моем случае выполняется 30 секунд и все это время другие пользователи не могут открыть таблицу поэтому в конце концов я выбрал средний вариант: scan delete where ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2010, 11:46 |
|
|
start [/forum/topic.php?fid=41&fpage=88&tid=1584913]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
82ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
others: | 318ms |
total: | 506ms |
0 / 0 |