Попробуйте выполнить следующие действия, чтобы повысить производительность запросов:

• определите индексацию в структуре базы данных и получите только те столбцы, которые вам нужны.
• Не используйте * в запросе выбора.
• И не ставьте идентификаторы в кавычки, как User.id='51394', вместо этого делайте User.id= 51394.
• Если вы указываете идентификаторы в кавычках, то ваша индексация не будет работать. Такой подход повышает производительность ваших запросов на 20% быстрее.
• Если вы используете ENGINE=MyISAM, то вы не можете определить индексацию между вашими таблица базы данных, измените компонент database engine на ENGINE=InnoDB. И создайте некоторую индексацию, например, внешние ключи, полнотекстовую индексацию.

Если я правильно понимаю, для всех результат SELECT * FROM AdvanceBulkInsert... вы запускаете запрос SELECT cf.*, и для всех SELECT cf.* вы запускаете SELECT * FROM User

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

Я думаю, вам следует объединить все ваши запросы на выбор только в один большой запрос.

Для этого:

• Замените SELECT * FROM AdvanceBulkInsert с помощью EXISTS IN (SELECT * FROM AdvanceBulkInsert where ...) или JOIN

• Замените SELECT * FROM User на NOT EXISTS IN(SELECT * from User WHERE )

Затем вы вызываете обновите все результаты объединенного выбора.

Вы также должны по очереди выполнять свой запрос, чтобы определить, какой из этих запросов занимает больше всего времени, и вы также должны использовать ANALYSE , чтобы определить, какая часть запроса занимает время.

Редактировать:

Теперь я вижу ваш код:

Некоторые зацепки:

• У вас есть индекс для cf.customtypeid, cfv.customfieldid, cfsa.customfieldid, пользователя. Дата рождения, пользователь. Имя, пользователь. фамилия ?

• Вам не нужно выполнять ЛЕВОЕ СОЕДИНЕНИЕ с областью пользовательских полей, если у вас есть место, где вы используете область пользовательских полей, достаточно простого СОЕДИНЕНИЯ с областью пользовательских полей.

• Вы будете запускать запрос 2 много раз с relatedId = 0, возможно, вы сможете сохранить результат в var?

• Если вам не нужны отсортированные данные, удалите "ЗАКАЗ ПО cf.сортировщику, cf.метке". В противном случае добавьте индекс в cf.сортировщик, cf.метка

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

• select_type - это всегда должен быть простой запрос/подзапрос. Связанные с этим подзапросы доставляют много хлопот. К счастью, вы не используете никаких
• возможные ключи - По каким ключам этот выбор будет искать
• строки - сколько строк-кандидатов определяется ключи/кэш и другие методы. Чем меньше число, тем лучше
• Дополнительно - "использование" говорит вам, как именно найдены строки, это самая полезная информация

Анализ запросов

Я бы опубликовал аналитику для 1-го и 3-го запросов, но оба они довольно простые запросы. Вот разбивка запроса, который доставляет вам проблемы:

EXPLAIN SELECT cf.*, ctyp.typeName, cfv.id as customId, cfv.customFieldId, 
   cfv.relatedId, cfv.fieldValue, cfv.createdAt 
FROM `CustomField` `cf` 
    INNER JOIN CustomType ctyp on ctyp.id = cf.customTypeId 
    LEFT OUTER JOIN CustomValue cfv on cf.id = cfv.customFieldId 
                and relatedId = 0 
    LEFT JOIN CustomFieldSubArea cfsa on cfsa.customFieldId = cf.id 
WHERE ((relatedTable = 'people' and enabled = '1') 
  AND (onCreate = '1')) 
  AND (cfsa.subarea='peoplebulkinsert') 
ORDER BY cf.sortOrder, cf.label

• ВНУТРЕННИЙ пользовательский тип СОЕДИНЕНИЯ ctyp на ctyp.id = см. customtypeid
• ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ Пользовательское значение cfv на cf.id = cfv.Пользовательское поле и связанный идентификатор = 0
• СЛЕВА ПРИСОЕДИНИТЬСЯ к пользовательскому полю cfsa на cfsa.customfieldid = cf.id
• ГДЕ ((Связанная таблица = "люди" и включено = '1') И (Создать = '1')) И (cfsa.подобласть ='peoplebulkinsert')
• ПОРЯДОК ПО ср.сортировщик , ср. метка

Решение

Позвольте мне объяснить приведенный выше список. Жирный шрифт столбцы полностью должны иметь индекс. Объединение таблиц - дорогостоящая операция, которая в противном случае должна проходить через все строки обеих таблиц. Если вы сделаете индекс по соединяемым столбцам, механизм БД найдет гораздо более быстрый и лучший способ сделать это. Это должно быть обычной практикой для любой базы данных

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

Поэтому вам нужно добавить индексы в эти столбцы

• Идентификатор пользовательского типа
• Пользовательское поле - пользовательский идентификатор, идентификатор, связанная таблица, включено, onCreate, сортировщик, метка
• Пользовательское значение - идентификатор пользовательского поля
• Область настраиваемых полей - идентификатор настраиваемого поля, область

