Comments 7
Очень странно в статье, посвящённой оптимизации, не увидеть ни планов выполнения запросов, ни попыток оптимальной индексации данных... По сути, данные просто были нормализованы. Но и тут - вместо того, чтобы обосновать применённую нормализацию на основании анализа предметной области, всё сделано чуть ли не по наитию (слава богу, структуры - проще некуда, потому и прокатило).
А ещё за кадром как-то остался факт необходимости полной переделки кода создания/обновления записей с учётом изменения структуры.
Я убрал LEFT JOIN, так как он не влияет на количество элементов в выборке.
Серьёзно? А то, что это изменяет логику запроса - это ничего? Нет, к тому, что безграмотные "запросописатели" лепят LEFT JOIN где надо и где не надо вне зависимости от требуемой логики, я как-то привык, но вносить изменения без оглядки на логику - это уже край.
Запрос на получение количества данных будет иметь следующий вид
SELECT * ну никак не может вернуть количество.
SELECT * ну никак не может вернуть количество.
Извиняюсь, за опечатку. Исправил.
Серьёзно? А то, что это изменяет логику запроса - это ничего?
Согласен. Не хватает пояснения.
В таблице "feature_name_descriptions", если нет описания или наименование характеристики, поля name или/и description просто пустые, и необходимы для дальнейшей логики, которая выходит за пределы этой статьи. В первом случае когда используем "JOIN feature_name_descriptions", мы теряем "variants_links.feature_id" у которых ещё нет записи в "feature_name_descriptions". По этому я решил использовать "LEFT JOIN test_feature_name_description".
А ещё за кадром как-то остался факт необходимости полной переделки кода
С этим тоже согласен. Не хватает логики после выборки данных. Постарался уложится в SQL код, иначе статья получилась бы чересчур большая.
А где хоть один EXPLAIN?
Статья полный фейспалм. О чем уже и написали комментаторы сверху.
При оптимизации Mysql существует куча способов оптимизации (в зависимости от схем таблиц, размера строк, количества данных), но статья совсем не об этом, а из разряда делаю что-то не знаю что и получаю что-то еще, но не знаю почему.
features_variants_links
image_link - char, иначе зачем MyISAM?
feature_variants
KEY variant_id не нужен. Перекрывается PRIMARY KEY.
Как уже отметили выше, в статье никак не упомянут EXPLAIN. Но даже без explain, длительность выполенния поиска еще сильно зависит от проиводительности работы дисковой подсистемы, есть ли кэш, прогрет ли он, запускает ли кто-то паралельно другие запросы по базе... Так что Вы, может, и прооптимизируете запрос до 1 секунды выполнения, а потом на реальном сервере кто-то запустит паралельный бакап базы и время выполнения запроса улетит в космос.
И вообще MyISAM использовать в XXI веке.. как-то нехорошо. InnoDB тоже не фонтан, конечно, но если не хранить всё в одном огромной файле, а разбить на file-per-table, то терпимо.
Ужас а не статья. Начиная от подзаголовков "Количество строк 224998:" и заканичвая тем что нет ни одного EXPLAIN, ни одного примера результата запроса (чтобы примерно понять котекст), постоянные отсылки к InnoDB - так перейдите на InnoDB, черт вас за ногу.
Абсолютно вырвиглазные глаза таблиц и переменных, ни одного слова про железо, на котором это все крутится.
В общем кто-то где-то оптимизировал какие то циферки сферического коня в вакууме и решил поделиться опытом. Статья уровня "я взял базу, выкинул из нее старые ненужные данные и все заработало быстрее".
Ну и псевдо-большие данные в заголовке это откровенное вранье. Это вообще смешной объем данных - чуть больше миллиона строк. Я регулярно в плане хобби перемалываю базы размером 20+ ГБ (нац. база стоимостей процедур в госпиталях, базы продажи недвижимости, итд), правда мне там скорость запроса вообще не важна, но с обычным индексом скорость выполнения примерно такая же как и у вашего клиента, в пределах 1-2 секунд.
MySQL. Оптимизация псевдо-больших данных