Sayt sekin ochilsa, ko'pchilik birinchi navbatda hostingni yoki rasmlarni ayblaydi. Lekin dinamik saytlarda sekinlikning eng keng tarqalgan manbalaridan biri bazadagi bir yoki ikki noqulay so'rovdir. Bitta sahifa o'nlab so'rov yuborishi mumkin va ularning orasida bittasi bir necha soniya davom etsa, butun sahifa shuncha kutib qoladi. MySQL'ning sekin so'rovlar logi aynan shu so'rovlarni ushlab olish uchun yaratilgan va u taxmin o'rniga aniq dalil beradi.
Sekin so'rovlar logi qanday ishlaydi
MySQL har bir so'rov qancha vaqt bajarilganini o'lchaydi. Sekin so'rovlar logi yoqilganda, belgilangan chegaradan uzoq davom etgan har bir so'rov alohida faylga yoziladi. Bu chegara long_query_time parametri bilan soniyalarda beriladi va kasr qiymat ham qabul qiladi, masalan yarim soniya. Logga so'rov matni bilan birga uning bajarilish vaqti, qulf kutish vaqti, qaytarilgan va ko'rib chiqilgan qatorlar soni ham yoziladi.
Oxirgi ikki ko'rsatkich ayniqsa foydali. Agar so'rov foydalanuvchiga 20 ta qator qaytargan, lekin buning uchun bir million qatorni ko'rib chiqqan bo'lsa, bu indeks yetishmasligining aniq belgisi. Bunday nomutanosiblik ko'pincha so'rovning o'zini emas, jadval tuzilishini o'zgartirish kerakligini ko'rsatadi.
Logni yoqish
O'z VPS serveringizda yoki administrator huquqiga ega bazada logni ikki usulda yoqish mumkin. Birinchisi server ishlab turgan paytda buyruq orqali, bu qayta ishga tushirishsiz darhol kuchga kiradi, lekin keyingi qayta ishga tushirishda yo'qoladi:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
Doimiy sozlama uchun xuddi shu qiymatlar MySQL konfiguratsiya faylining [mysqld] bo'limiga yoziladi. Fayl joylashuvi tizimga qarab farq qiladi, Debian va Ubuntu'da odatda /etc/mysql/ papkasi ichida, boshqa tizimlarda /etc/my.cnf bo'ladi. Log fayli yoziladigan papkaga MySQL xizmati yozish huquqiga ega bo'lishi kerak:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
# indekssiz so'rovlarni ham yozish (vaqtincha, log tez o'sadi):
# log_queries_not_using_indexes = 1
long_query_time ni juda kichik qilib qo'ysangiz, log tez o'sib, diskni to'ldirishi mumkin. Boshlanishiga bir soniya yaxshi qiymat, eng og'ir muammolar tuzatilgach chegarani yarim soniya yoki undan pastga tushirib, keyingi qatlamni ko'rish mumkin.
Log yozuvini o'qish
Logdagi har bir yozuv sarlavha qatorlari va so'rov matnidan iborat. Quyidagi misolda so'rov uch soniyadan ortiq davom etgan, foydalanuvchiga 24 ta qator qaytargan, lekin buning uchun bir milliondan ortiq qatorni ko'rib chiqqan:
# Time: 2026-11-04T10:15:32.481920Z
# User@Host: shop_user[shop_user] @ localhost []
# Query_time: 3.214 Lock_time: 0.000120 Rows_sent: 24 Rows_examined: 1184302
SET timestamp=1793787332;
SELECT * FROM products WHERE category_id = 17 ORDER BY created_at DESC LIMIT 24;
Bunday yozuvni ko'rib, birinchi savol shunday bo'ladi: category_id va created_at ustunlarida indeks bormi? Ko'pincha javob yo'q bo'lib chiqadi va MySQL har safar butun jadvalni boshidan oxirigacha ko'rib chiqadi.
Ko'p yozuvni tahlil qilish vositalari
Gavjum saytda log bir kunda minglab yozuvga yetadi va ularni qo'lda o'qish mumkin emas. MySQL bilan birga keladigan mysqldumpslow yordamchi dasturi o'xshash so'rovlarni bir guruhga yig'adi, raqam va satrlarni umumlashtiradi va ularni umumiy vaqt yoki chaqiruvlar soni bo'yicha saralaydi. Quyidagi buyruq umumiy vaqt bo'yicha eng og'ir o'nta so'rovni ko'rsatadi:
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
Chuqurroq tahlil uchun Percona Toolkit to'plamidagi pt-query-digest vositasi keng qo'llaniladi. U har bir so'rov guruhining umumiy vaqtdagi ulushini foizda ko'rsatadi, shuning uchun qaysi tuzatish eng katta foyda berishini darhol ko'rish mumkin. Ko'pincha bitta yoki ikkita so'rov bazadagi umumiy yukning katta qismini tashkil qilishi ma'lum bo'ladi.
Topilgan so'rovni EXPLAIN bilan tekshirish
Muammoli so'rov topilgach, uning bajarilish rejasini EXPLAIN buyrug'i bilan ko'rish kerak. Natijada type ustunida ALL yozilgan bo'lsa, bu butun jadvalni ko'rib chiqish demakdir, key ustuni bo'sh bo'lsa, hech qanday indeks ishlatilmagan. Extra ustunidagi Using filesort esa saralash xotirada yoki diskda alohida bajarilayotganini bildiradi:
EXPLAIN SELECT * FROM products
WHERE category_id = 17
ORDER BY created_at DESC LIMIT 24;
Ko'p holatda yechim filtrlash va saralash ustunlariga mos tarkibiy indeks qo'shishdir. Indeks qo'shilgach so'rovni qayta EXPLAIN bilan tekshiring va logda u qayta paydo bo'lmayotganiga ishonch hosil qiling.
Shared hostingda nima qilish mumkin
Shared hostingda server darajasidagi log sozlamalarini oddiy foydalanuvchi o'zgartira olmaydi, chunki ular barcha mijozlarga ta'sir qiladi. Bunday holatda ilova darajasidagi vositalar yordam beradi. WordPress uchun Query Monitor plagini har bir sahifada qaysi so'rov qancha vaqt olganini ko'rsatadi, Laravel va boshqa freymvorklarda esa o'z so'rov loglari va nosozliklarni tahlil qilish panellari bor. Muayyan sahifa bo'yicha aniq tahlil kerak bo'lsa, sayt.uz kabinetidan yoki texnik yordam orqali so'rov qoldirish mumkin.
Amaliy misol: mebel do'konining katalog sahifasi
Namangandagi mebel do'konining example.uz sayti bosh sahifada tez ochilardi, lekin kategoriya sahifalari besh-olti soniya yuklanardi. Kuchliroq tarifga o'tish rejalashtirilgan edi, ammo avval sekin so'rovlar logi bir kunga yoqildi. mysqldumpslow natijasi ko'rsatdiki, kechikishning deyarli hammasi yuqorida ko'rganimizga o'xshash bitta so'rovdan kelmoqda: mahsulotlar jadvali kategoriya va sana bo'yicha indekssiz qidirilardi.
Ikki ustunli indeks qo'shilgach, so'rov vaqti uch soniyadan bir necha millisekundgacha tushdi va kategoriya sahifalari bir soniyadan tez ochila boshladi. Hosting tarifini o'zgartirish kerak bo'lmadi. Shundan so'ng do'kon egasi logni yoqilgan holda qoldirib, har hafta eng og'ir so'rovlar ro'yxatini ko'zdan kechiradigan bo'ldi, shunda yangi plagin yoki o'zgarish qo'shilganda muammo darhol ko'rinadi.