MySQL slow query log: ჩართე, წაიკითხე, გაასწორე ის, რასაც პოულობს

slow query log იწერს ყოველ ბრძანებას, რომელსაც long_query_time წამზე მეტი დასჭირდა: რამდენ ხანს გაგრძელდა, რამდენი ხაზი დაათვალიერა და რამდენი დააბრუნა. ნაგულისხმევად გამორთულია, და მის ჩასართავად restart არ გჭირდება:

SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 0.5;SET GLOBAL log_output = 'FILE';SHOW VARIABLES LIKE 'slow_query_log_file';

დატოვე ჩართული ჩვეულებრივი დღის განმავლობაში, შეაჯამე mysqldumpslow -s t -t 10-ით, რომ იპოვო ბრძანებების ის ათი ფორმა, რომლებიც ჯამში ყველაზე მეტ დროს ხარჯავს, და გაასწორე ისინი სათითაოდ - თითქმის ყოველთვის index-ით, ზოგჯერ query-ის გადაწერით. ორი ხაფანგია: ახალი long_query_time მხოლოდ იმ კავშირებზე მოქმედებს, რომლებიც შეცვლის შემდეგ გაიხსნა, ხოლო ნაგულისხმევი ზღვარი, ათი წამი, იმდენად მაღალია, რომ თითქმის ვერაფერს იჭერს, რაც ვებ აპლიკაციისთვის მნიშვნელოვანია.

ეს სახელმძღვანელო MySQL 8.0-სა და 8.4 LTS-ს ფარავს: პარამეტრებს, ლოგის ფორმატს, ინსტრუმენტებს, რომლებიც მას აჯამებს, რა უნდა ქნა, როცა ლოგის ფაილამდე ვერ აღწევ, და იმ პრობლემების გამოსწორებას, რომლებსაც ის ჩვეულებრივ ამჟღავნებს.

პარამეტრები#

ყველა მათგანი დინამიკურია, ასე რომ SET GLOBAL restart-ის გარეშე მუშაობს, ხოლო SET PERSIST მნიშვნელობას restart-ების შემდეგაც ინახავს. გლობალური ცვლადების შეცვლას SYSTEM_VARIABLES_ADMIN სჭირდება, რომელიც root ანგარიშს აქვს, აპლიკაციის მომხმარებელს კი - არა.

long_query_time-ის არჩევა

ათ წამს აზრი ჰქონდა 2005 წლის batch ანგარიშებისთვის. ვებ აპლიკაციისთვის, სადაც გვერდი რამდენიმე ასეულ მილიწამში უნდა მზად იყოს, ეს ნიშნავს, რომ ლოგი ცარიელი რჩება, სანამ მომხმარებლები ელოდებიან. გონივრული საწყისი წერტილები:

• ვებ აპლიკაცია ან API: 0.5-დან 1-მდე. მოთხოვნის გზაზე ნახევარ წამზე მეტი ყველაფერი ღირს, რომ იცოდე.
• ფონური ამოცანები და ანგარიშები: 2-დან 5-მდე, ან გაუშვი ისინი ცალკე ანგარიშით და ცალკე შეხედე.
• მოკლე, განზრახ ჩაწერა: 0 ყოველ ბრძანებას ლოგავს. სასარგებლოა ათი წუთით, რომ გვერდის ჩატვირთვის სრული სურათი დაინახო; საშიშია ჩართულად დატოვება, რადგან ყოველ query-ს დისკზე წერს.

ხაფანგი, რომელიც ყველას აბნევს: long_query_time-ს session-ის მნიშვნელობა აქვს, რომელიც გლობალურიდან კოპირდება კავშირის გახსნისას. connection pool-ის მქონე აპლიკაციამ შეიძლება კავშირები საათობით შეინარჩუნოს, და ეს კავშირები ძველ ზღვარს ინარჩუნებს. ან გადატვირთე აპლიკაცია შეცვლის შემდეგ, ან დაელოდე, სანამ pool კავშირებს განაახლებს. log_queries_not_using_indexes და თავად slow_query_log ყველასთვის მაშინვე მოქმედებს.

