помирает mysql 600мб

для начала

mysqltuner.pl

данные на диск - лучшее что можно, как уже в списке есть - репликацию настроить , мастер-слейв и на другой машине дампить со спокойной душой.

всё остальное - не имеет по моему никакого практического смысла пока не выясните что тормозит. mysql slow log в помощь, конечно, но он не очень крутой.

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

почитаю про перловый скрипт, спасибо. както он попадался на глаза но чтото я побоялся запускать, в основном изза смешаности типа таблиц (innodb и myisam в одной базе)

slowlog посмотрю. ноо чем мне это поможет? ну узнаю я какие запросы грузят систему, переписать то я их не смогу( не дадут.

или это нужно чтобы оценить целесообразность переноса базы в рамдиск?

ну, вы поглядите на запросы то. может действительно индексы помогут. Это ведь из запроса понятно. Берём медленный запрос, делаем ему explain. Смотрим, отчего он медленный. Делаем выводы. Иногда можно индексы поставить, иногда переписывать надо.. как повезёт

вот только mysql slow log не очень умный, он просто дампит все запросы которые висят больше определённоо времени. А они обычно висят из-за одного, который залочил таблицы. И добраться до него бывает непросто.

Но тем не менее.

KRoN73,емпни, тут недавно разбирался с этим, может посоветует чего

есть ли особые настройки my.cnf или дефолтных хватит?

однозначно нужно тюнить
если не знаете какие-параметры, как выше советовали - перловский скрипт

Во время заливки базы на проблемном компе посмотреть в процессах что тормозит

Если дело не в железе то этого мануала по оптимизации должно хватить https://habrahabr.ru/post/108418/

RAM диск в этой ситуации не решение. У тебя 24 гига рамы и база целиком туда влезает, по идее все должно закэшироваться туда само. Если этого не происходит - надо разбираться с настройками движка, что в нем не так. Ну и еще вариант - ты недоговариваешь и на этом серваке еще 100500 баз крутится которые отъедают ресурсы.

НО допустим бекап базы разворачивающйися на томже сервере в соседнюю базу занимает часы

Вот это звонок для меня, что никакие индексы тебе не помогут, что-то очень не в порядке с настройками движка, системы. Интересно посмотреть на top в момент бэкапа, если оно все время сидит в IO, то тут варианты -

a) ты недоговариваешь и на серваке куча баз которые не помещаются в память и оно всегда бегает по диску, памяти не хватает, FS кэш маленький, короче все время на IO медленного диска, это отягощалось бы неоптимальными настойками MySQL и неоптимальными запросами.

б) баз немного, памяти предостаточно, но оно все равно бегает по диску - какие-то адово дурацкие настройки MySQL, которые не дают ему все поднять в память.

в) IO низкое, а запросы выполняются долго - это сомнительный вариант, тогда да, запросы плохие, но я отметают этот вариант из-за коммента про долгий бэкап.

г) Даже если настройки MySQL заставляют его ходить в диск, то непонятно, что происходит с Linux самим в этой ситуации, потому что в нормальной ситуации он тоже кэширует все в VFS кэше. Если только какие-то настройки не заставляют его или MySQL fsync-аться на каждый чих. (что в принципе возможно если кто-то пытается делать миллионы и миллионы транзакций на этой базе, но все равно чтение должно быть довольно быстрым)

д) HDD у тебя не локальный, а сетевой, много транзацкий + дурацкие настройки, много fsync-ов, поэтому все время тратится на latency между этой машиной и сетевым HDD. Я такую проблему наблюдал в Azure, Jira там бегает примерно в 2 раза медленнее из-за этого (latency до базы + latency до диска где лежит Lucene индекс сильно большое)

В общем данных в твоем посте щас недостаточно, требуется исследование поведения.

Только одно ясно - только лишь дурацкими запросами такое железо как у тебя убить 600 мегабайтовой базой очень сложно.

спасибо за ответ. сегодня буду работать.

пока могу сказать следующее

