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

Question

У меня есть таблица с ~ 1,2 м строк в нем.Он имеет 6 проиндексированных столбцов, включая одно поле varchar (255), содержащее URL-адреса.

Мне нужно иметь возможность сканировать таблицу, чтобы увидеть, существует ли URL-адрес в таблице, следовательно, индекс, но яИнтересно, смогу ли я увидеть прирост производительности за счет уменьшения размера индекса примерно до 50?

Конечно, это может означать, что при поиске URL-адреса в базе данных может потребоваться сканирование большего количества строк ... но у меня есть толькоделать этот запрос примерно каждые 30 секунд, поэтому мне интересно, будет ли стоить меньший размер индекса.Мысли? * * 1005

Answer 1

Из моего учебника по индексированию SQL (также охватывает MySQL) :

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

Это общее правило, которое я предлагаю, пока нет очень веской причины сделать что-то другое.

Пространство не является проблемой, в большинстве случаев.

С точки зрения производительности, глубина дерева индексов логарифмически возрастает с увеличением числа конечных узлов индекса. Это означает, что сокращение размера индекса на половину, вероятно, вовсе не уменьшает глубину дерева. Следовательно, прирост производительности может быть ограничен улучшенной частотой обращений к кешу. Но вы упомянули, что выполняете этот запрос каждые 30 секунд. На умеренно загруженной машине это означает, что ваш индекс не будет кэшироваться вообще (за исключением, может быть, вы ищете один и тот же URL каждые 30 секунд).

В конце концов: я не вижу причин действовать против общего совета, упомянутого выше.

Если вы действительно хотите сохранить индексное пространство, попробуйте сначала найти избыточные индексы (например, те, которые начинаются с тех же столбцов). Обычно это низко висящие фрукты.

Answer 2

Две причины, почему снижение может быть лучше - (Предполагая, что ваш индекс полезен)

1) Индексы тоже загружаются в память, так что может быть редкая вероятность того, что размер вашего индекса увеличится до такой степени, что он не будет полностью кэшироваться в памяти. Вот когда вы увидите снижение производительности (со всеми новыми характеристиками оборудования ... вряд ли это возможно с 1,2M строк, но все же стоит отметить).

2) Во многих случаях достаточно первых символов n, чтобы можно было быстро идентифицировать каждую запись. Вам может не потребоваться индексировать целые 255 символов вообще.

Две причины, по которым вам может быть все равно -

1) Как уже говорилось, вы, возможно, никогда не увидите, что ваши индексы растут вне вашего ключевого буфера, так что волнуйтесь.

2) Вам нужно будет определить первые n символов, и даже после этого производительность будет меньше или равна полному индексу ... никогда больше. Вам действительно нужно тратить время на это? Стоит ли возможной потери точности?

Answer 3

Храните хэш md5 для вашего url с фиксированной длиной 32.

Answer 4

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

Поскольку это столбец VARCHAR, индексированные значения будут в любом случае равны длине каждого URL, поэтомупросматривая типичные URL-адреса, вы можете индексировать только около 50 символов для каждого URL-адреса.

Даже если все URL-адреса значительно длиннее, уменьшение размера индекса может просто увеличить вероятность того, что эта часть индекса уже находится в памяти.Но опять же я сомневаюсь, что вы заметили бы разницу.Это может быть полезно только в том случае, если объем был очень большим, и вам нужно было начать микрооптимизацию для дополнительной производительности.

Answer 5

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

Наличие или отсутствие индекса может основываться на ваших операциях CRUD, у вас есть больше вариантов выбора или больше операций вставки / обновления / удаления?