1. MySQL Индекс ашиглах
2006 он Лекц №8
Ц.Амарбат

2. Агуулга Индексийн зарчим Индекс ашиглалт Query optimizer
Нэмэлт зөвөлгөө

3. Query optimization
Олон хүмүүс миний query удаан ажиллаад байна, яаж хурдасгах вэ гэсэн асуудал тавьдаг.
Гол шийдэл бол индексийг хэрэгтэй газар нь зөв хэрэглэх явдал юм. Индекс бол query-г хурдасгах хамгийн гол хүчин зүйл юм.
Үүний дараа өөр бусад техникүүдээс судлах хэрэгтэй.

4. Индексийн ажиллах зарчим
Индексийн зарчмыг ойлгохын тулд индекслэгдээгүй хүснэгт дээр жишээ авч үзье.
Энэ хүснэгтээс 13 дугаартай компанийн бичлэгүүдийг хайж олох болбол яах вэ?
Бүх бичлэгүүдийг эхнээс нь эхлэн шалгах шаардлагатай болно. Энэ нь ялангуяа энэ хүснэгт их хэмжээний өгөгдөлтэй үед маш их цаг авдаг.

5. Индексийн ажиллах зарчим
Тэгвэл бид эхний company_num талбарт индекс өгье.
Уг индекс нь энэ талбарын эрэмбэлэгдсэн утгуудыг агуулна.

6. Индексийн ажиллах зарчим
Одоо 13 утгатай компанийг индексийг нь ашиглан хайвал эхний 3 бичлэгийг уншаад л хайлт зогсоно.
Ижил индекстэй элементүүдийг ч гэсэн дарааллан хайдаггүй. Үүний тулд жишээ нь хоёртын хайлт ашиглагддаг.

7. Индексийн ажиллах зарчим
Эндээс нэг асуулт гарч ирж болно.
Яагаад зүгээр л company_num талбарыг эрэмбэлчихээд индекс ашиглахгүй хайж болохгүй гэж? Тэгвэл адилхан хурдан болохгүй гэж үү?
Хариулт:
Хэрвээ хүснэгтэд нэг л индекс ашигласан бол үнэхээр тэгж болно. Гэхдээ индексийг ашиглан бид нэг биш олон талбарыг индекстэй болгож болно. Жишээ нь company_num, company_name хоёр талбарт индекс өгч болно.
Харин бид нэг хүснэгт дээр хоёр талбарыг зэрэг эрэмбэлэх боломжгүй.

8. Индексийн ажиллах зарчим
Индекс бол хүснэгтээс тусдаа оршдог тул олон талбарт олон индекс үүсгэх боломжтой байдаг.
MYISAM төрлийн хүснэгтийн индекс болон өгөгдлүүд нь тусдаа файлд хадгалагддаг.
INNODB төрлийн хүснэгтийн индекс болон өгөгдлүүд нь нэг tablespace –д хадгалагддаг. Tablespace нь олон файл ашиглан нэг хүснэгтийн мэдээллийг хадгалах технологи юм.

9. Индексийн ажиллах зарчим
Олон хүснэгтийг холбосон query бичих үед индексийн ач холбогдол улам их болно. Учир нь индексгүй нэг хүснэгтээс өгөгдөл хайхад уг хүснэгтийн бүх бичлэгийг шалгах бол олон хүснэгт холбосон тохиолдолд бүх хүснэгтүүдийн нийт бичлэгийн үржвэр тооны бичлэгүүдийг шалгах болно.
Дараах жишээгээр харъя. Бидэнд утгуудыг янз бүрийн дарааллаар хадгалсан i1, i2, i3 талбартай харгалзан t1, t2, t3 хүснэгтүүд байсан болог. i1
name 2 aa
921 bb
117 cc i2
name 47 sd 13
dff
511
sfd i3
name
112 ee
300
dgf
145
hht