1) на сервере 4 7.2kRPM диска собраны в один рейд MDADM. если просто копировать с диска на тотже диск файл обьемом 4 гб, то первая половина заливается на скорости 500-700мбайт\сек а дальше падает до 100-150мбайт\сек

cat /etc/mdadm.conf 
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md0 level=raid1 num-devices=4 UUID=e99dbfcc:0edc178e:8d900598:71a4fb4d
ARRAY /dev/md1 level=raid10 num-devices=4 UUID=39aebdf6:fdedbdb3:b4b41eaa:5b5ae78e
ARRAY /dev/md2 level=raid10 num-devices=4 UUID=07ff5293:db61252e:b4cb1a3f:78dbb183

система на md0, база на md2, md1 в системе не нашел.

2) я умолчал о одной базе, в томже мускуле но база отдельная. одна таблица, пара милионов строк, туда каждую секунду делается примерно 4 селекта, 1 апдейт и 1 инсерт. все значения инт или дататайм. селект делается по последним 50к записям. размер базы - 300мб.

3) iotop

в простое меняется значение только первого пункта, изменяется от 5% до 30% в среднем 5-10

теже показатели при запуске сложного отчета

Total DISK READ: 0.00 B/s | Total DISK WRITE: 153.03 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                    
 1123 be/3 root        0.00 B/s    0.00 B/s  0.00 %  7.05 % [jbd2/md2-8]
32695 be/4 mysql       0.00 B/s   47.82 K/s  0.00 %  0.99 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock --port=3306
32688 be/4 mysql       0.00 B/s  816.15 B/s  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock --port=3306
 9416 be/4 mysql       0.00 B/s  816.15 B/s  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock --port=3306
 1435 be/3 root        0.00 B/s  816.15 B/s  0.00 %  0.00 % auditd

а вот во время разворачивания бекапа тойже самой базы в соседнюю, на томже диске

Total DISK READ: 0.00 B/s | Total DISK WRITE: 10.91 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                    
 1123 be/3 root        0.00 B/s    0.00 B/s  0.00 % 65.83 % [jbd2/md2-8]
23301 be/4 mysql       0.00 B/s   10.05 M/s  0.00 %  6.86 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock --port=3306
  582 be/3 root        0.00 B/s    0.00 B/s  0.00 %  1.00 % [jbd2/md0-8]
32688 be/4 mysql       0.00 B/s    9.57 K/s  0.00 %  0.25 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock --port=3306
32695 be/4 mysql       0.00 B/s  115.59 K/s  0.00 %  0.13 % mysqld --basedir=/usr --datadir=/var/lib/mysql~ --socket=/var/lib/mysql/mysql.sock -

вот top в простое

top - 11:24:42 up 107 days, 23:18,  3 users,  load average: 1.61, 1.20, 1.36
Tasks: 276 total,   1 running, 275 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.0%us,  0.7%sy,  0.0%ni, 87.0%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  12155116k total,  9557016k used,  2598100k free,   317984k buffers
Swap: 30703612k total,    56416k used, 30647196k free,  7357624k cached
 Unknown command - try 'h' for help 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      
32685 mysql     20   0 1965m 174m 7032 S 99.8  1.5 580:48.38 mysqld                                                                                       
   36 root      20   0     0    0    0 S  0.3  0.0  27:32.37 events/1                                                                                     
19974 apache    20   0  306m  25m 8616 S  0.3  0.2   0:02.38 httpd                                                                                        
22095 apache    20   0  317m  38m 8832 S  0.3  0.3   0:01.86 httpd                                                                                        
23698 root      20   0 99.1m 4444 3332 S  0.3  0.0   0:00.05 sshd                         

при заупске скрипта

top - 11:23:26 up 107 days, 23:17,  3 users,  load average: 0.80, 0.99, 1.31
Tasks: 277 total,   1 running, 276 sleeping,   0 stopped,   0 zombie
Cpu(s): 27.5%us,  1.7%sy,  0.0%ni, 70.1%id,  0.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12155116k total,  9564608k used,  2590508k free,   317932k buffers
Swap: 30703612k total,    56416k used, 30647196k free,  7357472k cached
 Unknown command - try 'h' for help 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      
