Предполагам също, че използвате Oracle. Също така ви препоръчвам да разгледате уеб страницата за обяснение на плана, като за начало. Има много неща за оптимизиране, но може да се научи.
Следват няколко съвета:
Първо, когато някой ви възложи да оптимизирате, той почти винаги търси приемлива производителност, а не крайна производителност. Ако можете да намалите времето за изпълнение на заявка от 3 минути до 3 секунди, не се притеснявайте да го намалите до 2 секунди, докато не бъдете помолени да го направите.
Второ, направете бърза проверка, за да се уверите, че заявките, които оптимизирате, са логически правилни. Звучи абсурдно, но не мога да ви кажа колко пъти са ме питали за съвет относно бавно работеща заявка, само за да разбера, че понякога дава грешни отговори! И както се оказва, отстраняването на грешки в заявката често се оказва, че я ускорява.
По-конкретно, потърсете фразата "Декартово съединение" в плана за обяснение. Ако го видите там, шансовете са много добри да сте открили неволно декартово съединение. Обичайният модел за непреднамерено декартово свързване е, че клаузата FROM изброява таблици, разделени със запетая, а условията за свързване са в клаузата WHERE. С изключение на това, че липсва едно от условията за присъединяване, така че Oracle няма друг избор освен да извърши декартово присъединяване. При големи таблици това е катастрофа в производителността.
Възможно е да видите декартово присъединяване в плана за обяснение, където заявката е логически правилна, но аз свързвам това с по-стари версии на Oracle.
Също така потърсете неизползван съставен индекс. Ако първата колона на съставен индекс не се използва в заявката, Oracle може да използва индекса неефективно или изобщо да не го използва. Нека дам пример:
Заявката беше:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(СУБД не беше Oracle, така че синтаксисът беше различен и аз съм забравил оригиналния синтаксис).
Един бърз преглед на индексите разкри индекс на клиенти с колоните (държава, държава, пощенски код) в този ред. Промених заявката на read
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
и сега се изпълняваше за около 6 секунди вместо за около 6 минути, тъй като оптимизаторът успя да използва индекса с добро предимство. Попитах приложните програмисти защо са пропуснали държавата от критериите и това беше техният отговор:те знаеха, че всички адреси имат държава, равна на „САЩ“, така че решиха, че могат да ускорят заявката, като изпуснат този критерий!
За съжаление, оптимизирането на извличането на база данни всъщност не е същото като спестяване на микросекунди от компютърното време. Това включва разбиране на дизайна на базата данни, особено на индексите, и поне общ преглед на това как оптимизаторът върши работата си.
Обикновено получавате по-добри резултати от оптимизатора, когато се научите да си сътрудничите с него, вместо да се опитвате да го надхитрите.
Успех при навлизането в оптимизацията!
