Immortal_pony, Тимур Громов: Конкретно в данном случае не особо много вариантов: проблем с индексом тут быть не может, потому что UPDATE делает index seek для поиска дубликатов, и если это не проблема с локами таблицы нетранзакционным движком, то остаются только проблемы с медленными дисковыми операциями, из-за которых index seek может работает медленно.
Immortal_pony: В подавляющем большинстве случаев разбора проблем с конкуретными операциями является использование нетранзакционного движка там где он не нужен, потому что он не умеет нормально работать с такими операциями.
> скорость вставки не изменится.
Совершенно верно.
Но общее время исполнения запроса будет включать в себя время ожидания снятия лока. В любом случае, автор выше отметил, что смена движка ему не помогла.
В вашем примере потерялся CURLOPT_RETURNTRANSFER, без него curl ответ на stdout сразу выводит. Очень удобно также задавать параметры через массив:
$curlParams = [
CURLOPT_URL => $url,
CURLOPT_POST => 1,
CURLOPT_POSTFIELDS => $fields_string,
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_USERPWD => $userpwd,
];
curl_setopt_array($ch, $curlParams);
Так у вас же там нет полнотекстового индекса - собственно это и написано в ошибке. А BOOLEAN MODE и без него работает. Создайте индекс: CREATE FULLTEXT INDEX index_name ON `org` (name_org,description,tags); У вас же MyISAM таблица? Если InnoDB, то индекс будет создан только если версия MySQL 5.6 или выше.
Это Deprecated возможность, опасно ее использовать. К тому же, с INSERT .. ON DUPLICATE KEY UPDATE она не работает: The DELAYED option is ignored when you use ON DUPLICATE KEY UPDATE.( https://dev.mysql.com/doc/refman/5.6/en/insert-on-...
NOW() возвращает текущую дату, это слегка противоречит постановке задачи. А не работало, потому что подзапрос надо было использовать как скалярное значение, обернув в скобки:
DELETE FROM msg WHERE d <= DATE_SUB((SELECT MAX(d) FROM msg), INTERVAL 30 MINUTE);
на здоровье:) при выборе движка для таблицы необходимо принимать во внимание, что основное назначение InnoDB - обеспечение ACID (dev.mysql.com/doc/refman/5.6/en/mysql-acid.html) принципов за счет проигрыша в скорости, заметного на больших данных, а MyISAM - это просто хранилище, причем legacy, как уже было сказано, там нет всех этих механизмов и поэтому INSERT там работает быстрее по определению. Можно даже провести аналогию: NTFS vs. FAT32. Соотвественно, если вам важны целостность, консистентность и транзакции - InnoDB ваш выбор. Если важна скорость, таблица не подверженна конкуретным операциям - оставьте MyISAM. Не забывайте после массовых удалений делать REPAIR TABLE для дефрагментации занимаемого места и перестройки индексов(осторожно, на больших таблицах эта операция занимает много времени - на двух миллионах записей у меня занимало примерно 15 минут). И да, SSD даст вам прирост в скорости)
SET autocommit = 0 делает неявный START TRANSACTION, которую нужно будет обязательно COMMIT или ROLLBACK. По умолчанию он включен, и каждая операция является транзакцией. И все это работает только для InnoDB, в MyISAM нет понятия транзакций в принципе.
Почему вы не хотите рассмотреть вариант с LOAD DATA INFILE? Вы можете сформировать CSV файл (например), положить его куда-нибудь в /tmp, а потом зачитать его инструкцией LOAD DATA INFILE, в таком случае вставка будет ультра быстрая.
Или, насколько я понял, у вас это все локально происходит и пользователь один - в таком случае можно оставить MyISAM и не забывать следить за его состоянием
Можно попробовать выключать проверку foreign и unique constraints: SET unique_checks=0;
SET foreign_key_checks=0; (Не забудьте включить обратно после вставки), увеличить размер буфера на вставку: https://dev.mysql.com/doc/refman/5.5/en/server-sys... Рассмотрите использование BIGINT AUTO_INCREMENT в качестве первичного ключа, это тоже хорошо повышает производительность INSERT'ов. Кроме того, если вы вставляете настолько много данных, что множественные VALUES не подходит, воспользуетесь инструкцией массовой загрузки LOAD DATA INFILE (https://dev.mysql.com/doc/refman/5.6/en/load-data.html), которая была создана специально для этих целей и работает ультра быстро.
Если вам не принципиальна целостность данных, с бд работает один пользователь или таблица используется в основном для SELECT'ов - то можете оставить MyISAM. В остальных случаях настоятельно рекомендуется использовать InnoDB. (сам Oracle и рекомендует:
> InnoDB is the default and most general-purpose storage engine, and Oracle recommends using it for tables except for specialized use cases. dev.mysql.com/doc/refman/5.6/en/storage-engines.html)