log_queries_not_using_indexes სასარგებლოდ ჟღერს და ძირითადად ხმაურია: ის ლოგავს ყოველ query-ს ათხაზიან lookup ცხრილზე და ყოველ SELECT COUNT(*)-ს პატარა ცხრილზე. თუ ჩართავ, დააწყვილე min_examined_row_limit = 1000-თან, რომ მხოლოდ რეალური ზომის scan-ები ჩაიწეროს, და log_throttle_queries_not_using_indexes-თან, რომ ერთმა ცხელმა query-მ ფაილი ვერ დატბოროს.

ჩანაწერის კითხვა#

# Time: 2026-10-08T14:02:11.482913Z# User@Host: app[app] @  [198.51.100.7]  Id:    42# Query_time: 2.481920  Lock_time: 0.000004 Rows_sent: 20  Rows_examined: 1840022use appdb;SET timestamp=1791468131;SELECT id, title, created_at FROM postsWHERE status = 'published' ORDER BY created_at DESC LIMIT 20 OFFSET 36000;

ყოველ ხაზს თავისი მინიშნება აქვს:

• Query_time შესრულების რეალური დროა. ის მოლოდინში გატარებულ დროსაც მოიცავს, ასე რომ სხვა ტრანზაქციის უკან დაბლოკილი ბრძანება ნელი ჩანს, მაშინაც კი, თუ მისი საკუთარი სამუშაო უმნიშვნელოა.
• Lock_time lock-ების მოპოვებაზე დახარჯული დროა. როცა ის Query_time-ის უმეტეს ნაწილს შეადგენს, query კონკურენციის მსხვერპლია და არა მიზეზი - შეხედე, რას ეჭირა lock, რაც ტრანზაქციებში, lock-ებსა და deadlock-ებშია აღწერილი.
• Rows_sent და Rows_examined-ის თანაფარდობა ყველაზე სასარგებლო ერთი რიცხვია. ოცი გაგზავნილი ხაზი 1.8 მილიონ დათვალიერებულზე ნიშნავს, რომ სერვერმა თითქმის ყველაფერი წაიკითხა და გადააგდო. კარგი query იმაზე ცოტა მეტს ათვალიერებს, რასაც აბრუნებს.
• User@Host გეუბნება, რომელმა აპლიკაციამ ან ამოცანამ გამოგზავნა, რაც მნიშვნელოვანია, როცა რამდენიმე ერთ სერვერს იზიარებს.

log_slow_extra = ON-ით ყოველი ჩანაწერი იღებს ისეთ ველებს, როგორიცაა Thread_id, Errno, Bytes_received, Bytes_sent, Read_first, Read_key, Read_next, Sort_merge_passes, Sort_rows, Created_tmp_tables და Created_tmp_disk_tables, რომლებიც sort-ზე მძიმე query-ს scan-ზე მძიმისგან ასხვავებს ხელახლა გაშვების გარეშე. ჩართე; ლოგი უფრო განიერი ხდება, მაგრამ ფასი უმნიშვნელოა.

ზემოთ მოყვანილი მაგალითი კლასიკაა: ღრმა OFFSET პაგინაცია. MySQL-ს 36 000 ხაზის წაკითხვა და გადაგდება უწევს, რომ 20 დააბრუნოს, და არქივის მე-2000 გვერდი პირველზე ზუსტად ამდენით ნელია. გამოსწორება ბოლო სექციაშია.

შეჯამება mysqldumpslow-ით#

ერთი დღის ლოგი შეიძლება ათასობით ჩანაწერს შეიცავდეს, რომელთა უმეტესობა იგივე რამდენიმე ბრძანებაა სხვადასხვა მნიშვნელობით. mysqldumpslow, Perl სკრიპტი, რომელიც MySQL სერვერს მოჰყვება, მათ ფორმის მიხედვით აჯგუფებს - რიცხვებს N-ით ცვლის, სტრიქონებს 'S'-ით - და აჯამებს:

# Top 10 by total time: the queries that cost you the most overall$ mysqldumpslow -s t -t 10 /var/lib/mysql/db-slow.log# Top 10 by count: the ones that run constantly$ mysqldumpslow -s c -t 10 /var/lib/mysql/db-slow.log# Only statements touching the orders table$ mysqldumpslow -s t -g 'orders' /var/lib/mysql/db-slow.log

