MYSql Query - # 2013 - Потерянное соединение с сервером MySQL во время запроса

Question

У меня длинный запрос с несколькими соединениями, которые были отключены. Я уже создал Sponsor_Id (используется в WHERE) во всех таблицах спонсоров в качестве индекса. График профилировщика показывает ужасную медлительность (75% времени при отправке данных).

---

Вот запрос:

SELECT GROUP_CONCAT(DISTINCT masterdetail.eventid) as eventids 
FROM tblsponsor_slave_eventprefrencesdetail userprefrence 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_category 
        userprefcategory 
       ON userprefrence.SponsorId = userprefcategory.SponsorId 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_locationtarget 
        userpreflocation 
       ON userprefrence.SponsorId = userpreflocation.SponsorId 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_type userprefEventType 
       ON userprefrence.SponsorId = userprefEventType.SponsorId 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_audienceprofile 
        userprefAudiProfile 
       ON userprefrence.SponsorId = userprefAudiProfile.SponsorId 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_industry 
        userprefIndustry 
       ON userprefrence.SponsorId = userprefIndustry.SponsorId 
     INNER JOIN tblsponsor_slave_eventprefrencesdetail userprefdetail 
       ON userprefrence.SponsorId = userprefdetail.SponsorId 
     INNER JOIN tblsponsor_slave_sponsor_eventprefrence_audiencetype 
        userprefAudiType 
       ON userprefrence.SponsorId = userprefAudiType.SponsorId 
     INNER JOIN tblsponsor_slave_eventprefrence_agegroup userprefAgeGroup 
       ON userprefrence.SponsorId = userprefAgeGroup.SponsorId 
     INNER JOIN tblevent_slave_event_address_city eventcity 
       ON userpreflocation.Sponsor_EventPrefrence_LocationTarget = 
        eventcity.Event_Address_City 
     INNER JOIN tblevent_slave_event_audienceprofile eventAudiProfile 
       ON userprefAudiProfile.Sponsor_EventPrefrence_AudienceProfile = 
        eventAudiProfile.Event_AudienceProfile 
     INNER JOIN tblevent_slave_event_industrycatered eventindustry 
       ON userprefIndustry.Sponsor_EventPrefrence_Industry = 
        eventindustry.Event_IndustryCatered 
     INNER JOIN tblevent_slave_agegroup eventagegroup 
       ON userprefAgeGroup.Sponsor_AgeGroup_Type = 
        eventagegroup.Event_AgeGroup_Type 
        AND userprefAgeGroup.IsExist = eventagegroup.IsExist 
     INNER JOIN tblevent_master_detail masterdetail 
       ON eventcity.EventId = masterdetail.EventId 
     INNER JOIN tblevent_slave_others eventothers 
       on masterdetail.EventId = eventothers.EventId 
        AND masterdetail.Event_Category = 
         userprefcategory.Sponsor_EventPrefrence_Category 
        AND masterdetail.Event_Type = 
         userprefEventType.Sponsor_EventPrefrence_Type 
        AND eventothers.Event_Gender = 
         userprefdetail.Sponsor_EventPrefrence_Gender 
        AND eventothers.Event_TargetAudience = 
         userprefAudiType.Sponsor_EventPrefrence_AudienceType 
        AND eventothers.Event_Sponsor_Range_Min < 
         userprefrence.Sponsor_EventPrefrence_Range_Max 
WHERE userprefrence.SponsorId = 164 
     AND eventagegroup.IsExist = 1 
     AND masterdetail.Event_StartDateTime > '2015-08-27' 
     AND masterdetail.Event_Category in ("1", "2", "3", "7", 
              "9", "10", "11") 
     AND eventcity.Event_Address_City in ("1", "3", "54") 
     AND masterdetail.Event_Type in ("2", "3", "4", "5", "7") 
     AND eventindustry.Event_IndustryCatered in ("13", "18") 
     AND eventAudiProfile.Event_AudienceProfile in ("1", "2", "10") 

Answer 1

Оптимизатор (возможно) начинается с таблицы, лучше всего отфильтрованного материала в пункте WHERE. Что выглядит наиболее избирательным? Скажем, это masterdetail.Event_StartDateTime > '2015-08-27'. Затем вам нужен индекс на masterdetailначиная с с Event_StartDateTime.

Затем он перейдет к другому столу. Это, вероятно, см:

ON eventcity.EventId = masterdetail.EventId 

подразумевая, что eventcity является следующей таблицей, и он должен получить в некоторых хау. Пахнет EventId является PRIMARY KEY; поэтому никаких дальнейших действий не требуется.

Затем на следующую таблицу. И следующий. Etc.

Эти WHERE положений нуждаются в дискуссии:

userprefrence.SponsorId = 164 
eventagegroup.IsExist = 1 

Они колонок = постоянной, что делает их очень хорошо для индексации. С другой стороны, IsExist пахнет истинным/ложным флагом, который почти никогда не используется сам по себе в индексе.

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

Можете ли вы обосновать 15-стол JOIN? Это много. («Нормализовать, но не переустанавливать».)

Я лечу слепой - не могли бы вы предоставить SHOW CREATE TABLE для каждого (после того, как вы выполнили все свои предложения)?

То, что я вам дал, возможно, не все, что можно было бы сделать.

sending data - бесполезная информация; им нужно каким-то образом разбить его.