10. Индексийн ажиллах зарчим
Энэ гурваас яг ижил дугаартай бичлэгүүдийнх нь name талбаруудыг нь жагсаан харах хэрэгтэй болжээ. Тэгвэл бичих query нь
SELECT t1.name, t2.name, t3.name FROM t1, t2, t3
WHERE t1.i1 = t2.i2 and t2.i2 = t3.i3
Энэ тохиолдолд query ажиллахад t1 хүснэгтийн эхний утгыг аваад түүнийг t2 хүснэгтээс(1000 удаа давтана) t3 хүснэгтээс(1000 удаа давтана) хайж олоод олсон нэрүүдийг хэвлэнэ. Дараа нь t1-н дараачийн бичлэгт шилжээд өмнөх үйлдлийг дахин давтана.
Үүний үр дүнд уг query ажиллаж дуусахын тул 1000x1000x1000 буюу миллиард бичлэг шалгах шаардлагатай болж байна! i1
name 2 aa
921 bb
117 cc i2
name 47 sd 13
dff
511
sfd i3
name
112 ee
300
dgf
145
hht

11. Индексийн ажиллах зарчим
Шийдэл: Бид t2 болон t3 хүснэгтийн i2, i3 талбарууд дээр индекс тавьж өгнө.
Ингэснээр t1 хүснэгтийн эхний утгыг аваад түүнийг t2 хүснэгтийн i2-н индексийг ашиглан уг утга байгаа бичлэгийг шууд олно, мөн t2-н уг i2 утгатай таарах бичлэгийг t3 хүснэгтийн i3 дээрх индексийг ашиглан олно. Үүний дараа t1-н дараачийн бичлэгэд шилжээд өмнөх үйлдлийг давтана.
Энэ query нь өмнөх query-с бараг миллиард дахин хурдтай ажиллаад өмнөхтэй ижил үр дүнг үзүүлнэ. i1
name 2 aa
921 bb
117 cc i2
name 47 sd 13
dff
511
sfd i3
name
112 ee
300
dgf
145
hht

12. Индексийн ажиллах зарчим
MySQL нь индексийг дараах тохиолдолд хэрэглэдэг:
WHERE ашиглан олон хүснэгт ашигласан query-г ажиллуулахад.
Min(), max() зэрэг MySQL-н функцүүд нь индекслэгдсэн талбарууд дээр хурдан ажиллана.
Хүснэгтийг эрэмбэлэх болох груплэх ажиллагааг хурдасгахад (ORDER BY, GROUP BY) хэрэглэнэ.
Хэрэв зөвхөн индекслэгдсэн талбараас өгөгдөл select хийж байгаа бол MySQL нь индекс файлаас өгөгдлийг олоод л буцаадаг (олсон индексэд харгалзах утгыг өгөгдлийн файлаас хайх нь энэ тохиолдолд илүү ажил).

13. Индексийн дутагдал Индекс ашигласнаар гарах дутагдал нь:
Индексийг нэмэлт файлд хадгалснаар нэмэлт орон зайг hard disk-с шаардана. MYISAM хүснэгтэд Олон индекстэй хүснэгтийн индексийн файл нь түргэн том болж үйлдлийн системд заагдсан хамгийн том файлын хэмжээнд хүрч алдаа үүсэх боломжтой.
INNODB тохиолдолд мөн л зай эзэлнэ. Гэхдээ индекс болон хүснэгт нь нэг tablespace-д хадгалагддаг. Tablespace нь олон файлуудын цуглуулгаас тогтдог тул өгөгдлүүд нь үйлдлийн системийн файлын хэмжээний хамгийн их утгаас хэтрэх аюулгүй байдаг.
Өгөгдлийг өөрчлөх query (INSERT, UPDATE…) –г удаан болгодог. Учир нь зөвхөн өгөгдлийг өөрчлөх биш харгалзах индексийн хүснэгтийг өөрчлөх шаардлага гардаг.
Гэхдээ өгөгдлийг өөрчлөх үйлдэл нь select хийх үйлдлээс хамаагүй бага хийгддэг тул индекс нь нийтдээ ашигтай зүйл юм.

