hudson Сообщение 07/10/2009 22:52 Копия темы
mysqldump и /*!40001 SQL_NO_CACHE */ Долгое время в рассылке медленных логов от 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!

// репост из моего блога dbykadorov.livejournal.co../