Count: 1412  Time=1.84s (2598s)  Lock=0.00s (0s)  Rows=20.0 (28240), app[app]@[198.51.100.7]  SELECT id, title, created_at FROM posts  WHERE status = 'S' ORDER BY created_at DESC LIMIT N OFFSET N

პირველ რიგში ჯამური დროით დაალაგე (-s t). query, რომელსაც დღეში ერთხელ 30 წამი სჭირდება, ნაკლებად მნიშვნელოვანია, ვიდრე ის, რომელსაც 0.6 წამი სჭირდება დღეში 4000-ჯერ, და სწორედ ჯამური დრო აყენებს მათ სწორ რიგზე. ფრჩხილებში მოცემული რიცხვები ჯამებია; მათ გარეთ - საშუალოები.

pt-query-digest Percona Toolkit-იდან იმავე საქმეს უფრო დეტალურად აკეთებს - პროცენტილებით, query-ის fingerprint ID-ით, EXPLAIN-ის შემოთავაზებებით - და ღირს მისი დაყენება, თუ ლოგებს ხშირად აანალიზებ. ორივე ინსტრუმენტს სჭირდება ფაილი იმ მანქანაზე, სადაც მათ გაუშვებ; ჩამოიტანე SFTP-ით ან scp-ით, ნაცვლად იმისა, რომ ანალიზი პატარა ბაზის სერვერზე გაუშვა.

როცა ლოგის ფაილს ვერ კითხულობ#

ჰოსტინგზე განთავსებულ ბაზაზე შეიძლება shell ბაზის მანქანაზე არ გქონდეს. ორ გზას ის არ სჭირდება.

ლოგი ცხრილში. log_output = 'TABLE'-ით ჩანაწერები mysql.slow_log-ში მიდის, რომლის წაკითხვაც SQL-ით შეიძლება:

SET GLOBAL log_output = 'TABLE';SET GLOBAL slow_query_log = ON;SELECT start_time, query_time, rows_sent, rows_examined, LEFT(sql_text, 200) AS queryFROM mysql.slow_logORDER BY query_time DESCLIMIT 20;

ცხრილი CSV engine-ს იყენებს, index-ები არ აქვს და იზრდება, სანამ TRUNCATE TABLE mysql.slow_log-ით არ დააცარიელებ. ერთი დღის ჩაწერისთვის კარგია, თვეობით ჩართულად დასატოვებლად - არა.

performance_schema-ის digest-ები. MySQL უკვე აჯამებს ყოველ ბრძანებას ფორმის მიხედვით performance_schema-ში, slow log ჩართულია თუ არა, ყოველგვარი ზღვრის გარეშე. ეს ხშირად ლოგზე უკეთესია, რადგან იჭერს სწრაფ query-ს, რომელიც მილიონჯერ ეშვება:

SELECT schema_name,       count_star                          AS calls,       ROUND(sum_timer_wait / 1e12, 1)     AS total_s,       ROUND(avg_timer_wait / 1e9, 1)      AS avg_ms,       sum_rows_examined, sum_rows_sent,       LEFT(digest_text, 120)              AS queryFROM performance_schema.events_statements_summary_by_digestWHERE schema_name = 'appdb'ORDER BY sum_timer_wait DESCLIMIT 10;

ტაიმერის მნიშვნელობები პიკოწამებშია, აქედან გაყოფები. sys სქემა იმავე მონაცემებს უფრო მოსახერხებელ view-ებში ახვევს: sys.statement_analysis (ყველაფერი, ჯამური დაყოვნებით დალაგებული), sys.statements_with_full_table_scans, sys.statements_with_sorting, sys.statements_with_temp_tables და sys.statements_with_runtimes_in_95th_percentile. მთვლელები ნულდება სერვერის restart-ისას ან მოთხოვნით, TRUNCATE TABLE performance_schema.events_statements_summary_by_digest-ით, რაც „მანამდე“ და „შემდეგ“-ის სუფთად გაზომვის გზაა.