14. Ямар талбарт индекс өгөх вэ?
Хайлт, эрэмбэлэлт, бүлэглэлтэнд оролцож байгаа талбарууд нь индекслэхэд тохиромжтой байдаг.
Өөрөөр хэлбэл
JOIN – д оролцсон талбарууд
WHERE командын ард орсон талбарууд
ORDER BY, GROUP BY ард орсон талбарууд
Зөвхөн үзүүлэх зорилгоор хадгалсан өгөгдлүүдийг индекслэх нь буруу зүйл юм.

15. Ямар талбарт индекс өгөх вэ?
Талбар дахь өгөгдөл нь аль болох бага давхардаж байвал индекс илүү үр дүнтэй ажиллана.
Жишээ нь “хүйс” гэсэн талбарт индекс өгөөд огт ашиг гарахгүй. Учир нь хүснэгтийн нийт бичлэгтэй харьцуулахад аль нэг утга нь 50%-с илүү олон гарах тул.
1, 3, 7, 4, 7, 3 утгуудтай талбарт нийт 4 ялгаатай утга байна. Ер нь энэ утга нь аль болох өндөр байх тусам уг талбарт индекс илүү үр дүнтэй ажиллана.
Уламжлалт 30%-н дүрмийг хэрэглэж болно.
Энэ нь нийт ялгаатай утгын тоо нь нийт бичлэгийн тооны ядаж 30 хувь байх гэсэн үг.

16. Ямар талбарт индекс өгөх вэ?
Индекстэй талбарын урт нь аль болох бага байх хэрэгтэй. Жишээ нь хэрэв mediumint хангалттай бол bigint хэрэглэх хэрэггүй, хэрэв бүх утгууд нь 25 тэмдэгтээс илүү гардаггүй бол char(100) гэж үүсгэх хэрэггүй юм.
Индекс бүхий талбарын хэмжээ нь том байснаар боловсруулалт удааширдаг.
Жижиг өгөгдлүүдийг харьцуулахад хурдан
Жижиг өгөгдлүүд нь санах ойд бага зай эзэлнэ.
Индексүүдийг хадгалах кэшд жижиг хэмжээтэй индексүүд илүү олноор багтана. Энэ нь кэш доторх индекс хүрэлцэхгүй бол дахин hard disk-с үлдсэн индексийг ачаалах шаардлагыг багасгана.
Ялангуяа INNODB, BDB төрлийн хүснэгтүүдийн primary key нь аль болох бага хэмжээтэй байх хэрэгтэй байдаг. Учир нь энэ төрлийн хүснэгт дэх бусад индексүүд нь үндсэн түлхүүрийг ашиглан өгөгдлөө олж авдаг.

17. Ямар талбарт индекс өгөх вэ?
Хэрэв char, varchar, binary, varbinary, blob, text талбаруудад индекс өгөх гэж байгаа бол эхний тодорхой хэдэн тэмдэгтээр индекс өгч болдог.
Ингэснээр индексийн хэмжээ багасч хурд нэмэгдэнэ.
Ихэнх текст талбарууд олон утга агуулсан байх боловч эхний хэдэн байтаар л давхардахгүй байх боломж их байдаг.
Ингэж үүсгэхдээ:

18. Ямар талбарт индекс өгөх вэ?
Нийлмэл индексийн давуу талыг хэрэглэх.
Жишээ нь хүснэгтийн state, city, zip талбаруудыг нэгтгэн нэг индекс болговол эдгээр индекс нь state/city/zip дарааллаар эрэмбэлэгдсэн байдаг.
Энэ тохиолдолд query дотор дараах талбаруудыг ашиглан хайлт гүйцэтгэхэд уг индекс ашиглагдана:
Нийлмэл индексийн хамгийн зүүн талд байгаа индексийг ашиглан бичлэгийн мөрийг олдог.
Тиймээс бид city, zip оролцуулсан query бичлэг уг индекс энд тус болж чадахгүй.