32685 mysql     20   0 1965m 176m 7032 S 232.8  1.5 578:21.43 mysqld                                                                                      
23587 root      20   0 98.9m 4320 3320 S  1.0  0.0   0:00.03 sshd                                                                                         
 8650 root      20   0  100m  728  612 S  0.3  0.0   0:04.56 ping           

при разворачивании бекапа базы

top - 11:25:51 up 107 days, 23:19,  3 users,  load average: 1.49, 1.21, 1.35
Tasks: 277 total,   1 running, 276 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.3%us,  0.6%sy,  0.0%ni, 80.0%id, 12.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12155116k total,  9540372k used,  2614744k free,   318012k buffers
Swap: 30703612k total,    56416k used, 30647196k free,  7333108k cached
 Unknown command - try 'h' for help 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      
32685 mysql     20   0 1965m 174m 7032 S 57.9  1.5 581:33.71 mysqld                                                                                       
23801 root      20   0 61888 5500 2504 S  4.3  0.0   0:00.52 mysql                                                                                        
  964 root      20   0     0    0    0 S  0.7  0.0 458:07.64 md2_raid10                                                                                   
  360 root      20   0  195m  10m 1572 S  0.3  0.1   0:15.68 supervisord                                                                                  
23515 root      20   0 15156 1484 1008 R  0.3  0.0   0:00.34 top                                                                                          
23809 root      20   0 99.1m 4436 3332 S  0.3  0.0   0:00.03 sshd                                                                                         
32393 apache    20   0 98380 5948 1948 S  0.3  0.0   0:05.26 nginx                                                                                        
     

вот my.cnf изначально все буферы которые сейчас 256мб были по 8 но работало при этом также

[client]
port		= 3306
socket		= /var/lib/mysql/mysql.sock


[mysqld]
port		= 3306
socket		= /var/lib/mysql/mysql.sock
skip-locking
key_buffer_size = 256M
max_allowed_packet = 256M
table_open_cache = 400
sort_buffer_size = 256M
read_buffer_size = 32M
read_rnd_buffer_size = 4M
net_buffer_length = 2K
thread_stack = 128K
interactive_timeout=360
wait_timeout=360
max_connections = 400

server-id	= 1


[mysqldump]
quick
max_allowed_packet = 256M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M

[mysqlhotcopy]
interactive-timeout

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.

В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.

Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.

А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).

на правах «получуши для идей (ака брейншторминг)»: скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?

диск файл обьемом 4 гб, то первая половина заливается на скорости 500-700мбайт\сек а дальше падает до 100-150мбайт\сек

это он сначала кеширует в память, а потом начинает ждать записи на диск (видно кеш гдето 2гб по дефолту).

Лучше нормально потюнить мускуль, чем держать базу в рамдиске. Держать базу в рамдиске мб хорошее решение для мускуля в винде (и то не факт), но не в линуксе.

а кстати, пользователь mysql один и тот же для обеих (всёх трёх) баз?

я не специалист по мускулу но как идея - может там есть лимиты на пользователя (типа кеши, коннекшны и т.п.) и может быть они не позволяют разворачивать базу из бекапа паралельно, если пользователь тот же.

Только одно ясно - только лишь дурацкими запросами такое железо как у тебя убить 600 мегабайтовой базой очень сложно.

кстати, не так уж, по опыту. один-два декартовых джойна чего нить в пару сотен тысяч строк без «задних мыслей» и всё лежит. если я верно помню, давно дело было.

Есть возможность заменить HDD на SSD? Четыре штуки в raid 10 дадут хорошую скорость. А уж если NVMe поставить, то вообще шик. Ну и mysqltuner прогнать.

LOR reply

Перво-наперво хочу сказать, что вывод твоего top-а меня беспокоит, согласно ему у тебя 12 гигов памяти, а не 24. Теперь по статистике которую я вижу: При запуске скрипта у нас вот это

