Долгое время в рассылке медленных логов от maatkit меня тревожила запись вида:
# pct total min max avg 95% stddev median # Count 38 310 # Exec time 67 355s 0 85s 1s 992ms 8s 0 # Lock time 0 0 0 0 0 0 0 0 # Rows sent 99 10.57M 0 2.66M 34.93k 65.68k 223.39k 9.83 # Rows exam 60 10.57M 0 2.66M 34.93k 65.68k 223.39k 9.83 # Users 1 dbusr # Databases 3 d1 (4), d2 (2), d3(1) # Time range 2009-10-07 08:00:02 to 2009-10-07 16:02:38 # Query_time distribution # 1us # 10us # 100us # 1ms # 10ms # 100ms # 1s ################################################################ # 10s+ ########################## # Tables # SHOW TABLE STATUS FROM `d1` LIKE 'tbl_n'G # SHOW CREATE TABLE `d1`.`tbl_n`G SELECT /*!40001 SQL_NO_CACHE */ * FROM `tbl_n`G # Converted for EXPLAIN # EXPLAIN SELECT /*!40001 SQL_NO_CACHE */ * FROM `tbl_n`G
Пренеприятнейший лог надо вам сказать. Какая-то зараза выбирает до 2.66M записей разом (за половину суток > 10М). И так каждый день. Собственно забивать закрывать глаза на эту проблему помогал тот факт что на сервисе и нагрузке это вроде бы никак не отражалось.
Однако стоило приглядеться и картина стала ясной.
1. факт – большой разброс макс-мин-95% строк за выборку: 2.66M – 34.93k – 65.68k
2. факт – mk-query-digest агрегирует схожие запросы
Виновником этой строки стал mysqldump (что и было проверено и подтверждено визуально слежением за slow-log во время дампа).
p.s. спасибо munin и maatkit за наш спокойный сон )
hth!