MySQL PHP | «ВЫБРАТЬ ИЗ таблицы», используя «буквенно-цифровой» -UUID. Скорость против индексированного целого числа / индексированного символа - PullRequest
0 голосов
/ 11 июня 2010

В данный момент я выбираю строки из таблиц table01 и table02, используя:

SELECT t1.*,t2.* FROM table01 AS t1 
INNER JOIN table02 AS t2 ON (t1.ID = t2.t1ID) 
WHERE t1.UUID = 'whatever';

Столбец UUID представляет собой уникальный индекс, тип: char (15), с буквенно-цифровым вводом.Я знаю, что это не самый быстрый способ выбора данных из базы данных, но UUID является единственным идентификатором строки, доступным для внешнего интерфейса.

Поскольку я должен выбирать по UUID, а неID, мне нужно знать, какой из этих двух вариантов я должен использовать, если, скажем, таблица состоит из 100 000 строк.На какие различия в скорости я бы посмотрел, и увеличился ли бы индекс UUID и стал бы отставать от БД?

Получить идентификатор перед выполнением "большого" выбора

1. $id = SELECT ID FROM table01 WHERE UUID = '{alphanumeric character}';
2. SELECT t1.*,t2.* FROM table01 AS t1 
   INNER JOIN table02 AS t2 ON (t1.ID = t2.t1ID) 
   WHERE t1.ID = $id;

Илисохраните его таким, каким он является сейчас, используя UUID.

2. SELECT t1.*,t2.* FROM table01 AS t1 
   INNER JOIN table02 AS t2 ON (t1.ID = t2.t1ID) 
   WHERE t1.UUID = 'whatever';

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

Ответы [ 2 ]

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

Почему бы просто не попробовать?Создайте новую базу данных с этими таблицами.Напишите быстрый скрипт php, чтобы заполнить таблицы большим количеством записей, чем вы можете себе представить (если вы ожидаете 100 000 строк, вставьте 10 миллионов).Затем поэкспериментируйте с различными индексами и запросами (помните, EXPLAIN - ваш друг) ...

Когда вы, наконец, получите то, что, по вашему мнению, работает, поместите запрос в скрипт на веб-сервере и нажмите на него ab (Apache Bench).Вы можете наблюдать за тем, что происходит, когда вы увеличиваете параллелизм запросов (1 за один раз, 2 за один раз, 10 за один раз и т. Д.).

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

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

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

...