Зависает процесс copy to tmp table

[Sponge Bob]

Что то не обратил внимание сразу, сейчас только подумалось: а тебе зачем в базе это делать все? Может имеет смысл дампануть и во время дампа кодировку поменять? Тот же дампер помниться мне запросто с этим справляется. При дампе принудительно указываеш кодировку базу и кодировку дампа и назад заливаеш его с автоматическими настройками.
И еще после запуска на чистом (перезапущеном) мускуле посмотри после 1-2 часов работы над этим запросом посмотри через пхпмиадмин какие операции мускульные так вешают все. Возможно все решиться принудительным указанием какого то буферного параметра большего чем он сейчас есть (или наоборот, меньше).
Ну и последняя умная мысля, если твой мускуль близок к моему 5.1.42 то можно запаковать в 7z всю твою папку, дать мне и я на серваке попробую это сделать подсунув прям папку с твоей базой к себе, там по крайней мере все 4 гига могут вертеться в оперативке и места дофея еще останется.

 

[Tima111]

Sponge Bob, спасибо, но с дампером не хотелось связываться. Время на перекопки базы своими силами ещё много Поле уже конвертнул в UTF-8 за 14 часов запрос прошёл благодаря увеличенным настройкам! Спасибо!
Подумал раз памяти оперативной ещё много, то можно настройки ещё больше увеличить - чтобы запросы быстрее проходили.
Вот как сделал:

skip-locking
key_buffer = 800M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 200M
read_buffer_size = 500M
key_buffer_size=1024M
read_rnd_buffer_size=2000M
net_buffer_length = 33M
thread_stack = 33M
thread_cache_size = 8
sort_buffer_size = 30M
query_cache_size = 512M

Поставил вчера запрос на INDEX поля, запрос до сих пор висит в copy to tmp - хотя прошло уже более 25 часов. Почему? Ведь должно быстрее исполняться раз все параметры увеличил? И памяти ещё свободной много. У меня 4Гб оперативной памяти, CPU C2D E6500.
Может поможете составить наиболее продуктивный My.cnf для такой конфигурации? Почему при бывших настройках, где цифры были меньше - copy to tmp - прошёл быстрее?

 

[Sponge Bob]

Может поможете составить наиболее продуктивный My.cnf для такой конфигурации?

На коленке писать его не получится. Надо смотреть не только на твое железо но и на твои задачи И опять таки далеко не всегда простое увеличение параметров может пропорционально увеличить производительность. Я же выше писал, возможно некоторые параметры придеться не увеличивать а уменьшать для увеличения скорости работы, чтоб система не ждала из за нехватки одних возможностей и переизбытке других. Вертай конфиг в зад и если что то поправить и хочется, то помни, что на 32 биной мускуле под виндой больше 2-2.5 гигов оперативки ты не займеш никак. Предидущий конфиг и так у гарници этого, твой же уже за ней далеко.
Ради интереса можеш попробывать мой, только пути подправь. Я в своем уменьшил все параметры в одинаковое количество раз, чтоб под 32 битной виндой запуститься смогло вообще это хозяйство )))) А, и у меня под MyISAM в кирилице заточено, если cp1251 тебе еще покатит в дефолтных параметрах, то вот при работе с Innodb базой будет работать это ощутимо хуже так как у меня он вообще считай не настроен. Но судя по озвученным парамтерам твоей таблици она должна в MyISAM-е быть )))

[client]

port=3306

[mysql]

default-character-set=cp1251


[mysqld]

port=3306
basedir="C:/MySQL/"
datadir="D:/MySQLData/"
default-character-set=cp1251
default-storage-engine=MyISAM
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=128
max_allowed_packet=32M
query_cache_size=512M
table_cache=256
tmp_table_size=512M
thread_cache_size=64
thread_concurrency=8
myisam_max_sort_file_size=25G
myisam_sort_buffer_size=128M
key_buffer_size=512M
read_rnd_buffer_size=32M
sort_buffer_size=64M
innodb_data_home_dir="D:/MySQLData/"
innodb_additional_mem_pool_size=36M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=16M
innodb_buffer_pool_size=1024M
innodb_log_file_size=18M
innodb_thread_concurrency=10