Для проверки результаты попробуйте снова запустить инструкцию explain после добавления указателей (и, возможно, нескольких других запросов select/insert/update). В дополнительном столбце должно быть написано что-то вроде "Использование индекса", а в столбце possible_keys должен быть список используемых ключей (даже два или более на запрос соединения).

Примечание: В вашем коде есть некоторые опечатки, вы должны исправить их на случай, если кому-то еще тоже понадобится поработать над вашим кодом: "reqruitecount" в качестве столбца таблицы и "fileuplaod" в качестве индекса массива в вашем ссылочном коде.

Для моей работы я должен ежедневно добавлять один CSV-файл с 524 столбцами и 10 тыс. записей. Когда я попытался разобрать его и добавить запись с помощью php, это было ужасно.

Итак, я предлагаю вам ознакомиться с документацией о ЗАГРУЗКЕ ЛОКАЛЬНОГО ФАЙЛА ДАННЫХ

Я копирую/пропускаю свой собственный код, например, но адаптирую его к вашим потребностям

$dataload = 'LOAD DATA LOCAL INFILE "'.$filename.'"
                REPLACE
                INTO TABLE '.$this->csvTable.' CHARACTER SET "utf8"
                FIELDS TERMINATED BY "\t"
                IGNORE 1 LINES
            ';

$result = (bool)$this->db->query($dataload);

Где $filename - локальный путь к вашему CSV (вы можете использовать dirname(__FILE__) для его получения)

Эта команда SQL выполняется очень быстро (всего 1 или 2 секунды для добавить/обновить весь CSV)

РЕДАКТИРОВАТЬ: прочитайте документ, но, конечно, вам нужно иметь индекс uniq в таблице пользователей для работы "заменить". Таким образом, вам не нужно проверять, существует ли пользователь или нет. И вам не нужно анализировать CSV-файл с помощью php.

Похоже, у вас есть возможность (вероятность?) 3 запроса для каждой отдельной записи. Для этих 3 запросов потребуется 3 обращения к базе данных (и если вы используете yii для хранения записей в объектах yii, это может еще больше замедлить работу).

Можете ли вы добавить уникальный ключ на имя/фамилию /DOB и один на адрес электронной почты?

Если это так, то вы можете просто ВСТАВИТЬ....ПРИ ОБНОВЛЕНИИ ДУБЛИКАТА КЛЮЧА. Это позволило бы свести его к одному запросу для каждой записи, значительно ускоряя процесс.

Но большим преимуществом этого синтаксиса является то, что вы можете вставлять/обновлять сразу много записей (обычно я придерживаюсь около 250), поэтому еще меньше обращений к базе данных.

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

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

Другой проблемой, по-видимому, является ваш следующий запрос, но вы не уверены, где вы его выполняете. Похоже, что его нужно выполнить только один раз, и в этом случае он возможно, это не имеет большого значения. Вы не указали структуру таблицы CustomType, но она присоединена к Customfield, а поле customTypeId не имеет индекса. Следовательно, это соединение будет медленным. Аналогично в соединениях CustomValue и CustomFieldSubArea, которые объединяются на основе customfieldid, и ни у одного из них нет индекса в этом поле (надеюсь, уникальный индекс, как если бы эти поля не были уникальными, вы получите МНОГО возвращенных записей - 1 строка для каждой возможной комбинации)

SELECT cf.*, ctyp.typeName, cfv.id as customId, cfv.customFieldId, 
       cfv.relatedId, cfv.fieldValue, cfv.createdAt 
FROM `CustomField` `cf` 
    INNER JOIN CustomType ctyp on ctyp.id = cf.customTypeId 
    LEFT OUTER JOIN CustomValue cfv on cf.id = cfv.customFieldId 
                and relatedId = 0 
    LEFT JOIN CustomFieldSubArea cfsa on cfsa.customFieldId = cf.id 
WHERE ((relatedTable = 'people' and enabled = '1') 
  AND (onCreate = '1')) 
  AND (cfsa.subarea='peoplebulkinsert') 
ORDER BY cf.sortOrder, cf.label

Смотрите, чтобы вы могли попытаться сократить запрос и проверить с помощью компилятора sql online, проверьте период времени, который затем включите в проект.

Всегда выполняйте массовый импорт в рамках транзакции

        $transaction = Yii::app()->db->beginTransaction();
        $curRow = 0;
        try
        {
            while (($peopleData = fgetcsv($handle, 10240, ",")) !== FALSE) {
            $curRow++;
            //process $peopleData
            //insert row
            //best to use INSERT ... ON DUPLICATE  KEY UPDATE
            // a = 1
            // b = 2;
            if ($curRow % 5000 == 0) {
               $transaction->commit();
               $transaction->beginTransaction();
            }
        }
        catch (Exception $ex)
        {
            $transaction->rollBack();
            $result = $e->getMessage();                    
        }
        //don't forget the remainder.
        $transaction->commit();

Я видел, как процедуры импорта ускорились на 500%, просто используя эту технику. Я также видел процесс импорта, который выполнял 600 запросов (смесь выбора, вставки, обновления и отображения структуры таблицы) для каждой строки . Этот метод ускорил процесс на 30%.