Cpu(s): 27.5%us, 1.7%sy, 0.0%ni, 70.1%id, 0.6%wa, 0.0%hi, 0.1%si, 0.0%st

Ну тут все ясно, оно уперлось в CPU, запросы скорее всего довольно тяжелые, отсутствие индексов ситуацию ухудшит, засовывать это дело в RAM диск не поможет - оно вообще почти ничего не ждет с диска, все торчит в обработке. Лучшее, что тут можно сделать - это включать slow query log и вдумчиво анализировать запросы которые там есть. Может быть стоит накрутить индексов в каких-то таблицах. Если решишь добавить индексов - будь осторожен, подумай о том насколько активно в эти таблицы добавляются данные. Если в таблицы идет очень много insert-ов и update-ов, то добавление индексов замедлит такие запросы, если таблицы используются в основном для чтение - смело крути индексы и сравнивай производительность, удалить их всегда сможешь. Еще совет - в логе медленных запросов смотри на комбинации полей которые используются для фильтрации данных. Грубо говоря если видишь что-то вроде WHERE foo=‘blah’ and bar=‘not so blah’ значит тебе и индекс лучше всего создавать с двумя полями, именно вот в таком порядке как оно встречается в запросе, иначе планировщик запросто может такой индекс проигнорировать. Посмотри, есть ли сортировки по большим выборкам. Я не помню есть ли у мускула сортированные индексы, но вот у постгры есть, поэтому если у мускула они тоже есть, создание таких индексов может сильно облегчить такие запросы.

что посоветуете по оптимизации базы? кроме индексов.

Я так читаю, что ты не хочешь создавать индексы, для этого есть причина или это я неправильно читаю?

Еще у нас есть вот это:

1123 be/3 root 0.00 B/s 0.00 B/s 0.00 % 65.83 % [jbd2/md2-8]

Это меня немного напрягло, неужели оно может быть настолько медленным, что убьет производительность базы? (Меня это беспокоит, потому что я такое уже видал - у одного канадского телеоператора база на диск писала медленнее чем у меня дома торрент качал)

С другой стороны:

Total DISK READ: 0.00 B/s | Total DISK WRITE: 10.91 M/s

Вот я не помню, а в ман лезь лень, это мегабиты или мегабайты? В любом случае значение низковато, даже просто копирование 600 метров займет от часа до 10 такими тэмпами. I/O Wait в top-е я большого не вижу, то есть дело наверное в чем-то другом, например блокировках, следовательно:

Как уже выше спросили - а бэкап делается от какого пользователя, от того же самого или другого? Как вообще делается бэкап? Вот эта соседняя база она совсем независима?

Я попробую накидать несколько мыслей на счет конфигурирования, я разделю их на две категории: потенциально может улучшить чтение и потенциально можно улучшить запись, сам решай к какой базе их применить.

Чтение:

innodb_buffer_pool_size должен быть большим. Прям реально большим, что бы твои базы туда влезали. То есть в твоем случае - пару гигов. Официальная дока вообще говорит о 50%-75% системной памяти

Для оптимизации этих отчетов, я бы рекомендовал почитать вот это - https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html, я убежден там пачка сортировок и правильные значения в конфиге могут радикально помочь. Если проблемы с чтением басурманского - маякни, я оттуда перепишу тебе самое важное.

Запись:

ЭТО МОЖНО ДЕЛАТЬ ТОЛЬКО ЕСЛИ У ТЕБЯ НЕТ РЕПЛИКАЦИИ, если репликация включена, эта опция нарушит согласованность данных: выставить innodb_autoinc_lock_mode = 2 (“interleaved”), по дефолту, если в табличках используются автоинкрементные поля и есть инсерты с большим количеством вставляемых строк и база не может угадать сколько, она берет table lock, то есть блокируют всю табличку на запись. Если у тебя есть несколько параллельных вставок, то это значит что они все пойдут в один поток. Подробнее - https://dev.mysql.com/doc/refman/5.5/en/innodb-auto-increment-handling.html#i...

