Query –ны хурдыг сайжруулах зарим зөвлөмжүүд

1. “SELECT * FROM …” гэж бүх баганыг мэдээллийн сангаас унших биш өөрт шаардлагатай цөөн хэдэн багануудаа л нэг бүрчлэн нэрээр нь зааж мэдээллийн сангаас уншвал илүү хурдан ажиллана.
2. WHERE дээр аль болох sargable биш операторуудын оронд sargable оператор ашиглавал илүү хурдан
3. WHERE дээр ашиглагдаж байгаа баганууд бүгд индексгүй тохиолдолд OR операторыг аль болох ашиглахаас татгалзах
4. Боломжтой бол UNION –ны оронд UNION ALL –ыг ашиглавал илүү хурдан
5. Нэг хүснэгтээс гаргасан хоёр тусдаа бичлэгүүдийг UNION хийж нэгтгэхгүй байх. Харин түүний оронд WHERE дээр OR ашиглан нэгтгэсэн бичлэгийг шууд гаргаж авсан нь илүү хурдан.
6. Хүснэгтэнд тодорхой нэг нөхцөлийг хангах бичлэг байгаа эсэхийг шалгахдаа COUNT(*) бус EXISTS –ийг ашиглавал илүү хурдан ажиллана.
7. Бүх бичлэгүүдийг биш зөвхөн хэрэгтэй бичлэгүүдийг WHERE дээр шүүлтүүр хийж авч байх
8. Хүснэгтээс NULL өгөгдөлтэй бичлэгүүдийг шалгахдаа NOT IN –ийн оронд EXISTS, NOT EXISTS, IN эсвэл LEFT JOIN гэсэн операторуудыг ашиглавал илүү үр дүнтэй
9. Хэрэв EXISTS –ийг ашиглах боломжтой бол аль болох IN операторыг ашиглахаас татгалзах
10. Хэрэв BETWEEN –ийг ашиглах боломжтой бол аль болох IN операторыг ашиглахаас татгалзах
11. IN операторыг ашиглан шүүлт хийхдээ байнга ашиглагддаг буюу хамгийн түрүүнд олдох өгөгдлөөс нь эхэлж эрэмбэлэн ашиглавал илүү хурдан ажиллана
12. Боломжтой бол WHERE дээр бичлэгүүдийг шүүлт хийхдээ SUBSTRING –ийн оронд LIKE –ийг ашиглах нь илүү хурдан
13. Үнэхээр шаардлагатай л биш бол ORDER BY –ыг ашиглахаас татгалзах
14. Query –нд бичлэгүүдийг эрэмбэлэхдээ аль болох шаардлагагүй багануудаар эрэмбэлэхгүй байх
15. Аль болох цөөн тооны мөртэй бичлэгүүдийг эрэмблэх
16. Байнга эрэмбэлэлт хийдэг багануудын хувьд класстер индекс (clustered index)  үүсгэж ашиглах нь илүү хурдан
17. Хэрэв GROUP BY –ыг aggregate function (SUM, COUNT,…) оролцуулалгүйгээр ашиглан, бичлэгүүдийг давхардуулахгүй авахыг хүсэж байгаа бол DISTINCT ашигласан нь илүү хурдан

Дээрх зөвлөмжүүд нь SQL Server -ээс гадна MSAccess, Oracle, MySQL гэх мэт бусад мэдээллийн баазын хувьд хэрэгжүүлэхэд мөн ялгаагүй Query -г хурдасгах боломжтой.

Танд амжилт хүсье!

SQL Query –ны хурдыг сайжруулах (SARG-able operator)

Хөгжүүлэгчид query бичихдээ анх бичээд л ажиллаж байвал дараа нь мэдээллийн сангийн өгөгдлийн хэмжээ тодорхой хугацааны дараа томрохыг бодолцохгүй бичих тохиолдолууд их байдаг. Харин дараа нь оновчтой бус бичсэн маш олон query –нүүд маш удаан ажиллах, удаан хугацаагаар хүснэгтүүдийг түгжих (lock) зэргээр системийн хэвийн үйл ажиллагааг алдагдуулж, систем унаж эхэлдэг. 

SQL Server дээр query –ны хурдыг сайжруулах нэг гол зүйл SARG(Search ARGument) -able биш операторуудыг WHERE дээр ашиглахаас аль болох татгалзах явдал юм. Ялангуяа индекс тавигдсан багануудын хувьд SQL Server нь индексээ ашиглан хурдан ажиллах боломжийг Sargable биш оператор нь байхгүй болгодог.

Операторуудыг гүйцэтгэх хурдаар нь сайнаас муу хүртэл болон тэдгээрийг ашигласан жишээ query –г доор харуулав.

Sargable операторууд:

