Дилемма ключа MySQL

Question

У меня есть таблица, которая кэширует данные (общий хостинг, поэтому нет memcached) в таблицу MySQL.

Концепция такова:

У меня есть страница, которая загружает (статические) данные, а затем кеширует их:

• Если кеша не существует, он запрашивает страницу, затем отображает HTML и сохраняет его в таблице кеша.
• Если страница не существует в кэше, она выполняет 12 запросов (меню, содержимое страницы, SEO, список продуктов и т. Д.), А затем сохраняет отображаемый HTML-код в таблице.

Таблица кеша выглядит так:

=cache=
url varchar(255) - primary key
page mediumtext

Теперь я думаю, что поступаю правильно, основываясь на том, что у меня есть (общий хост, нет кэширования, как memcached и т. Д.), Но мой вопрос таков:

Поскольку URL является индексом varchar, а числовые идентификаторы (например, int) быстрее, есть ли способ преобразовать URL, например /contact-us/ или /product-category/product-name/, в уникальное целое число? Или есть другой способ оптимизировать это?

Answer 1

Я бы создал некоторую форму хэша, которая позволила бы использовать более короткий ключ. Во многих случаях может быть полезным что-то простое, например, хэш пути запроса. В качестве альтернативы что-то еще более простое, например, CRC32 ('/ your / path / here'), может подойти в вашей ситуации в качестве первичного ключа. В этом примере следующие столбцы будут существовать

 urlCRC INT(11) UNSIGNED NOT NULL (PRIMARY KEY)
 url VARCHAR(255) NOT NULL
 page MEDIUMTEXT

Затем вы можете сделать еще один шаг и добавить триггер BEFORE INSERT, который будет вычислять значение для urlCRC, т.е. содержащее

NEW.urlCRC = CRC32(NEW.url)

Затем вы можете создать хранимую процедуру, которая принимает в качестве аргумента inURL (string), и внутренне это будет делать

SELECT * FROM cacheTable WHERE urlCRC = CRC32(inURL);

Если количество возвращаемых строк равно 0, то вы можете запустить логику для его кэширования.

Это, конечно, может быть излишним, но даст вам числовой ключ для работы, которого, при условии отсутствия конфликтов, будет достаточно. Сохраняя URL-адрес как VARCHAR (255), также, если возникает конфликт, вы можете легко восстановить новые хеши, используя другой алгоритм.

Просто чтобы прояснить ситуацию, я просто использую CRC32 () в качестве примера на макушке, скорее всего, есть более подходящие алгоритмы. Главное, на что следует обратить внимание, так это на то, что числовой ключ более эффективен для поиска, поэтому, если вы сможете преобразовать свои строки в уникальные числовые значения, это будет более эффективным при получении данных.

Answer 2

выберите все кэшированные URL-адреса с помощью хэша, затем найдите точный URL-адрес во всех коллизиях хешей

select page from (select * from cache where HASHEDURL = STOREDHASH) where url = 'someurl'

Answer 3

Изменение столбца url на строку фиксированного размера сделает индексирование немного быстрее, если в таблице не будет другого столбца динамического размера (TEXT). Преобразование его в целое число будет возможно, в зависимости от вашей структуры URL - вы также можете использовать какую-то хеш-функцию. Но почему ты не облегчаешь свою жизнь?

Вы можете сохранить результаты кеша непосредственно на диск и создать фильтр mod_rewrite (поместите его в ваш файл .htaccess), который соответствует, если файл существует, в противном случае вызывает скрипт PHP. Это будет иметь 2 преимущества:

1. Если кеш горячий, PHP не запустится. Это экономит время и память.
2. Если файл часто запрашивается и он достаточно мал (или у вас много оперативной памяти), он будет храниться в оперативной памяти. Это намного быстрее, чем MySQL.