19. Ямар талбарт индекс өгөх вэ?
Мөн хэт олон индекс нь хүснэгтийг өөрчлөх үйл ажиллагааг улам удаашруулна. Тиймээс цөөхөн хэрэглэгдэх талбаруудад индекс тавихгүй байсан нь дээр.
Хэрэв индекс бүхий хүснэгтэд дахин индекс нэмэх гэж байгаа бол уг индекс нь уг хүснэгтэд байгаа нийлмэл индексийн хамгийн зүүн талд байгаа эсэхийг шалгах хэрэгтэй. Хэрэв байвал уг талбарт индекс өгөд хэрэггүй. Учир нь энэ талбар угаасаа индекстэй байна гэсэн үг.
Жишээ нь хэрэв хүснэгтэд (state, city) болон zip гэсэн хоёр индекс байгаа бол state талбарт индекс өгөх хэрэггүй гэсэн үг.

20. Индекс үүсгэх Индекс үүсгэх аргуудаас сануулъя:
Alter table арга нь бүх төрлийн индексийг үүсгэж чадна:
Create index нь Primary key индексээс бусдыг нь үүсгэж чадна:

21. Индекс үүсгэх Хүснэгтийг үүсгэж байх үедээ үүсгэвэл:
Дараах хоёр зарлалт нь ижил:

22. Индекс үүсгэх
Нийлмэл индекс үүсгэхдээ талбаруудыг таслалаар тусгаарлан зааж өгнө.
Жишээ
Create table users(
id int not null primary key,
state char(10) not null,
city char(10) not null,
zip char(5) not null,
UNIQUE (state, city, zip) )

23. Индекс устгах
Drop index ашиглах:
Alter table ашиглах:

24. Индекс ашиглах
Хэрвээ query дотор индекстэй талбар дээр боловсруулалт гүйцэтгээд ашигласан байвал уг индекс ашиглагддаггүй. Өөрөөр хэлбэл энэ тохиолдолд уг бичлэгийн бүх утга дээр уг боловсруулалтыг хийх шаардлагатай болдог.
Үүний үр дүнд индекстэй талбартай query ч гэсэн индексгүй мэт удаан ажиллах болно.
Үүнээс тойрч гарахын тулд query-гээ индекстэй талбар нь аль болох дангаараа орж байхаар бичихийг хичээх хэрэгтэй.
Жишээ нь
SELECT name FROM users WHERE id*2 < 30
id талбар нь индекстэй боловч энэ тохиолдолд индексийн ашиг гарахгүй. Үүний оронд:
SELECT name FROM users WHERE id < 15
Ингэснээр индекс ашиглагдан эрс хурдан болно.

25. Индекс ашиглах Өөр жишээ: Дараах жишээг авч үзье:
SELECT name FROM users WHERE YEAR(birth) < 1990
Үүний оронд:
SELECT name FROM users WHERE birth < ‘ ’
Дараах жишээг авч үзье:
Эхний query нь хамгийн удаан ажиллана.
Хоёрдах нь арай дээр учир нь < тэмдгийн баруун талд байгаа тогтмолыг MySQL нь нэг удаа бодоод л бусад бүх бичлэгүүдэд хэрэглэнэ. Гэхдээ date_col талбарийн индекс хэрэглэгдэхгүй тул мөн л уг талбарын утгыг бүх бичлэгээс боловсруулалт хийн гаргаж авна.
Гуравдах хувилбарт индекс хэрэглэгдэх боломжтой болох тул хамгийн хурдтай ажиллана.

26. MySQL query optimizer
MySQL нь хэрэглэгчийн дамжуулсан query-г ажиллуулахын өмнө уг query-г яаж хурдан ажиллуулах талаар товчхон шинжилгээ хийгээд дараа нь олсон шийдлийнхээ дагуу ажиллуулдаг.
Энэ шинжилгээнд аль индексийг эхэлж ашиглах вэ, аль нь ашиглагдахгүй байх вэ, аль холбоосыг эхлээд боловсруулах вэ болон бусад шийдлүүд хийгддэг.
Хэрвээ query-гээ хурдан ажилладаг болгохыг хүсвэл query шинжилгээнд тус болох байдлаар query-г бичих нь үр дүнд хүрч болдог.

