"за мкадом сео нет"©
Что Вы подразумеваете под KEY?
Смысл любого индекса в том, что бы нужные данные искались бы без прохода по всей базе данных. Как первые буквы в записной книжке. Даже если Вы не помните сами где какая буква начинается что бы открыть сразу нужную страницу по памяти (не храните в оперативке), все равно индекс на диске (буквы нарисованные на корешках книжки) помогает Вам найти нужного абонента быстрее, чем если бы Вы перелистывали всю книжку.
Если индекс помещается в оперативку - это отлично. Если не помещается - все равно его наличие сильно помогает.
Да.
Тут даже дело не столько в больших данных, сколько в самом принципе тестирования.
99% что у Вас весь индекс, что составной что простой, в оперативке. Значит разница даже многократная по доступу к нему - в пределах погрешности будет, особенно с учетом того что на таблице в 100к записей и целочисленном индексе - пара мегабайт дай бог объем индекса. Опять же ОС может кэшировать дисковые операции, т.е. sql_no_cache особо не решает.
Нельзя так тестить в принципе, можно получить результаты с точностью до противоположных.
Из сказанного Вами прямо следует, что простые индексы использовать крайне глупо, ведь они "то же самое, только без бонусов составных". В подобном выводе есть легкий оттенок нелогичности, Вы так не считаете? :) Коронной идеей в данном случае будет повесить составной индекс на все поля сразу, пусть будет типа.
Еще раз - составной индекс - избыточен по отношению к простому. Это факт. Избыточность это плохо. Это тоже факт. Можно несколько поспорить на тему насколько это плохо, но это отдельный вопрос.
Что касается теста - забейте таблицу разными данными в индексируемых полях, забейте туда десяток миллионов записей, пусть размер будет хотя бы пара гигов для индексов и 10 для базы, протестируйте запросом на выборку с benchmark 10000 а не разовым sql_no_cache, посчитайте время построения индекса заодно, не забудьте протестировать скорость вставках с тем же бенчмарком - тогда это будет тест что-то показывающий. А пара одиночных запросов на неизвестно каких данным, на крошечных индексах и неизвестно как закэшированных данных (ФС тоже кэширует) - это не тест, а фикция.
По мануалу да, но непонятно где и как используется на практике. tinyint(1) вполне себе нормально хранит число 120.
Единственное где это вроде бы еще важно, это при джоинах таблиц по индексам. int (10) с int (11) вроде как не идеально склеивается по индексам. Но не вдавались в детали.
У int-овых типов данных, в отличии от текстовых полей, число в скобках отношения к размеру занимаемых данных не имеет никакого, оно упрощенно говоря несет в себе чисто декоративный смысл в данном контексте.
К номеру gjdkfjj наверняка можно подобрать более красивую расшифровку:) Фокус-то в том, что одной цифре соответствуют 3 буквы на выбор.
Потому что индекс на country+phone, а не на country. Избыточность менее эффективна.
В зависимости от оптимизатора sql. Не зря в мануалах специально указывают, что если хочется гарантированно использовать составной индекс, то в where нужно использовать тот же порядок, что и при задании индекса.
Вы немного не верно смысл нормальных форм понимаете в данном контексте.
Нормальные формы фиксят ситуацию вида "имя васи хранится в двух местах" принципом вида "пихнем имя васи в одно место и сделаем на него ссылки". Тем самым изменяя данные васи их не нужно апдейтить данные в двух местах, достаточно в одном, поэтому целостность улучшается.
В Вашем случае, EAV разбитое по разным таблицам, это хранение данных контакта в нескольких разных местах, то есть ситуация прямо противоположно направленная сохранению целостности данных. Вместо одного места - Вы разносите их в несколько.
Да, имя Васи у Вас все еще хранится только в одном месте, но информация относящаяся к Васе уже начинается хранится в куче разных мест - таблиц. Поэтому в случае сбоя при апдейте, у Вас получится что часть информации в части таблиц обновилась, а часть информации в части таблиц не обновилась - оппа - сбой целостности. Безусловно это не ах какая катастрофичная проблема и она решается, но тем не менее вопрос на повестку дня всплывает.
Когда это имеет смысл.
Если индекс типа country+phone, то поиск where country+phone будет эффективнее остальных вариантов.
Однако where phone будет без индекса вообще, а where country будет менее эффективным.
Так же phone+country скорее всего (в зависимости от оптимизатора скл) работать не будет с таким индексом.
Да, верно.---------- Добавлено 13.09.2013 в 21:07 ----------
1-800-MY-APPLE ?
Для хранения - нормально.
Для вставки - Х запросов вместо одного, приложение должно будет само решать вопросы целостности данных.
Для поиска - как Вы будете искать в контактах человека у которого в телефоне есть вхождение 812 (одна таблица), при этом он носит белые штаны (другая таблица) и никогда не был в рио-де-жанейро (третья таблица + негативная выборка) но при этом был в москве (третья таблица и позитивная выборка)? EAV усложняет эту задачу само по себе, а несколько таблиц забивают гвоздь в крышку гроба:)
