Оптимизация MySQL путем сортировки строк

Question

Оптимизация MySQL путем сортировки строк

0

Я не являюсь экспертом MySQL, и у меня есть много поисков о следующей проблеме, не найдя решение.

Итак, я использую таблицу MySQL с этой структурой:

CREATE TABLE photos (
  file varchar(30) NOT NULL default "",
  place tinytext NOT NULL default "",
  description tinytext NOT NULL default "",
  type char(1) NOT NULL default "",
  taken year NOT NULL default "0000",
  modified tinyint NOT NULL default 0,
  PRIMARY KEY (file)
);

Первый параметр - относительный путь к файлу. Он используется как первичный ключ.

В настоящее время строки не сортируются (это означает, что порядок, который я наблюдаю в phpMyAdmin, по умолчанию - это порядок, в котором элементы были вставлены в таблицу).

Поскольку 99% доступа к этой таблице являются SELECT (INSERT и UPDATE редки в моей программе), я полагаю, что я должен добавить INDEX в файл столбца (почти все SELECT используют только этот столбец).

Однако мой вопрос: "Не было бы лучше всегда хранить строки по алфавиту" файла ", а не создавать индекс?" и так: "можно ли сообщить MySQL, что данные сортируются в этом порядке и заставляют его сохранять этот порядок при вставке элементов в таблицу?".

Я не уверен, что мои вопросы действительно имеют смысл, потому что, может быть, это просто частный случай, когда в таблице уже есть какой-то индекс... Но мне действительно хотелось бы получить ответ...

Спасибо заранее!

Peter Potrowl 23 нояб. 2009, в 08:44

Источник

Теги:

mysql

optimization

sql

indexing

3 ответа

3

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

И в ответ на ваш вопрос о том, можете ли вы сохранить строки, отсортированные в СУБД, вы не сможете. SQL - это реляционная алгебра, которая будет извлекать строки в любом порядке, если вы специально не используете предложение order by.

При выполнении запроса:

select * from photos;

нет гарантии, в каком порядке вам будут доставлены строки. С другой стороны:

select * from photos order by file;

гарантирует порядок, а индекс первичного ключа file будет использоваться для извлечения записей в этом порядке. Не должно быть никакой сортировки или другого штрафа за производительность, поскольку индекс первичного ключа создается для упорядоченного доступа к строкам.

Лучше всего думать о первичном ключе как о специальном типе индекса. Вы можете, конечно, индексировать другие столбцы, если считаете это необходимым (хотя, похоже, это не так).

paxdiablo 23 нояб. 2009, в 05:23

0

Короткий ответ: вам все равно.

В чистом SQL, как отметил pax, есть нет понятия о том, как хранятся данные. Если вы хотите использовать столбец для доступа, тогда укажите индекс - который будет почти всегда автоматически выполняется, если вы укажете Основной ключ.

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

Thorsten 23 нояб. 2009, в 06:11

Ещё вопросы

Michael Buen · Accepted Answer · 2009-11-23T04-35-00.000Z

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

Это называется кластеризованным индексом на языке MSSQL. Хотя выполнение ORDER BY в поле файла (с кластеризованным индексом) ускоряет ваш запрос, вставка записей может замедляться из-за физического переупорядочения (см. разбиение на страницы) записей; поскольку значения входных файлов не являются последовательными по своему характеру. Кластеризованный индекс идеален для автоматически увеличивающегося первичного ключа или любого идентификатора, который последовательно вводится в базу данных. Или, возможно, вы можете увеличить размер страницы вашего кластерного индекса в своем поле файла, так что разбиение страниц не произойдет. Для причины может быть только один кластеризованный индекс для таблицы.

[EDIT: 23 ноября 2009 г. 17:55 CN]

Привет, Питер, Mysql кластеризованный индекс. Mysql, хотя он поддерживает кластерный индекс, он может делать это только на первичном ключе. Если ваше поле имени файла действительно является первичным ключом, вы можете указать на нем кластеризованный индекс. Кластерный индекс для MySQL предназначен только для первичного ключа, а MSSQL - для любого поля. Кластеризованный индекс, отличный от первичного ключа, полезен, например, база данных контактов; хотя идентификатор учетной записи (какой-то внутренний номер, который не обращен к пользователю) является первичным ключом, более разумно назначать кластерный индекс имени контакта, потому что, поскольку вы часто представляете список контактов пользователям, думайте, что iPhone или какой-либо контакт с смартфоном базы данных или CRM и т.д., они часто перечисляют контакты, используя имя, а не их номер телефона и их внутренний идентификатор (первичный ключ (думаю, guid или целое число))

Это замечательно, если ОП использовал SQL Server ...
@OMG Пони: Во-первых: что плохого в том, чтобы знать о кластеризованном индексе, даже если вы используете RDBMS, которая их не поддерживает? ОП, очевидно, нужна помощь с основами реляционных баз данных. Второе: хотя движок MyISAM вообще не поддерживает кластеризованные индексы, InnoDB организует все таблицы как кластерный индекс на основе B-Tree.
Спасибо, Майкл! Я попробую кластерный индекс. Мне действительно нужно это на мой первичный ключ!