27. MySQL query optimizer Жишээ:
Эндээс col1-н шаардлагыг хангасан 900 бичлэг, col2-н шаардлагыг хангасан 300 мөр, хоёуланг нь зэрэг хангасан 30 мөр олдож байг.
Хэрвээ MySQL нь эхний нөхцлийг шалгавал col2-т бас таарч байгаа 30 ширхэг өгөгдлийг олохын тулд 900 ширхэг бичлэг шалгана. Тиймээс 870 үл тохирох хэсгийг шалгах болно.
Хэрвээ MySQL нь хоёрдахь нөхцлийг эхэлж шалгавал col1-т бас таарч байгаа 30 ширхэг өгөгдлийг олохын тулд 300 ширхэг бичлэг шалгана. Тиймээс 270 үл тохирох хэсгийг шалгах болно.
Тиймээс хоёрдахь нөхцлийг баримтлан ажиллуулбал query-г 300 алхмын дотор бүгдийг бодож гаргана гэсэн үг. Энэ шийдвэрийг MySQL optimizer бодож олдог.

28. Индекс устгах
Мөн индекслэгдсэн талбарыг LIKE оператортой хамтран хэрэглэж байгаа тохиолдолд ’%утга’ байдлаар ашиглавал индекс нь хэрэглэгдэхгүй. Харин ‘утга%’ байдлаар хэрэглэвэл индекс нь хэрэглэгдэнэ.
Жишээ
id талбарт нь 1 оролцсон хэрэглэгчдийг гаргахдаа
SELECT * FROM users WHERE id LIKE ‘%1%’
Энэ тохиолдолд id талбарын индекс тус болж чадахгүй.
Хэрэв 1-р эхэлсэн id-тай хэрэглэгчдийг олох бол
SELECT * FROM users WHERE id LIKE ‘1%’
Энэ тохиолдолд MySQL query optimizer нь дээрх query-г доорх query-тэй адилхан үзэж хувирган хэрэглэнэ:
SELECT * FROM users WHERE id >= ‘1’ and id <= ‘2’
Тиймээс энд индекс нь ажиллан хурдан болно.

29. Индекс устгах
EXPLAIN ашиглан query optimizer-г ажиллуулан үр дүнг харж болно.
Жишээ: Доорх гурван query-г query optimizer-р ажиллуулан үр дүнг харъя.
Бүх бичлэгийг шалгана гэсэн үг
Хэрэглэчихээр индекс байхгүй байна гэсэн үг.
Нийт 102 бичлэг уншина
Expiration талбарт нь индекс байгаа

30. Индекс устгах
Expiration талбарт нь индекс байгаа

31. Индекс устгах Expiration талбарт нь индекс байгаа
Бүх бичлэгийг биш хэсэг бүлэг бичлэгийг шалгасан байна.
Expiration талбарт байгаа индексийг хэрэглэж байна.
Энэ Query-г ажиллуулахад нийт 6 бичлэг уншихад хангалттай байна.

32. MySQL query optimizer
Тиймээс EXPLAIN ашиглан манай query-д индекс нь хэрэглэгдэж байгаа эсэх, хэдэн мөр бичлэг уншин ажиллаж байгааг нь шалгаж болж байна.
Ингэснээр бид өөрсдийн query-г янз бүрээр бичиж үзээд аль нь илүү хурдтай ажиллаж байгааг нь харах боломжтой болж байгаа юм.

33. MySQL query optimizer Өөр жишээн дээр харъя:
утгыг агуулсан t1, t2 хүснэгт бидэнд байгаа болог. Хэрэв бид энэ хоёр хүснэгтээс ижил утгуудыг нь жагсаан харах болбол дараах query-г бичиж өгнө.