RE:NODE-ზე root პაროლი ყოველი MySQL სერვერისთვის შენთვის გენერირდება, ასე რომ ორივე გზა ვინმესთვის თხოვნის გარეშე ხელმისაწვდომია: SET GLOBAL slow log-ის პარამეტრებისთვის და სრული წაკითხვის წვდომა performance_schema-სა და sys-ზე.

იმის გასწორება, რასაც პოულობს#

ჩანაწერების უმეტესობას ერთი და იგივე რამდენიმე მიზეზი ხსნის.

გამოსადეგი index არ არის. Rows_examined ასობით ათასებში, EXPLAIN აჩვენებს type: ALL-ს ან სუსტ ref-ს. დაამატე index, რომელიც WHERE-სა და ORDER BY-ს ემთხვევა, ტოლობის სვეტები პირველად. MySQL-ის index-ები და EXPLAIN აღწერს, როგორ დააპროექტო და როგორ დაადასტურო, რომ იმუშავა.

ღრმა OFFSET პაგინაცია. LIMIT 20 OFFSET 36000 36 020 ხაზს კითხულობს. შეცვალე keyset პაგინაციით: დაიმახსოვრე ბოლო ხაზის დალაგების მნიშვნელობა და იქიდან გააგრძელე.

-- Instead of OFFSET, continue after the last row the user sawSELECT id, title, created_at FROM postsWHERE status = 'published'  AND (created_at < '2026-03-14 09:12:00'       OR (created_at = '2026-03-14 09:12:00' AND id < 88213))ORDER BY created_at DESC, id DESCLIMIT 20;

(status, created_at, id)-ზე index-ით ყოველი გვერდი იმავე ოც ხაზს ჯდება.

ფუნქციები index-ირებულ სვეტებზე. WHERE DATE(created_at) = '2026-10-08' ვერ გამოიყენებს index-ს created_at-ზე. გადაწერე დიაპაზონად: created_at >= '2026-10-08' AND created_at < '2026-10-09'.

**SELECT * განიერ ცხრილებზე.** ყველა სვეტის წაკითხვა, დიდი TEXT და JSON ჩათვლით, როცა გვერდი სამს აჩვენებს. დაასახელე სვეტები; სწორი index-ით query შეიძლება covering გახდეს და ცხრილს საერთოდ აუაროს გვერდი.

`ORDER BY RAND()`. ყოველ ხაზს შემთხვევით მნიშვნელობას უგენერირებს და ყველას ალაგებს. „შემთხვევითი რჩეული ელემენტისთვის“ შემთხვევითი ID აპლიკაციაში აირჩიე, ან წინასწარ არეულ პატარა ცხრილში გადაიტანე.

დიდი ცხრილების დათვლა. SELECT COUNT(*) FROM events მილიონობით ხაზიან InnoDB ცხრილზე ყოველ ჯერზე index-ს ათვალიერებს, რადგან InnoDB ხაზების ზუსტ რაოდენობას არ ინახავს. დაქეშე რიცხვი, აწარმოე მთვლელი, ან აჩვენე შეფასება information_schema.tables-იდან.

lock-ის მოლოდინი. მაღალი Lock_time, ან Query_time ბევრად მეტი, ვიდრე EXPLAIN ANALYZE აჩვენებს, როცა მარტო უშვებ. query სხვა ტრანზაქციას ელოდება. იპოვე გრძელი ტრანზაქცია sys.innodb_lock_waits-ში ან information_schema.innodb_trx-ში და ტრანზაქციები მოკლე შეინარჩუნე.

N+1 ნიმუში. slow log-ში არასოდეს ჩანს, რადგან ყოველი query სწრაფია. digest ცხრილში ჩნდება როგორც ერთი ბრძანება უზარმაზარი count_star-ით - იგივე SELECT ... WHERE post_id = ?, რომელიც სიის ყოველ ხაზზე ერთხელ ეშვება. გაასწორე აპლიკაციაში join-ით ან IN (...) batch-ით.

ერთდღიანი გამოძიება, ნაბიჯ-ნაბიჯ#

