Докато се приближавате към „почтен ', 2 милиона реда все още е сравнително малък размер за таблица. (И затова обикновено е възможно по-бързо изпълнение)
Както разбрахте, заместващите символи в предния край са особено неефективни и ще трябва да намерим решение за това, ако този случай на употреба е често срещан за вашето приложение.
Възможно е просто да нямате правилния набор от индекси . Преди да продължа обаче, искам да подчертая, че докато индексите обикновено подобряват производителността на СУБД с SELECT оператори от всякакъв вид, това систематично има отрицателен ефект върху производителността на операциите "CUD" (т.е. с SQL CREATE/INSERT, UPDATE , DELETE глаголи, т.е. заявките, които пишат към базата данни, а не просто четене към него). В някои случаи отрицателното въздействие на индексите върху заявките за „записване“ може да бъде много значително.
Моята причина да подчертая особено амбивалентния характер на индексите е, че изглежда, че вашето приложение събира достатъчен обем данни като нормална част от работата си и ще трябва да следите за възможно влошаване, тъй като заявките INSERT се забавят . Възможна алтернатива е събирането на данни в сравнително малка таблица/база данни, без или с много малко индекси, и редовно импортиране на данните от тази входна база данни в база данни, където се извършва действителното копаене на данни. (След като бъдат импортирани, редовете могат да бъдат изтрити от „входната база данни“, запазвайки я малка и бърза за нейната функция INSERT.)
Друг проблем/въпрос е относно ширината на ред в таблицата за прехвърляне (броя на колоните и сумата от ширините на тези колони). Лошото представяне може да е свързано с факта, че редовете са твърде широки, което води до твърде малко редове в листните възли на таблицата и следователно по-дълбока от необходимото дървовидна структура.
Обратно към индексите...
с оглед на няколкото запитвания във въпроса, изглежда, че бихте могли да се възползвате от индекс на ip + note (индекс, направен поне с тези два ключа в този ред). Пълен анализ на ситуацията с индекса и честно казано възможен преглед на схемата на базата данни не може да се направи тук (не е достатъчно информация за един...), но общият процес за това е да се направи списък с най-често срещаните случаи на употреба и за да видите кои индекси на базата данни биха могли да помогнат в тези случаи. Човек може да получи представа за това как се обработват конкретни заявки, първоначално или след добавяне на индекс(и), с mySQL команда EXPLAIN.
Нормализирането ИЛИ демормализацията (или всъщност комбинация от двете!) често е жизнеспособна идея за подобряване на производителността и по време на минни операции.