34. MySQL query optimizer
Хоёр хүснэгтэд алинд нь ч индекс хэрэглээгүй бол:

35. MySQL query optimizer Дараах зарчмаар ажиллаж байна:
Тиймээс нийт 1000х1000 буюу сая бичлэг шалгах болно.

36. MySQL query optimizer
Үүнийг сайжруулахын тулд холбогдож байгаа хоёр талбарын аль нэг дээр индекс тавьж өгөөд үр дүнг харвал:

37. MySQL query optimizer
Энэ нь хамаагүй сайжирсан байна. Нэгдүгээр хүснэгтийн 1000 бичлэг бүрт хоёрдугаар хүснэгтийн 10 бичлэгийг ойролцоогоор шалгана. Тиймээс нийт бичлэг шалгаад ажиллаж дуусна.
Хэрэв одоо эхний хүснэгтэд индекс өгвөл илүү сайжрах уу?
Манай тохиолдолд хоёр хүснэгтийн аль нэгийх нь бүх бичлэгийг унших шаардлагатай тул энэ нь тус болохгүй. Учир нь хүснэгт бүрт ялгаатай 1000 утга байгаа.
Хэрэв хүснэгт бүрт давхардсан утгууд байвал алинд нь индекс өгөх вэ?
Нэгдүгээр хүснэгтийн i1 талбарт ялгаатай утгууд нь 680
Хоёрдугаар хүснэгтийн i1 талбарт ялгаатай утгууд нь 510 байг
Энэ тохиолдолд Нэгдүгээр хүснэгтэд индекс өгснөөр илүү хурдан болно. Учир нь олон ялгаатай утгуудтай талбарт индекс өгснөөр эрэмбэлэлт нь илүү олон интервалтай болох тул хайлтаар илүү хурдан шилжих боломжтой болно.

38. MySQL query optimizer
Хэдийгээр өмнөх query илүү сайн болсон боловч эхний хүснэгтийн утга бүрт 10 биш 1 л утга харгалзаж байгаа. Тиймээс бас л илүү хайгаад байна гэсэн үг.
Бид өмнөх query-г илүү сайн ажиллуулдаг болгож болно. Үүний тулд query-г ажиллуулахын өмнө ANALYZE TABLE tableName командыг өгөх хэрэгтэй.
Ингэснээр MySQL нь уг хүснэгт дэх талбарын утгууд нь ямар тархалттай байгааг судалдаг. Өөрөөр хэлбэл 1 ба 2-р хүснэгт хоёуланд нь 1000 ширхэг ялгаатай утга байгаа гэдгийг query optimizer нь олж мэднэ гэсэн үг.

39. MySQL query optimizer Үүнийг туршиж үзье:
Одоо 1 л бичлэг шалгаж байна.

40. MySQL query optimizer
Мөн зарим тохиолдолд query optimizer буруу шийд гаргах тохиолдол байдаг. Жишээ нь ашиг муутай индексийг хэрэглэх гэх мэт.
Бид үүнийг EXPLAIN ашиглан илрүүлээд дараа нь query optimizer-н шийдвэрийг өөрчилж болно.
Үүний тулд энгийн JOIN -ий оронд STRAIGHT_JOIN ашиглаж болно. Ингэж холбосон тохиолдолд MySQL-г хүчээр join хийх хүснэгтийн дарааллыг join-ий хойно бичигдсэн байгаа хүснэгтүүдийн дарааллаар хайлгадаг. Энэ тохиолдолд сонголтоор аль болох цөөн бичлэг өгч байгаа хүснэгтийг join командын хойно эхлэн тавих хэрэгтэй. Ингэснээр эхний сонгогдсон цөөн тооны бичлэгүүдийг бусад хүснэгтээс сонгогдсон бичлэгүүдтэй тулгах замаар илүү цөөн үйлдэл хийн query-г ажиллуулдаг.
Хэрэв аль хүснэгтээс илүү цөөн өгөгдөл сонгогдож байгааг мэдэхгүй байгаа бол хамгийн олон бичлэгтэй хүснэгтийг хамгийн эхэнд байрлуулсан нь дээр.
Мөн индекс ашиглалтыг өөрчлөхийн тулд дараах командуудыг query дотроо хэрэглэж болно.
FORCE INDEX
USE INDEX
IGNORE INDEX
Эдгээрийг join-ий ард бичигдсэн хүснэгтийн нэрийнх нь ард бичиж өгнө.

