MySQL: огромная таблица. не может запросить, даже простой выбор!

Question

У меня есть таблица с около 200 000 записей. простой запрос выбора занимает много времени. Я в замешательстве, потому что я работаю под 4-ядерным процессором и 4 ГБ оперативной памяти. как мне написать мой запрос? или это как-то связано с INDEXING?

важное примечание: моя таблица статична (данные не изменяются).

каковы ваши решения?

PS

1 - у моей таблицы есть первичный ключ id

2 - мой стол имеет уникальный ключ serial

3 - я хочу запросить другие поля, например where param_12 not like '%I.S%' или where param_13 = '1'

4 - 200 000 невелики, и именно поэтому я удивлен.

5 - у меня даже возникают проблемы при добавлении простого поля: мой вопрос

6 - могу ли я создать INDEX для полей BOOL? (или это полезно)

PS и спасибо за ответы

7 - мой выбор должен вернуть поля, которые указали «I.S» или нет.

select * from `table` where `param_12` like '%I.S%'

это все, что я хочу. Кажется, никакой индекс здесь не помогает. ветчина

Answer 1

Индексация поможет. Пожалуйста, оставьте определение таблицы и выберите запрос.
Добавьте индекс для всех столбцов "=" в предложении where.

Answer 2

Да, вам нужно / нужно проиндексировать эту таблицу, а разделение также будет полезно. Чтобы сделать это правильно, вам нужно предоставить больше информации. Вы захотите использовать EXPLAIN PLAN и просмотреть свои запросы, чтобы определить, какие столбцы и как их индексировать.

Еще один аспект, который следует учитывать, - нормализована ли ваша таблица. Нормализованные таблицы, как правило, дают лучшую производительность из-за снижения ввода-вывода.

Я понимаю, что это расплывчато, но без какой-либо дополнительной информации, которая может быть настолько конкретной, насколько это возможно.

Кстати: таблица из 200 000 строк является относительно небольшой.

Здесь - еще один вопрос, который вы можете найти полезным

Answer 3

Если вы запрашиваете данные с помощью LIKE '%asdasdasd%', то никакой индекс вам не поможет. Он должен будет делать полное сканирование каждый раз. Проблема здесь в ведущем %, поскольку это означает, что искомая подстрока может находиться в любом месте поля, поэтому она должна проверить все это.

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

Answer 4

Индекс на param_13 может использоваться, но не на param_12 в этом примере, так как использование LIKE '% сводит на нет использование индекса.

Answer 5

1 - моя таблица имеет идентификатор первичного ключа: на самом деле бесполезно, если вы не используете схему, для которой требуется числовой первичный ключ

2 - моя таблица имеет уникальный серийный ключ: идентификатор также уникален по определению; почему бы не использовать серийный в качестве основного? Этот автоматически индексируется, потому что вы определили его как уникальный.

3 - я хочу выполнить запрос к другим полям, например, где param_12 не похож на '% I.S%' или где param_13 = '1': запрос like '%something%' не может действительно использовать индекс; есть ли способ, которым вы можете изменить param12 на param12a, который является первым%, и param12b, который равен 'I.S%'? Индекс можно использовать в операторе like, если начальная строка известна.

4 - 200 000 невелико, и именно поэтому я удивлен: да, 200 000 не так уж много. Но без хороших индексов, запросов и / или размера кэша MySQL потребуется для чтения всех данных с диска для сравнения, что является медленным.

5 - у меня даже проблема при добавлении простого поля: мой вопрос

6 - могу ли я создать INDEX для полей BOOL? Да, вы можете, но индекс, который соответствует половине времени, довольно бесполезен, индекс используется для ограничения количества записей, которые MySQL должен загружать максимально полно; если индекс существенно не ограничивает это число, как это часто бывает с логическим значением (в распределении 50-50), использование индекса требует только большего дискового ввода-вывода и может замедлить поиск. Поэтому, если вы не ожидаете что-то вроде распределения 80-20 или лучше, создание индекса будет стоить времени, а не выигрыша.

Answer 6

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

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

Вы правы: 200К не огромная таблица.ОБЪЯСНИТЬ ПЛАН поможет здесь.Если вы видите TABLE SCAN, измените дизайн.

Answer 7

Во-первых, убедитесь, что у вашей таблицы есть первичный ключ.

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