Имя пользователя:
Пароль:  
Помощь | Регистрация | Забыли пароль?  | Правила  

Компьютерный форум OSzone.net » Компьютеры + Интернет » Вебмастеру » Mysql, оптимизация таблицы (создание индексов)

Ответить
Настройки темы
Mysql, оптимизация таблицы (создание индексов)

редкий гость


Сообщения: 1696
Благодарности: 44

Профиль | Сайт | Отправить PM | Цитировать


Есть таблица с (условно четырьмя полями): data (тип неважен), visible,
show_in_main, pub_date (DATETIME)

Требуется наиболее эффективно выполнять выборки типа (опять же неточно)
SELECT data, pub_date FROM tbl WHERE visible AND show_in_main AND
pub_date >= somedate AND pub_date < someother_date

Вопросы:
1. visible и show_in_main лучше сделать какого типа? Пока TINYINT, но
может ENUM или какой другой инт будет эффективнее?
2. По каким колонкам создавать индекс? Вижу три варианта:
a. (visible, show_in_main) и pub_date
б. (visible, show_in_main, pub_date)
в. (pub_date, visible, show_in_main)

http://dev.mysql.com/doc/refman/4.1/...imization.html я понял не до конца.

Стоит отметить, что у абсолютного большинства строк в таблице visible=show_in_main=1. Так что, наверное, простой индекс по pub_date меня устроит. Но, всё же, хочется чуть лучшего решения.

-------
http://ivank.ru


Отправлено: 19:06, 05-03-2007

 

Аватара для vadimiron

Ветеран


Сообщения: 1864
Благодарности: 120

Профиль | Отправить PM | Цитировать


ivank
Я придерживаюсь политики создавать ключ по нейтральному от данных полю. То есть создаю столбик ID с auto_increment.
Единственный случай, когда я создаю ключ из самих данных, так это таблицы связи, чтобы избежать одинаковых записей.

Конечно, с такой политикой можно спорить, но у неё есть пара плюсов, которые меня убеждают:
Данные могут менятся: как тип так и название столбиков
Надо заботится, чтобы ключи были разные
При двухсторонней репликации баз данных без независимого от контекста данных ключа невозможно

И оптимизация: ничего быстрого, чем выборка по INT нет, или лучше сказать, выборка достаточно быстрая

И архитектура получается чистая и гибкая, у каждого объекта есть ID, и со временем могут поменятся хоть все столбцы, но сам объеект останется со всеми связями

Отправлено: 12:20, 06-03-2007 | #2



Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

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


Ночной странник


Contributor


Сообщения: 4050
Благодарности: 83

Профиль | Сайт | Отправить PM | Цитировать


ivank
я бы наверное выбрал пункт 3 т.к. в этом случае объем ключей будет наверное минимален.
а вообще на скорость подобной выборки будет очень влиять настройки базы данных.

-------
можно практически все, но просто мы это еще не знаем.
главный враг програмиста это копипастинг
За хорошее сообщение не забываем нажимать ссылочку "Полезное сообщение"!


Отправлено: 12:38, 06-03-2007 | #3


Аватара для Prisoner

Engrossed by the Void


Сообщения: 2229
Благодарности: 60

Профиль | Сайт | Отправить PM | Цитировать


ivank, имхо, самое подлое в этой ситуации, что посоветовать что-то конкретное сложно - в современных СУБД очень много оптимизаций которые взаимозаменяют друг друга в зависимости от того, что есть на руках. К примеру если таблица для выборки очень мала (порядка 50 строк), то всегда будет использоваться медленное и обычно устраняемое связывание ALL, т.е. происходит прямое сканирование всей таблицы. В этом случае это быстрее чем все оптимизационные алгоритмы т.к. таблица умещается в памяти целиком. Вообще, лучше, имхо, почитать это и сделать самостоятельные выводы. А еще это.

Отправлено: 13:18, 06-03-2007 | #4


