Как я могу улучшить запрос mysql, который извлекает данные 11.2m?

Question

select tblfarmerdetails.ncode, 
tblfarmerdetails.region,tblfarmerdetails.province, tblfarmerdetails.municipality, 
concat(tblfarmerdetails.farmerfname, ' ', tblfarmerdetails.farmerlname) as nameoffarmer, 
concat(tblfarmerdetails.spousefname, ' ',tblfarmerdetails.spouselname) as nameofspouse, tblstatus.statusoffarmer from tblfarmerdetails 
INNER Join 
tblstatus on tblstatus.ncode = tblfarmerdetails.ncode where tblstatus.ncode = tblfarmerdetails.ncode order by tblfarmerdetails.region 

Для получения данных 11,2 м требуется слишком много времени. Как я могу улучшить этот запрос?

Answer 1

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

SELECT f.ncode 
     , f.region 
     , f.province 
     , f.municipality 
     , CONCAT(f.farmerfname,' ',f.farmerlname) AS nameoffarmer 
     , CONCAT(f.spousefname,' ',f.spouselname) AS nameofspouse 
     , s.statusoffarmer 
    FROM tblfarmerdetails 
    JOIN tblstatus s 
     ON s.ncode = f.ncode 
    ORDER BY f.region 

Вполне вероятно, что много времени уходит, чтобы сделать «Использование FileSort» операцию, чтобы отсортировать все строки в порядке, указанном в пункте ORDER BY. Конечно, операция сортировки будет иметь место, если нет индекса с ведущим столбцом region.

Имея подходящий индекс доступен для examaple

... ON tblfarmerdetails (region, ...) 

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

Если MySQL имеет доступный «индекс покрытия», то есть индекс, содержащий все столбцов ссылки таблицы в запросе, MySQL может использовать этот индекс для удовлетворения запроса без необходимости посещения страниц в базовую таблицу.

Но учитывая количество столбцов, и вероятность того, что некоторые из этих колонн может быть величественным размера VARCHAR, это не может быть возможно или работоспособным:.

... ON tblfarmerdetails (region, ncode, province, municipality, farmerfname, farmerlname, spousefname, spouselname) 

(MySQL имеет некоторые ограничения на indexex Цель «индекса покрытия» заключается в том, чтобы избежать поиска страниц в таблице.)

И убедитесь, что MySQL знает, что ncode UNIQUE в tblstatus. Либо это PRIMARY KEY, либо индекс UNIQUE.

Мы подозреваем, что таблица tblstatus содержит небольшое количество строк, поэтому операция соединения, вероятно, не так дорого. Но соответствующий индекс покрытия, с ncode в качестве ведущей колонки, не мешал бы:

... ON tblstatus (ncode, statusoffarmer) 

Если MySQL должен Performa операции «Использование FileSort», чтобы получить строки упорядоченной (чтобы удовлетворить условие ORDER BY), на большой набор, эта операция может разлиться на диск и может добавить (иногда значительно) к прошедшему времени.

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

И клиент должен что-то сделать с возвращаемыми строками.

Вы действительно хотите вернуть 11.2M строк? Или вам нужны только первые пару тысяч строк?

Рассмотрите возможность добавления в запрос предложения LIMIT.

И как долго те lname и fname столбцы? Вам нужно, чтобы MySQL выполнял конкатенацию для вас, или это можно сделать на клиенте по мере того, как строки выполняются.

Возможно, MySQL должен выполнить «Использование временных» для хранения строк с конкатенированными результатами. И MySQL, вероятно, выделяет достаточно места для этого столбца возврата, чтобы удерживать максимально возможную длину от lname + максимально допустимой длины от fname. И если это многобайтовый набор символов, это удвоит или утроит хранение по одному байтовому набору символов.

---

Чтобы узнать, что происходит, вам нужно взглянуть на план выполнения запроса. Вы получаете, что предшествующими ваш ЗЕЬЕСТ с ключевым словом EXPLAIN

EXPLAIN SELECT ... 

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