•    = (хамгийн гүйцэтгэл сайн sargable оператор)
•    >
•    <
•    >=
•    <=
•    EXIST
•    IS
•    BETWEEN
•    IN
•    LIKE 'abc%' (хамгийн гүйцэтгэл тааруу sargable оператор)

Sargable биш операторууд:

•    IS NULL
•    <>
•    !=
•    !>
•    !<
•    NOT
•    NOT EXIST
•    NOT LIKE
•    LIKE '%abc'
•    LIKE '%ABC%'
•    LIKE '%abc%'
•    Where нөхцөл дээр функц ашиглах
•    column1 = column1 (ижил багануудыг хооронд нь жиших)
•    column1 = column2 (өөр багануудыг хооронд нь жиших)

Sargable биш оператор ашиглан оновчгүй бичигдсэн query-ны жишээ:

1)  SELECT * FROM Customers WHERE Left(Name,4) = 'Jane'  / функц ашигласан /
2)  SELECT * FROM Customers WHERE Salary IS NULL
3)  SELECT * FROM Customers WHERE Name LIKE '%Jane%'
4)  SELECT * FROM Customers WHERE PersonID NOT IN (SELECT PersonID FROM Persons WHERE Gender = 'Male')

Sargable оператор ашиглан дээрх query –нуудыг илүү оновчтой байдлаар бичвэл:

1)  SELECT * FROM Customers WHERE Name LIKE 'Jane%'
2)  SELECT * FROM Customers WHERE Salary = 0
3)  сайжруулах боломжгүй
4)  SELECT * FROM Customers WHERE PersonID IN (SELECT PersonID FROM Persons WHERE Gender = 'Female')

Индекс ашиглах нь (SQL Server)

Мэдээллийн сан (database) -гийн өгөгдөл, мэдээллийн хэмжээ (ялангуяа дэлгүүр, банк, суурин болон үүрэн телефоны компани г.м байгууллагуудын мэдээлэл нэг минут, нэг цаг, өдөрт хэдэн мянга, саяаар нэмэгддэг) ихсэхийн хэрээр түүний гүйцэтгэх хурд (performance) эсрэгээр буурч эхэлдэг.

Гэдийгээр маш сайн оновчтой database normalization болон denormalization хийсэн мэдээллийн сангийн дизайнтай байлаа ч SQL Tuning хийгээгүй бол мэдээллийн хэмжээ ихсэх тусам ажиллах хурд үхэр тэрэг мөлхөхтэй адил удааширдаг. Тэгэхээр энэ үхэр тэргийн хурдыг автомашины хурд болгон нэмэгдүүлэх сайн аргуудын нэг бол SQL Tuning –тай холбоотой индекс (index) -ийг зөв оновчтой ашиглах гэж хөгжүүлэгчид сайн мэдэх байх.

Индексийг хэзээ хаана ашиглавал оновчтой байх цөөн хэдэн доорх зөвлөмжүүдийг хэрэгжүүлж байх нь хөгжүүлэгч бидэнд нэн хэрэгтэй байдаг. Үүнд:

1. Query-ний WHERE дээр орсон багана (column) -уудын хувьд индекс үүсгэх
2. Хүснэгт (table)-ийн гадаад түлхүүр (foreign key) баганууд дээр индекс үүсгэх
3. Нэг хүснэгт (table) -нд дор хаяж нэг кластер индекс (clustered index) үүсгэх. Ихэвчлэн түлхүүр багана (primary key column) дээр үүсгэдэг.
4. ORDER BY, GROUP BY, TOP болон DISTINCT –үүдэд байнга ашигладаг багануудын хувьд индекс үүсгэх
5. Онцын шаардлагагүй индекс бус харин байнга хэрэглэгдэх индексийг үүсгэж ашиглах.
6. Мэдээлэл нь байнга нэмэгдэж, хасагдаж байдаг динамик өгөгдөлтэй хүснэгтүүд (dynamic table)-ийн хувьд хэт олон индексийг үүсгэхээс татгалзах.
7. Мэдээлэл нь байнга нэмэгдэж, хасагдах нь маш бага буюу тогтмол өгөгдөлтэй хүснэгтүүд (static table)-ийн хувьд индекс үүсгэхдээ FILLFACTOR –ын PAD_INDEX-ийг өндөр хувьтайгаар, харин динамик хүснэгтийн хувьд маш бага (default 0) хувьтайгаар тохируулж байх.
8. Индексийг аль болох давхардуулж үүсгэхгүй байх
9. Оновчтой индекс үүсгэхийн тулд үр дүнг нь үнэлэх бусад хэрэгсэл ашиглах (Index Tuning Wizard)

Happy coding!

PS: Өөрийнхөө сэтгэгдлийг үлдээвэл танд талархах болно.