редкий гость


Сообщения: 1696
Благодарности: 44

Профиль | Сайт | Отправить PM | Цитировать


vadimiron
Первичный ключ айди есть. В рамках данной выборки его наличие нважно, так как сортировка идёт по дате, а выборка ещё по двум признакам данных. Причём, поскольку данные могут забиваться задним числом, то порядок айди с порядком дат не совпадает. Весь вопрос в том, как подобный запрос выполнить наиболее эффективно. айди используется только для показа/редактирования отдельных записей.

Prisoner
Я кажется уже выше отметил, что документацию по индексам и тому, как они влияют на скорость выборки/сортировки понял не в полном объёме. Иначе бы здесь вопрос не задавал. А EXPLAIN сейчас мой лучший и единственный друг. Просто надоело экспериментальным путём подбирать оптимальную структуру, хочется закономерностей. Видимо, единственный метод, который позволит с ними разобраться - проб и ошибок.

-------
http://ivank.ru


Отправлено: 13:47, 06-03-2007 | #5

mar mar вне форума

Аватара для mar

just mar


Moderator


Сообщения: 3898
Благодарности: 160

Профиль | Отправить PM | Цитировать


ivank
так ведь - либо парсить код самого mysql, чтобы понять, как именно в ней реализованно то, или иное, либо положиться на документацию, либо - опыты на кошках (Влад, например, утверждает, что опытным путем обнаружил тормоза при работе LEFT JOIN - что-то я не припомню, чтобы в документации в этом признвались, но опыт показал). (С учетом некоторой вольности mysql в обращении c SQL вообще ) А что именно кажется смурным в документации?

Отправлено: 00:33, 07-03-2007 | #6


Ночной странник


Contributor


Сообщения: 4050
Благодарности: 83

Профиль | Сайт | Отправить PM | Цитировать


mar
Цитата:
Влад, например, утверждает, что опытным путем обнаружил тормоза при работе LEFT JOIN - что-то я не припомню, чтобы в документации в этом признвались, но опыт показал
тормоза возникают на из-за самого JOIN (на важно какого) а из-за процессов которые при этом возникают: пораждается большая временная таблица, которая зачастую записывается на жесткий диск + выборки по большой таблице а еще возможно и без индексов идут не очень быстро...

-------
можно практически все, но просто мы это еще не знаем.
главный враг програмиста это копипастинг
За хорошее сообщение не забываем нажимать ссылочку "Полезное сообщение"!


Отправлено: 10:48, 07-03-2007 | #7

mar mar вне форума

Аватара для mar

just mar


Moderator


Сообщения: 3898
Благодарности: 160

Профиль | Отправить PM | Цитировать


Vlad Drakula
ага, спасибо. Короче, твой опыт выявил локальный глюк mysql , т.е. говорит о том, что метод научного тыка бывает полезен (теория тут явно бы не подошла)

Отправлено: 17:47, 07-03-2007 | #8



Компьютерный форум OSzone.net » Компьютеры + Интернет » Вебмастеру » Mysql, оптимизация таблицы (создание индексов)

Участник сейчас на форуме Участник сейчас на форуме Участник вне форума Участник вне форума Автор темы Автор темы Шапка темы Сообщение прикреплено

Похожие темы
Название темы Автор Информация о форуме Ответов Последнее сообщение
MySQL - [решено] отображение таблицы в Mysql TigerZaka Программирование и базы данных 2 21-08-2008 22:00
MySQL - Сколько лучше назначить индексов для таблицы? tolbol Программирование и базы данных 5 23-07-2008 10:01
MySQL - большие таблицы XCodeR Вебмастеру 4 28-08-2005 11:40
выборка случайной строки из таблицы на MySQL Vlad Drakula Вебмастеру 5 19-10-2004 05:55
Удаление записей из таблицы MySQL unknown Вебмастеру 3 21-05-2003 14:54




 
Переход