Убедись что innodb_adaptive_flushing НЕ выключена, подробнее - https://dev.mysql.com/doc/refman/5.5/en/innodb-performance-adaptive_flushing....

Возможно для той базы, которая принимает данные во время бэкапа имеет смысл выставить innodb-max-dirty-pages-pct в максимум, подробнее - https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_..., я бы не стал этого делать для продакшн базы в которой важно, что бы данные записались бы на диск. Хотя хз, может у тебя диски с батарейками и в случае отказа системы сами кэши на блины поскидывают =).

Один из важных параметров который я ожидаю может помочь больше всего: попробуй выставить innodb-flush-method в O_DSYNC подробности - https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_...

Можно попробовать увеличить вот это - innodb_io_capacity, но это 50 на 50, без анализа и SHOW ENGINE INNODB STATUS в момент нагрузки невозможно предсказать, поможет или нет.

На принимающей базе можешь попробовать увеличить bulk_insert_buffer_size, это может помочь, но только для MyISAM таблиц, я конечно не знаю структуру твоей базы, тут решай сам, подробности - https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_b...

О да, про декартовы джойны я и не подумал. Ну я пытаюсь сохранять хоть немного веры в людей =)

Забыл написать - innodb_log_file_size подтяни повыше, до пары гигов, тоже может помочь. Конечно если памяти у тебя хватает.

Еще есть тула mysqldumpslow, её можно натравить на лог медленных запросов и она его в более читаемый вид приведет, как-то так:

mysqldumpslow -t 10 mysql-slow-query.log > mysqldumpslow.out

и получается что-то вроде

Count: 109  Time=56.73s (6183s)  Lock=0.00s (0s)  Rows=3990419.2 (434955691), dbuser[dbuser]@localhost
  /* тут  запрос */

натравил перловый скрипт, ничего дельного кроме уменьшения буферов он не сказал.

включил слоулог. ну там появляется 1 запрос в минуту который висит секунду-две.

включил полный лог.

там 1.5к запросов в минуту на 1 отчет. в секунду около 10-50 запросов.

к базе идет обращение в 95% на селекты, и по 2.5 процента на инсерты\апдейты.

в базе половина таблиц innodb а вторая половина Myisam

что порекомендуете по конфигу в таком случае?

стоит ли наворачивать индексы если запросы проскакивают вроде как быстро? может проблема в пхп 5.1 ?

бекапы делаются от рута mysqldump -u root -p database1 >/root/databse1.sql

касательно конфигов. насколько корректно будет вносить в конфиг секции Innodb и myisam если в одной базе используется и то и другое. да и другая база есть где тоже самое.

мы както попробовали внести в конфиг настройки innodb и сайты не заработали, а те тчо заработали, только на полоивну.

с английским туго, максимум пойму общий смысл.

если есть возможность, скажите что поменять в конфиге(листинг выше) что нибуть что сильно влияет на производительность. но так чтобы не ушатать базу.

меня сильно смущает софтовый рейд на обычный 7200rpm western digital Дисках. мы запускали данный сайт сняв бекап на другом сервере и все летало, с дефолтными настройками mysql. правда там было

1) mariadb последняя а не mysql 5.1
2) php 5.6 и php7.0 а не php5.1
3) apache 24 или nginx а не apache 2.2( Не думаю что виноват он но всеже)
4) не было никаких рейдов, линейная скорость записи была нанмого ниже
5) не было доп скриптов нагружающих базу( если можно считать нагрузку в 2-3 дополнительных селекта\апдейта в секунду)

Очень похоже на железячную проблему, даже с урезанными кешами mysql все равно работал бы быстрее.

А по сему поднимайте дублирующий сервер, переносите все туда, и разбирайтесь с тормознутым. Ибо копать в чем всё-таки затык вы будете очень долго

Хотя, надо посмотреть iotop во время нагрузки и вообще выяснить где узкое место

меня сильно смущает софтовый рейд на обычный 7200rpm western digital Дисках. мы запускали данный сайт сняв бекап на другом сервере и все летало, с дефолтными настройками mysql