როცა ვინმე ამბობს „საიტი ნელია“ და არავინ იცის რატომ, ეს რუტინა საჩივრიდან მიზეზამდე ერთ დღეში მიდის გამოცნობის გარეშე.

1. აიღე საწყისი მდგომარეობა. გაანულე digest-ის მთვლელები TRUNCATE TABLE performance_schema.events_statements_summary_by_digest-ით, რომ ხვალ წაკითხული რიცხვები მხოლოდ დღევანდელ დღეს მოიცავდეს.
2. ჩართე slow log ზღვარზე, რომელსაც შენი მომხმარებლები შეამჩნევდნენ - ვებსაიტისთვის 0.5 - log_slow_extra = ON-ით, და გადატვირთე აპლიკაცია ან დააცალე მის pool-ს განახლება, რომ კავშირებმა ახალი მნიშვნელობა აიღონ.
3. დატოვე დღის ყველაზე დატვირთულ ნაწილში. ღამის სამ საათზე გაკეთებული ჩაწერა backup ამოცანას იპოვის და მეტს არაფერს.
4. დაალაგე ჯამური დროით, mysqldumpslow -s t-იდან ან digest query-დან. ჩაიწერე ბრძანებების ხუთი ყველაზე მძიმე ფორმა მათი გამოძახებების რაოდენობითა და საშუალო დროით.
5. თითოეულისთვის აიღე ერთი რეალური მაგალითი ლოგიდან - მისი რეალური პარამეტრების მნიშვნელობებით, რადგან გეგმა შეიძლება განსხვავდებოდეს მომხმარებელს შორის, რომელსაც ხუთი შეკვეთა აქვს, და მას შორის, რომელსაც ორმოცდაათი ათასი - და გაუშვი მასზე EXPLAIN ANALYZE.
6. დაახარისხე: დაკარგული index, არასწორი index, query-ის ფორმა (offset, ფუნქცია სვეტზე, SELECT *), lock-ის მოლოდინი, ან კანონიერად მძიმე სამუშაო, რომელსაც ქეშირება ან შემაჯამებელი ცხრილი სჭირდება.
7. გაასწორე პირველი, გააკეთე deploy და შეამოწმე მისი digest-ის რიცხვები მეორე დღეს, სანამ მეორეზე გადახვალ.

რიგს იმაზე მეტი მნიშვნელობა აქვს, ვიდრე ჩანს. ერთი ბრძანების გასწორება ხშირად დანარჩენების სურათს ცვლის: დაკარგულმა index-მა, რის გამოც ერთი query ცხრილს ათვალიერებდა, მას buffer pool-იც მძევლად დააჭერინა და სხვა query-ების გვერდები მეხსიერებიდან გამოდევნა. ის სხვა query-ები ხელის შეუხებლად ჩქარდება, და მათ პირველად ოპტიმიზაციაზე ძალისხმევას ტყუილად დახარჯავდი.

ღირს იმის შემოწმებაც, ამ ყველაფრამდე, რომ დრო მართლაც ბაზაში იხარჯება. თუ ნახევარწამიანი ზღვრით ერთი დღის ლოგირებისას ყველაზე ნელი ბრძანება 0.6-წამიანი ანგარიშია, გვერდების ოთხწამიანი ჩატვირთვის მიზეზი ბაზა არ არის; შეხედე აპლიკაციას, გარე API გამოძახებებს ან სერვერის CPU-ს. slow log ბაზის გამორიცხვისთვისაც ისეთივე სასარგებლოა, როგორც მასში პრობლემის საპოვნელად.

როგორ არ აქციო ლოგი პრობლემად#

დაბალი ზღვრის slow log დატვირთულ სერვერზე სწრაფად იზრდება, და 10 ან 20 GB volume-ზე დავიწყებული ლოგი დისკის შევსების რეალური გზაა. მოახდინე მისი როტაცია:

$ mv /var/lib/mysql/db-slow.log /var/lib/mysql/db-slow.log.1$ mysql -u root -p -e "FLUSH SLOW LOGS;"

