Разработка индекса MySQL с разделением таблиц - PullRequest
Новая
       15

Разработка индекса MySQL с разделением таблиц

0 голосов
/ 11 июня 2011

У меня есть 2 таблицы MySQL со следующими схемами для веб-сайта, похожего на журнал. 

Article (articleId int auto increment ,
         title varchar(100),
         titleHash guid -- a hash of the title
         articleText varchar(4000)
         userId int)

User (userId int autoincrement
      userName varchar(30)
      email etc...)

Самый важный запрос: 

select title,articleText,userName,email 
from Article inner join user
on article.userId = user.UserId
where titleHash = <some hash>

Я думаю об использовании вместе столбцов articleId и titleHash в качестве кластеризованного первичного y для таблицы Article. И userId, и userName в качестве первичного ключа для пользовательской таблицы. Поскольку поиск будет основываться на столбцах titlehash и userName.

Кроме того, titlehash и userName не являются обязательными по конструкции и не изменяются в обычном режиме.

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

Я собираюсь использовать разбиение таблиц mysql на столбце titlehash, чтобы выборки выполнялись быстрее, поскольку БД сможет использовать исключение разделов на основе этого столбца.

Я использую innoDB в качестве механизма хранения;

Итак, вот мои вопросы;

  1. Нужно ли создавать еще один индекс столбец titlehash в качестве основного ключ (articleId, titlehash) не является хорошо для поиска на titlehash столбец как второй столбец по первичному ключу?

  2. Какие проблемы с этим дизайн?

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

Я из сервера SQL и собираюсь использовать mysql, поскольку использование разделов на сервере SQL обойдется мне в целое состояние, поскольку оно доступно только в редакции Enterprise.

Итак, гуру БД, пожалуйста, помогите мне; Большое спасибо.

1 Ответ

1 голос
/ 11 июня 2011

Как написано, ваш "самый важный запрос" на самом деле, кажется, вообще не включает таблицу User.Если чего-то не хватает, лучший способ ускорить это - вывести таблицу User из картинки и создать индекс для titleHash.Boom, done.

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

Учитываяваши изменения, все, что должно быть необходимо, насколько должны быть ключи:

  • Вкл. Article:
    • PRIMARY KEY (articleId) (без дополнительных столбцов, не пытайтесь придумывать)
    • KEY (userId)
    • UNIQUE KEY (titleHash)
  • Вкл. User:
    • PRIMARY KEY (userId)

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

Прежде всего, протестируйте с реальными данными и посмотрите на результаты EXPLAIN запроса.

...