Это не должно влиять, если бы это было так, то в top-е высокие значения wait-а были бы, а этого нет. Если на что это и может влиять то только на _запись_ бэкапа в текущей ситуации.

Конфигурация: То, что у тебя в базе есть таблицы на разных движках не влияет на конфигурацию мускула.

Ну и как мы уже видели, для отчета _могут_ помочь индексы, даже если запросы визуально быстры. Индексы обычно всегда помогают, если сделаны правильно =).

А вот еще интересный эксперимент, можно запустить отчет и бэкап одновременно и показать вывод top-а и iotop-а?

запуск сайта на 7пхп вместо 5.1 ничего не изменил. думаю проблему php можно исключить.

вы просили какой бекап и сложный отчет(на 1500 селектов). бекап из базы в файл или из файла в базу(точно такуюже но с другим именем)?

ну там появляется 1 запрос в минуту который висит секунду-две.

это, кстати, неплохая ситуация (потому что сразу видно претендента). Возьмите запросы (разные) которые сдампились слоулогом. Возьмите тестовую базу. и в консоли (или в phpmyadmin-е) запустите эти запросы со словом explain.

т.е. будет что то вида

explain select field, field2 from ..

результат сюда запостите пожалуйста вместе с запросом.

но ведь это селект в другую базу и появляется он в слоулоге редко

+----+-------------+-------------------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table             | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+-------------------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | me | ALL  | NULL          | NULL | NULL    | NULL | 1789305 | Using where |
+----+-------------+-------------------+------+---------------+------+---------+------+---------+-------------+

в запросе поменял имена таблицы и полей, остальное неизменно

SELECT `me`.`field1`, `me`.`FIELD2`, `me`.`amount`, `me`.`dttm`, `me`.`trans`, `me`.`idT`, `me`.`account`, `me`.`idService`, `me`.`print`, `me`.`type`, `me`.`out`, `me`.`admin`, `me`.`dttm_add`, `me`.`action`, `me`.`add_other_base`, `me`.`dttm_other_base`, `me`.`add_base3`, `me`.`dttm_base3`, `me`.`val` FROM `me` WHERE `me`.`FIELD2` = '5539' AND `me`.`print` = 0 AND `me`.`admin` = 0;

думаю проблема не в этом запросе который раз в секунду а в других, которых по 1.5к в минуту

согласен, но на этом примере пойдём дальше, с вашего позволения:

видите, possible keys NULL и using where?

это значит он всю таблицу фильтрует каждый раз. я не помню уже что такое кей лен (key_len 1789305), но если в таблице много строк - это заметная нагрузка (и нагрузка тем больше чем больше строк, тут пом-оему будет O(n)). Если строк мало, то заморачиваться смысла нет. (select count(*) from me чтобы узнать сколько строк), но судя по тому что он весит больше секунды, там строк много.

индекс надо поставить на самое «разнообразное» поле из тех что встречаются в предложении where. Я думаю у вас там print имеет значение либо 0, либо 1. admin - либо 0, либо 1. А вот field2 похоже имеет много значений.

Добавьте индекс на field2 пожалуйста. и снова покажите эксплейн этого же запроса.

да, «мало строк», «много строк» - весьма относительные понятия. если запросов 1500 в секунду, то и 100 строк безусловно стоят того чтобы опставить индекс, но пока давайте там результат разберём.

развернул все тоже самое на сервере за 1.5 тысячи рублей (какойто ксеон, 4гб рам, умирающий жесткий диск)

первый прогон скрипта-отчета 2.5 минуты, последующие, с изменением параметров сортировки и выборки - 4 секунды

4 секунды карл...

на проде, 70-80 секунд в любых случаях ---------------------------------------------

и еще. в базе ест ькакието индексы. такое ощущение что для каждого столбца каждой таблицы сделали индекс.

Загадочно. Я не эксперт по админству, гадать не буду. Рад что проблема решилась

всем спасибо за ответы. сервис запущен, разбираться опчему не работало все равно придется(

ваших ответов в целом достаточно, если что апну тему.

еще раз всем огромное спасибо