FLUSH SLOW LOGS ფაილს ხურავს და თავიდან ხსნის, ასე რომ MySQL ახალს იწყებს თავდაპირველი სახელით. logrotate-იან სისტემაზე ამ ბრძანებით postrotate-ის მქონე ბლოკი ამას ყოველ ღამე აკეთებს. ფაილზე წვდომის გარეშე გამორთე ლოგი, როცა გამოძიება დასრულდება (SET GLOBAL slow_query_log = OFF), და დააცარიელე mysql.slow_log, თუ ცხრილი გამოიყენე.

გონივრული მუდმივი პარამეტრები პატარა სერვერზე: slow log ჩართული, ზღვარი ერთ წამზე, log_slow_extra ჩართული, log_queries_not_using_indexes გამორთული, და კვირაში ერთხელ mysqldumpslow-ის ან digest view-ის ნახვა. ეს თითქმის არაფერი ჯდება და „საიტი ნელი ჩანს“-ს სიად აქცევს. ლოგები, რომელთა შენახვაც ღირს და მონიტორინგი, რომელიც რაღაცას გეუბნება მას იმ ყველაფრის გვერდით აყენებს, რაც უნდა შეაგროვო, ხოლო ნელი სერვერის მეხსიერების მხარე InnoDB-ის მორგებაშია პატარა სერვერებისთვის.

FAQ#

ანელებს თუ არა slow query log MySQL-ს?

გონივრულ ზღვარზე - თითქმის არა: საათში რამდენიმე ასეული ჩანაწერის ჩაწერა არაფერია. long_query_time = 0-ზე დატვირთულ სერვერზე ის ყოველ ბრძანებას წერს, რაც დისკის I/O-სა და ადგილს ხარჯავს, ამიტომ ეს მოკლე ჩაწერებისთვის შეინახე. log_output = 'TABLE' ფაილზე ოდნავ ნელია.

long_query_time დავაყენე, მაგრამ არაფერი იწერება. რატომ?

ჩვეულებრივ იმიტომ, რომ აპლიკაციის კავშირები ცვლილებამდე გაიხსნა და ისევ ძველ session-ის მნიშვნელობას ატარებს. გადატვირთე აპლიკაცია ან დაელოდე, სანამ მისი pool განახლდება. ასევე შეამოწმე, რომ slow_query_log არის ON, რომ min_examined_row_limit ყველაფერს არ ფილტრავს, და რომ იმ ფაილს უყურებ, რომელიც slow_query_log_file-შია დასახელებული.

შემიძლია ნელი query-ები მხოლოდ ერთი მომხმარებლისთვის დავლოგო?

მომხმარებლის დონის პარამეტრით - არა, მაგრამ შეგიძლია session-ის დონეზე შეცვალო: აპლიკაციას შეუძლია საკუთარ კავშირებზე გაუშვას SET SESSION long_query_time = 0.2 (session-ის მნიშვნელობისთვის განსაკუთრებული პრივილეგია არ სჭირდება), ხოლო ანგარიშების ამოცანას - უფრო მაღალი დააყენოს. შემდეგ მომხმარებლით გაფილტვრა ადვილია mysqldumpslow-ით ან mysql.slow_log-ის user_host სვეტით.

რა არის Rows_examined-ისა და Rows_sent-ის კარგი თანაფარდობა?

ძებნისა და სიის გვერდებისთვის - ერთნიშნა რიცხვებიდან დაბალ ათეულებამდე. აგრეგატები გამონაკლისია: SUM ერთი თვის შეკვეთებზე კანონიერად ბევრ ხაზს ათვალიერებს, რომ ერთი დააბრუნოს. მათთვის კითხვა ისაა, შეძლებდა თუ არა covering index ან შემაჯამებელი ცხრილი ამის ნაკლებით გაკეთებას.

slow query log იგივეა, რაც general log?

არა. general query log იწერს ყოველ ბრძანებას და ყოველ კავშირს, ნელია თუ არა, და ჩართულად დასატოვებლად ზედმეტად მძიმეა. slow log მხოლოდ ზღვარს გადაცილებულ ბრძანებებს იწერს, დროის მონაცემებით. general log რამდენიმე წუთით გამოიყენე, როცა ზუსტად უნდა დაინახო, რას აგზავნის აპლიკაცია.