SQL Мобильный телефон - char или int?

Когда это имеет смысл.

Если индекс типа country+phone, то поиск where country+phone будет эффективнее остальных вариантов.

Однако where phone будет без индекса вообще, а where country будет менее эффективным.

Так же phone+country скорее всего (в зависимости от оптимизатора скл) работать не будет с таким индексом.

Да, верно.

---------- Добавлено 13.09.2013 в 21:07 ----------

1-800-MY-APPLE ?

Тоже об этом подумал. Вот как раз от таких казусов и защищает стандарт. Прикольно, но тем у кого, номер означает GJDKFJJ не очень. :)

Это почему, если используется первая часть индекса?

Вообще-то говорят что в данном случае будет.

К номеру gjdkfjj наверняка можно подобрать более красивую расшифровку:) Фокус-то в том, что одной цифре соответствуют 3 буквы на выбор.

Потому что индекс на country+phone, а не на country. Избыточность менее эффективна.

В зависимости от оптимизатора sql. Не зря в мануалах специально указывают, что если хочется гарантированно использовать составной индекс, то в where нужно использовать тот же порядок, что и при задании индекса.

Результат составного индекса

1	0.00127900	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
2	0.00116100	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
3	0.00107100	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
4	0.00117800	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
5	0.00114800	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
6	0.00112300	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
7	0.00112500	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1

и результат простого индекса

1	0.00131500	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
2	0.00111600	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
3	0.00103800	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
4	0.00110100	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
5	0.00108400	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1
6	0.00107200	SELECT SQL_NO_CACHE * FROM search_visitors WHERE member=1

и честно говоря не вижу особой разницы. В таблице 100K записей

Из сказанного Вами прямо следует, что простые индексы использовать крайне глупо, ведь они "то же самое, только без бонусов составных". В подобном выводе есть легкий оттенок нелогичности, Вы так не считаете? :) Коронной идеей в данном случае будет повесить составной индекс на все поля сразу, пусть будет типа.

Еще раз - составной индекс - избыточен по отношению к простому. Это факт. Избыточность это плохо. Это тоже факт. Можно несколько поспорить на тему насколько это плохо, но это отдельный вопрос.

Что касается теста - забейте таблицу разными данными в индексируемых полях, забейте туда десяток миллионов записей, пусть размер будет хотя бы пара гигов для индексов и 10 для базы, протестируйте запросом на выборку с benchmark 10000 а не разовым sql_no_cache, посчитайте время построения индекса заодно, не забудьте протестировать скорость вставках с тем же бенчмарком - тогда это будет тест что-то показывающий. А пара одиночных запросов на неизвестно каких данным, на крошечных индексах и неизвестно как закэшированных данных (ФС тоже кэширует) - это не тест, а фикция.

edogs, стоп-стоп. Простой это отдельный индекс для каждого поля, составной это индекс для более одного поля, верно?

Не глупо. использовать простой индекс там, где нужен составной... Хотя не знаю, спорить не буду, может на пару десятков миллиардов записей и есть смысл делать отдельный простой индекс по мимо составного. С такими объемами не работал.

Да.

Тут даже дело не столько в больших данных, сколько в самом принципе тестирования.

99% что у Вас весь индекс, что составной что простой, в оперативке. Значит разница даже многократная по доступу к нему - в пределах погрешности будет, особенно с учетом того что на таблице в 100к записей и целочисленном индексе - пара мегабайт дай бог объем индекса. Опять же ОС может кэшировать дисковые операции, т.е. sql_no_cache особо не решает.

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

edogs, а смысл индекса KEY, который не в оперативке?