Re: SQL вопросы по оптимизации | |
---|---|
Syberex Автор Сообщений: 1432 Откуда: Кострома Дата регистрации: 19.01.2004 |
Цитата:А какие параметры лучше проверять? Типа запомнить размер и дату в конце работы? Но для файл серверного приложения не пойдет ... ------------------ |
Re: SQL вопросы по оптимизации | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Как правило, стоит стремится уменьшить размер промежуточных результатов. Также немаловажно какая из двух таблиц будет ведущей во время JOIN. Как правило, JOIN выполняется быстрее если таблица, в которой остается меньше записей после Rushmore оптимизации, является ведущей. Следующий код это демонстрирует:
Если есть коррелированный подзапрос, то может иметь смысл коррелировать его не прямо к исходной таблице а к результату подзапроса помещенного во FROM, который "соединит" исходную таблицу с другими таблицами, при условии, что этот подзапрос вернет меньше записей чем число записей в исходной таблице. Много разных факторов влияют на производительность, поэтому не стоит слепо следовать каким-то правилам. Надо попробовать и так и эдак и желательно делать это с данными, которые максимально близки к реальным (количество, разброс значений, и т.д. и т.п.). Поиграть индексами, какие-то создать, какие-то удалить или изменить выражение так, чтобы результат был тот же, но с индексным выражением оно не совпадало. Цитата: В VFP9 во FLUSH добавлен новый модификатор FORCE. Если он упомянут, то VFP вызывает дополнительную функцию, которая таки должна заставить операционку сбросить изменения на диск. Я бы порекомендовал выполнять FLUSH после того, как была произведена какая-то группа изменений. Особенно с таблицами открытыми эксклюзивно, для них VFP может достаточно долго держать изменения в своем кэше и не отдавать их операционке. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: SQL вопросы по оптимизации | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Aleksey Tsingauz [MSFT]
Алексей спасибо за внимание к нашим дурацким вопросам. Igor Korolyov Цитата: Согласен, но одно непонятно почему не возникает ошибка при выдаче Flush, когда сетевой шнурок уже выдернут. Цитата: Ну это вообще не подлежит обсуждению, иначе кто нам будет платить за сопровождение, а так мы вроде уважаемые люди ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: SQL вопросы по оптимизации | |
---|---|
Syberex Автор Сообщений: 1432 Откуда: Кострома Дата регистрации: 19.01.2004 |
2 Aleksey Tsingauz [MSFT]
Спасибо за пример, теперь понятно. Но в реальных условиях за таким отношением практически не уследить... У меня вот только что произошло еще кое-что связанное с JOIN (как мне кажется ) Всю ночь просидел... Вообщем вот: В модальной форме открывается вид (список деталей), в нем несколько JOIN-ов, вдруг он стал выдавать сообщение Цитата:Я начал проверять где были изменения, но вид пуст, GETFLDSTATE() возвращает .NULL. начал проверять код вида - все нормально, стал базу упаковывать и Validate-ить в результате всего Фокс9 завис с окном с сообщением: Цитата:там только кнопка ОК, жму и оно опять появляется ... короче "снять задачу" В хелпе только это: Цитата: Думал базе конец, но пронесло... Потом выяснеилось что для некоторых товаров, вид с деталями всетаки открывается! Оказалось, что не открывается когда поле id_detal (тип С(10)) для первого JOIN пусто... Пока удалил неправильные записи и сделал проверку, что бы не появлялись вновь, но ситуация непонятна ... Вод код вида (5-я буферизация)
[i][small][color=Gray]Отредактировано (02.09.04 19:27) ------------------ |
Re: SQL вопросы по оптимизации | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Хе ! А у меня еще со времен fpd(w) 2.6 тащился крыжик - включать ли FLUSH при записи, который ставился по умолчанию. Дальновидность однако , (только почему-то не всегда помогало, были редкие случаи, видимо тогда он был не до конца FLUSH )
------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Спасибо, очень интересные эксперименты. Я бы ещё добавил, что если есть
возможность заменить коррелированный подзапрос на некоррелированный, то так наверное и стоит сделать - т.к. коррелированный будет выполняться столько раз, сколько записей будет в промежутьчной выборке (ну в той к которой он привязывается), а некоррелированный - всего 1 раз. Даже если считать, что коррелированный возвращает всего по 1 записи, а некорелированный - несколько тысяч записей (зато всего 1 раз)... Ну пример - это многострадальная задача поиска "последних данных из истории изменения цен". Вплоть до VFP9 (если коенчно не прибегать к неправильным и непредсказуемым запросам с неполным GROUP BY) производительность такого запроса можно было существенно повысить, разделив его на 2 - и избавившись от коррелированного подзапроса. Ну а в VFP9 можно в одном запросе всё сделать - поместив подзапрос во FROM (он будет некоррелированным). В общем оптимизация - это очень непросто Да, и ещё, раз уж речь идёт о производительности и IN, то особо надо отметить эту фразу из Release Notes: Цитата:Это, да и фраза про то что число элементов зависит от SYS(3055), как я понимаю - неявное подтверждение того, что IN в VFP9 работает наподобии набора OR - когда вычисление прекращается при достижении заведомо известного результата, но при том повышает "сложность" выражения. Теперь насчёт FLUSH FORCE - насколько надёжно будет работать это (точнее АПИ-функция FlushFileBuffers) применительно к сетевым файлам (доступ через сетевой редиректор) - гарантируется ли сброс данных на диск сервера, или нет? Зависит ли это от типа сети и сетевого клиента (NT-сеть, Novell, UNIX/Samba-сервер) С общими принципы работы файловых систем и редиректора ознакомился (Opportunistic Locks однако весьма непросты ), но вот уверенности в том как именно пройдёт цепочка сброса буферов в случае сетевого файла пока нету... P.S. Я тут заодно Q332023 почитал, впечатляет Т.е. сначала народ жалуется на то что дескать данные пропадают, вы им р-р-раз и один хотфикс, всё вроде пучком, но тут они начинают жаловаться что дескать "медленно всё стало работать" - и вы им оп-па другой хотфикс, по сути позволяющий отменить действие первого Вот и попробуй угоди им всем ------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Э-э-э, даже не подумал как-то, что оно должно было давать ошибку когда-либо
Но возможно действительно стоит при неудаче выполнения FlushFileBuffers генерить ошибку... Да кстати, ты уверен, что данные к тому моменту как ты "выдернул шнурок" реально ещё не сбросились из кэша? Ибо в нормальных условиях кэш сбрасывается весьма и весьма быстро после операций записи... Надо будет поэкспериментировать на работе, в том числе посмотреть что за ошибка реально получается при FlushFileBuffers() с "выдернутым шнурком". ------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Цитата:Как я понимаю фоксовый оптимизатор что-то пытается в этом плане сам сделать (т.е. НЕ ставь FORCE для соединений и всё ). Цитата:А надо было отдохнуть, и с утречка со свежими силами ;) Цитата:Типичная ситуация, когда ненароком ошибаешься в размерности поля в NVL() т.е. скажем когда там не null, то берётся реальное поле с размером C(10), а когда null - подставляется SPACE(20) - вот и получается эта ошибка. Обычно вылазит при перезапросах, со сменой параметра, или если изначально представление открывалось с опцией NODATA. Да, и ещё - я вообще против однобуквенных алиасов, тем более M Не хочешь длинных или хоть минимально смысловых - пользуй t1, t2, ... например. Цитата:Фокс сам всё проверит по SET TABLEVALIDATE TO 7 И даже в более ранних он может обнаружить "несоответствие" и известить об этом ошибкой - про обработку таких ошибок я и говорил. А самому проверять... IMHO не стоит оно того. ------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Цитата: Почти. Создал таблицу с(254), добавил туда 5 млн записей - файл получился чуть больше 1Г поставил 5 буферизацию, затем replace all, tableupdate,End Trans, Flush, set step on и в этот момент дернул сеть, получил сообщение ОС FlushFileBuffers() не может завершить операцию, а у фокса не возникло ошибки (видимо, фокс не спросил как мол завершена операция), затем открыл табличку и увидел, что какая-то часть записей всё таки прилипла. Может быть отсюда и растут ноги , что не всегда данные сохраняются. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: SQL вопросы по оптимизации | |
---|---|
Syberex Автор Сообщений: 1432 Откуда: Кострома Дата регистрации: 19.01.2004 |
2 Игорь
Спасибо, действительно там должно быть space(10) ! Теперь все открывается, а деталь просто пустая ;) 2 Aleksey Tsingauz [MSFT] Не мешало бы в хелп по этой ошибке добавить пару строк про NVL(), ведь наверняка это основной момент, когда она возникает... ------------------ |
Re: SQL вопросы по оптимизации | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата: Это просто определение результата. На самом деле, VFP выполняет коррелированный подзапрос один раз, но часто (в зависимости от того, что подзапрос возвращает и как сравнивается) это требует один подготовительный шаг. Цитата: На сложность выражения влияют не только логические операторы AND и OR, но и все арифметические операторы, вызовы функций, число переданных параметров, и т.д. и т.п. Раньше, максимальное число параметров для IN было 25 и вероятность превысить сложность выражения была минимальной. Сейчас, этого предела нет и если пытаться передавать сотни параметров, то вероятность превысить сложность выражения довольно высока. Цитата:Обратитесь к документации для FlushFileBuffers. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Цитата: Не понял... Т.е. в запросе вида:
Но тогда по какому плану? Сколько он записей будет просматривать в yyy? Я всегда думал что для таких запросов внутренний подзапрос выполняется как минимум столько раз, сколько записей попадает на вход из внешней части (в данном случае из таблицы xxx). И несмотря на "простоту" запроса (допустим он полностью оптимизирован - есть индекс по полю ForLink) получим некоторое замедление - тем больше чем больше записей было в xxx. Цитата:Дык именно оттуда и не понятно как проходит взаимодействие с сетевым редиректором ------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: В данном конкретном случае подзапрос будет модифицирован так, чтобы подсчитать все искомые MAX(Another) за одно выполнение. Цитата: Логически это верно. Цитата: Конечно, не смотря на то, что модифицированный подзапрос выполняется один раз, чем больше разных MAX(Another) надо подсчитать, тем больше работы надо проделать и тем медленнее он выполняется. Но если взять следующий запрос, то подзапрос как таковой вообще выполнятся не будет.
Запрос будет трансформирован в специального вида JOIN между двумя таблицами. Вся разница между этим запросом и
будет только в том, что в первом JOIN будет по двум условиям, а во втором по одному. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Я понимаю, что целью оптимизатора и является по возможности преобразование
подзапроса в более простое и быстрое соединение. И я заметил существеннейший прирост скорости работы подобных запросов в VFP9 Но всё-же как объяснить достаточно разные результаты у по сути одинаковых запросов?
------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Игорь, замечательный пример.
Знаешь, я поставил твой 4-ый цикл на место первого и скорость выполнения увеличилась % ещё на 50, далее, что удивительно при проходе от 1-ого до 5-ого Select-a время выполнения увеличивается (казалось бы должно быть наоборот). ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: SQL вопросы по оптимизации | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Я тоже их менял местами (да и просто отключал некоторые и перезапускал
фокс), главное что пропорция в целом сохраняется... Цитата:Хм. Не заметил... У меня разбежка вся в пределах статистической погрешности (т.е. пляшут цифири около среднего, но без явной "тенденций"). Правда я ставил 10-20 выполнений в цикл (это уж потом снизил до 5, после того как на 8-ке этот запрос стал исполняться просто безобразно долго), ну ещё с SYS(1104) баловался и с индексами (в смысле проверял и без индексов и с ними). Вот до тестирования на сетевом диске руки не дошли ------------------ WBR, Igor |
Re: SQL вопросы по оптимизации | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: После удаления ORDER BY из всех запросов и увеличения внешнего цикла для INSERT до 10000, я получил следующие результаты: VFP 09.00.0000.1720 (Public Beta)
VFP 09.00.0000.2110
Разное время выполнения закономерно, все эти запросы выполняются по разным планам. Однако абсолютная разница для результата в 10000 записей кажется несущественной. Aleksey Tsingauz Visual FoxPro Dev Team |
© 2000-2024 Fox Club  |