Долгое время в рассылке медленных логов от 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!