В настоящий момент я выбираю строки из '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';
Боковое примечание: все новые строки создаются, проверяя, существует ли система, сгенерированная uniqueidid, прежде чем пытаться вставить новую строку. Сохранение столбца всегда уникальным.
Почему бы просто не попробовать? Создайте новый db с этими таблицами. Напишите быстрый php script, чтобы заполнить таблицы большим количеством записей, чем вы можете себе представить, чтобы быть сохраненным (если вы ожидаете 100k строк, вставьте 10 миллионов). Затем экспериментируйте с разными индексами и запросами (помните, EXPLAIN
- ваш друг)...
Когда вы, наконец, получите то, что, по вашему мнению, будет работать, поместите запрос в script на веб-сервере и нажмите его с помощью ab
(Apache Bench). Вы можете наблюдать, что происходит, когда вы увеличиваете concurrency запросов (по одному за раз, по 2 за раз, по 10 за раз и т.д.).
Все это не должно занимать слишком много времени (может быть, не больше нескольких часов), но это даст вам лучший ответ FAR, чем любой из пользователей SO в случае вашей конкретной проблемы (поскольку мы не знаем вашу конфигурацию сервера БД, точная схема, ограничения памяти и т.д.)...
Второе решение имеет лучшую производительность. Вам нужно будет искать строку по UUID в обоих решениях, но в первом решении вы сначала выполняете ее с помощью UUID, а затем выполняете быстрый поиск по первичному ключу, но тогда вы уже нашли правильную строку по UUID, поэтому неважно, что второй поиск быстрее, потому что второй поиск совсем не нужен.