41. MySQL query optimizer Илүү хурдан устгах хэрэгтэй тохиолдолд:
Хүснэгт доторх бүх өгөгдлийг устгах тохиолдолд:
DELETE FROM tablename; командыг өгч ажиллуулдаг.
Гэхдээ энэ нь бүх бичлэгүүдийг нэг нэгээр нь устгах тул том хүснэгт дээр цаг авах болно.
Илүү хурдан устгах хэрэгтэй тохиолдолд:
TRUNCATE TABLE tablename командыг хэрэглэнэ.
Энэ нь уг хүснэгтийг drop хийгээд буцаагаад шинээр үүсгэдэг. Тиймээс агшин зуурт ажилладаг.
Гэхдээ энэ тохиолдолд хэдэн өгөгдөл устгасныг мэдэх боломжгүй. Энэ тоог мэдэхийг хүсвэл эхний аргыг хэрэглэнэ.

42. Нэмэлт зөвөлгөө
Өмнөх лекцүүдээс бид query дотор дэд query хийж ажиллуулах тухай үзсэн (жишээ нь select доторх select)
Энэ боломж нь харьцангуй саяхан MySQL 4.1 хувилбараас эхлэн нэмэгдсэн.
Тиймээс зарим тохиолдолд MySQL нь дэд query-тэй ажиллахаас илүү JOIN-ийг илүү хурдан ажиллуулдаг.
Ер нь ихэнх дэд query-г JOIN query-р бичих боломжтой байдаг.
Хэрэв дэд query бүхий query удаан ажиллаж байвал түүнийг JOIN-д шилжүүлээд туршиж үзэх хэрэгтэй.

43. Нэмэлт зөвөлгөө
Ер нь query-г олон төрлөөр бичиж үзэж байх хэрэгтэй. Тэгээд аль нь илүү хурдан ажиллаж байгааг шалгадаг.
Шалгахдаа санах зүйл:
Олон удаа ажиллуулж үзэх. Учир нь query-г эхлээд ажиллуулахад хэрэгтэй өгөгдлүүд нь түр санах ой буюу кэшд хадгалагдсан байдаг тул ийм төрлийн хоёрдахь query ажиллахад илүү хурдтай ажилладаг.
Query туршиж байхдаа сервэрийн ачаалал хэвийн байх үеийг сонгох хэрэгтэй.

44. Нэмэлт зөвөлгөө
MySQL нь төрөл хувиргалтыг автоматаар гүйцэтгэдэг. Хэрэв бид талбарын утгыг зөвхөн уг талбарын төрөлтэй нь таарах утгатай харьцуулбал хурд нэмэгдэж болдог.
Жишээ нь: Хэрэв my_col нь int төрөлтэй бол доорх query-үүд ижил үр дүн буцаана:
Гэвч хоёрдах нь автомат төрөл хувиргалтыг ашиглана. Төрөл хувиргалт нь өөрөө маш багаар ч гэсэн цаг авах юм. Илүү ноцтой зүйл бол хэрэв my_col талбар нь индекстэй байсан бол автомат төрөл хувиргалт нь индекстэй талбарын индексийг үл хэрэгсэж болох юм.

45. Нэмэлт зөвөлгөө
Хэрэв WHERE –ийн ард индекстэй талбаруудыг нөхцөл шалгахад ашиглаж байгаа бол эдгээр талбаруудын төрлийг аль болох ижил байхаар сонгох хэрэгтэй.
Энэ тохиолдолд query-н ажиллах хурд нэмэгддэг.