Мой запрос выполняется слишком долго. Когда я регистрирую это, я вижу что-то подобное:
Sending data 0.039324
executing 0.000011
Sending data 0.039662
executing 0.000012
Sending data 0.040380
executing 0.000015
Sending data 0.035879
executing 0.000012
Sending data 0.035426
executing 0.000012
Sending data 0.038107
executing 0.000011
Sending data 0.035247
executing 0.000011
Sending data 0.050108
executing 0.000014
Sending data 0.045458
executing 0.000012
Sending data 0.034700
executing 0.000012
Sending data 0.036205
executing 0.000012
Sending data 0.034602
executing 0.000015
Sending data 0.034580
executing 0.000012
Sending data 0.034477
executing 0.000010
Sending data 0.034382
executing 0.000010
Sending data 0.034416
executing 0.000011
Sending data 0.034335
executing 0.000010
Sending data 0.034474
executing 0.000010
Sending data 0.034405
executing 0.000010
Sending data 0.034433
executing 0.000011
Sending data 0.034544
executing 0.000010
Sending data 0.034525
executing 0.000011
Sending data 0.034459
executing 0.000010
Sending data 0.034766
executing 0.000011
Sending data 0.034633
executing 0.000010
Sending data 0.034574
executing 0.000011
Sending data 0.034607
executing 0.000010
Sending data 0.034613
executing 0.000011
Sending data 0.034394
executing 0.000010
Sending data 0.034606
executing 0.000011
Sending data 0.034790
executing 0.000011
Sending data 0.034614
executing 0.000011
Sending data 0.034497
executing 0.000010
Sending data 0.034756
executing 0.000010
Sending data 0.034440
executing 0.000010
Sending data 0.034414
executing 0.000011
Sending data 0.034484
executing 0.000011
Sending data 0.034490
executing 0.000011
Sending data 0.034672
executing 0.000011
Sending data 0.034455
executing 0.000011
Sending data 0.034430
executing 0.000011
Sending data 0.034509
executing 0.000012
Sending data 0.034432
executing 0.000012
Sending data 0.034348
executing 0.000011
Sending data 0.034378
executing 0.000011
Sending data 0.034356
executing 0.000011
Sending data 0.034631
end 0.000014
query end 0.000007
closing tables 0.000010
freeing items 0.000025
logging slow query 0.000003
logging slow query 0.000004
cleaning up 0.000004
В нем слишком много отправляемых данных.
Запрос я запустил:
SELECT COUNT(*) as count from OrdersArchive where ID>0 and PId IN ('2564') and
(
ID like '17000106864'
OR `OrderID` like '17000106864'
OR `ID` IN
(
SELECT `transferID`
FROM `custom_fields`
WHERE `fieldName` = 'invoiceNumber'
AND `value` like '%17000106864%'
)
OR `tpb` LIKE '17000106864'
)
Объясните шоу
id select_type табличный тип возможных_ключей ключ key_len ref row Extra 1 PRIMARY OrdersАрхив архива PRIMARY, ID_UNIQUE PRIMARY 4 NULL 41609 Использование где 2 ЗАВИСИМАЯ ПОДПИСЬ custom_fields ALL NULL NULL NULL NULL 93141 Использование где
Табличные структуры MySQL:
СОЗДАЙТЕ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ `OrdersArchive` ( `ID` int (11) NOT NULL, `ids` int (11) NOT NULL DEFAULT '0', `OrderID` varchar (11) NOT NULL DEFAULT '0', `PricePosition` int (11) NOT NULL DEFAULT '0', `Reverse` tinyint (1) DEFAULT NULL, Отметка времени `DataOrder` NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 'DataFlightTrain` timestamp NOT NULL DEFAULT' 0000-00-00 00:00:00 ', `Customer` varchar (255) DEFAULT NULL, `PhoneCustomer` varchar (255) DEFAULT NULL, `EmailCustomer` varchar (255) DEFAULT NULL, `Provider` int (11) DEFAULT NULL, `DeliveryTime` отметка времени NULL ПО УМОЛЧАНИЮ NULL, `Address1` varchar (255) DEFAULT NULL, `Address2` varchar (255) НЕ NULL, `Passangers` varchar (1024) DEFAULT NULL, `PassangersPhones` varchar (255) НЕ NULL, `PassangersEmailes` varchar (255) НЕ NULL, `FlightTrain` varchar (255) DEFAULT NULL, `КоличествоPassangers` int (11) ПО УМОЛЧАНИЮ '1', `NamePlate` varchar (255) DEFAULT NULL, `PhoneDriver` varchar (255) DEFAULT NULL, `PhoneDriverNeed` tinyint (1) DEFAULT '0', `Status` int (11) DEFAULT NULL, `Operator` int (11) DEFAULT NULL, `userId` int (11) NOT NULL, `usn` varchar (256) NOT NULL, `ArendaNeed` varchar (255) DEFAULT '', `ArendaHour` int (11) DEFAULT NULL, `ArendaMinutes` varchar (255) DEFAULT '', `Cost` double DEFAULT NULL, Текст `Notes 'NOT NULL, `notes2` varchar (256) NOT NULL DEFAULT '', `PId` int (11) NOT NULL DEFAULT '0', `Voucher` varchar (256) NOT NULL, `Invoice` varchar (256) NOT NULL, `Meet` varchar (255) НЕ NULL, `Toward` varchar (255) НЕ NULL, `techStatus` int (2) NOT NULL DEFAULT '0', `City` varchar (55) НЕ NULL, `City2` varchar (55) NOT NULL, `Auto` varchar (30) NOT NULL, `отдела` varchar (255) НЕ NULL ПО УМОЛЧАНИЮ ', `nsktime` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', `tpb` varchar (255) NOT NULL DEFAULT '', `ban_add_races` int (1) NOT NULL DEFAULT '0', `paid` int (10) NOT NULL DEFAULT '0', `taxi` varchar (255) NOT NULL DEFAULT '', `price_client` int (11) DEFAULT NULL, `comission_from_client` int (11) DEFAULT NULL, `примчание` varchar (1000) DEFAULT NULL, ПЕРВИЧНЫЙ КЛЮЧ (`ID`), UNIQUE KEY `ID_UNIQUE` (` ID`), KEY `fk_Orders_Users1_idx` (` Оператор`), KEY `fk_Orders_Providers1_idx` (` Provider`), KEY `fk_Orders_OrderStatus1_idx` (` Status`), KEY `ids` (` идентификаторы`) ) ENGINE = InnoDB CHARSET ПО УМОЛЧАНИЮ = utf8; ## и другие таблицы СОЗДАЙТЕ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ `custom_fields` ( `ID` int (11) NOT NULL AUTO_INCREMENT, `pid` int (11) NOT NULL, `TransferID` int (11) NOT NULL, `fieldName` varchar (255) NOT NULL, `value` varchar (1024) NOT NULL, ПЕРВИЧНЫЙ КЛЮЧ (`ID`) ) ENGINE = InnoDB CHARSET ПО УМОЛЧАНИЮ = utf8 AUTO_INCREMENT = 325452;
Хотя текущий запрос SELECT, возможно, может быть улучшен до некоторой степени, я думаю, что это поможет гораздо больше, если вы сможете хранить данные более эффективным способом, особенно если вы можете устранить необходимость в
А ТАКЖЕ value
как «% 17000106864%»
Если вы создадите отдельное поле для invoiceNumber и заполните его при вставке данных, вы можете проиндексировать их и выбрать / присоединить к ним следующим образом:
ГДЕ invoiceNumber = 17000106864
В случае, если вы ищете только одну запись, добавление LIMIT к запросу также поможет.
Ну, я сделал это с INNER JOIN. Пробеги 0.34 сек
Последний запрос:
ВЫБЕРИТЕ COUNT (`OrdersArchive`.ID) как количество,` OrdersArchive`.ID ИЗ `OrdersArchive` ВНУТРЕННЕЕ СОЕДИНЕНИЕ `custom_fields` на` OrdersArchive`.ID = `custom_fields``transferID` ГДЕ `OrdersArchive`.ID> 0 И `custom_fields``fieldName` = 'invoiceNumber' А ТАКЖЕ `OrdersArchive`.PId IN ('2564') И ( `OrdersArchive`.ID LIKE '17000106864' ИЛИ `OrdersArchive`. OrderID` LIKE '17000106864' ИЛИ `OrdersArchive` .tpb` LIKE '17000106864' ИЛИ ЖЕ ( `custom_fields``value` like '% 17000106864%' ) )
Вернуться к вопросу, подразумеваемому в заголовке («несколько состояний данных отправки») …
IN(SELECT ...)
часто очень неэффективно. В вашем случае он выполняется многократно, тем самым «выполняя» и «отправляя данные» для каждого вызова.
Другие Ответы обеспечивают решение другого подразумеваемого вопроса («запрос выполняется слишком долго»), превращая эту конструкцию в JOIN
,
Другие вопросы;
PRIMARY KEY (`ID`), -- This is UNIQUE and an INDEX
UNIQUE KEY `ID_UNIQUE` (`ID`), -- totally redundant; DROP it
Возможно, вас мучают проблемы с производительностью, поскольку схема имеет вид «EAV» (Entity-Attribute-Value), и вам необходимо выполнить фильтрацию на основе некоторого значения ключа («invoiceNumber»). Попробуйте вытащить его из таблицы ключ-значение (custom_fields
) и положите его в основную таблицу (OrdersArchive
).
Но потом я вижу, что OrdersArchive
имеет довольно большое количество столбцов. Но у меня нет никаких конкретных предложений по этому поводу.
custom_fields
довольно лишен индексов. Увидеть мои советы при индексации общей таблицы ключ-значение.