Простой вопрос относительно скорости MySQL

Question

Итак, я решил, что имена моих изображений должны храниться в MySQL. Так что я бы сохранил «1» в в моей базе данных MySQL.

Теперь я намерен назвать свои iamges просто цифрами, фактически, в автоинкременте. Но я должен назвать свое изображение? Потому что я слышал, что mysql может быть довольно медленным, и я не хочу, чтобы куча имен изображений в моей базе данных, если это заставит мою базу данных работать намного медленнее. Тем более что имена изображений на самом деле не так важны.

Кроме того, может ли автоинкремент ускорить работу моей базы данных, в отличие от нумерации вручную?

РЕДАКТИРОВАТЬ: совершенно не связанный вопрос. Я заметил, что некоторые люди / сайты разделяют свои изображения на более мелкие куски. Как то, что легко может быть одним изображением, разделено на несколько файлов изображений? Я не понимаю этого, особенно если учесть, что плата за хостинг amazon image hositng не взимается. Как в амазонке обвинения за картину тоже. Так почему люди разделяют изображения? У меня есть свои предположения, но я уверен, что это еще не все.

Answer 1

Хм .... не уверен насчет контекста вашего вопроса, но в целом MySQL является одним из самых быстрых механизмов баз данных, которые вы можете получить для умеренного использования (платные продукты, такие как Oracle и MS SQL Server, обычно лучше экстремальные требования). Хранение имени в виде строки не будет заметно медленнее, чем сохранение его в виде целого числа - но это поможет получить более полное представление о реальном приложении. Автоинкремент - разумный выбор для автоматического назначения первичного ключа; это гарантирует уникальность числа, даже если два процесса обращаются к таблице в одно и то же время. Опять же, с точки зрения производительности - я не думаю, что вы могли бы измерить разницу.

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

Answer 2

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

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

Вот обновление для второй части.Это зависит от того, что именно вы видите, но я бы склонялся к тому, чтобы это было одной из нескольких вещей.

1) Некоторые части изображения могут нуждаться в динамическом изменении, и это позволяет просто загружать / изменять битэто должно измениться, а не целое изображение.

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

3) Сайт создан по шаблону, предоставленному в виде файла psd.Это ужасные вещи, когда кто-то создает изображение веб-сайта в фотошопе или тому подобном, а затем разбивает его на кучу маленьких изображений, а затем они загружаются отдельно в таблицу или в div.

Answer 3

Из твоего вопроса не так ясно, что ты собираешься делать.Но я чувствую, что должен поделиться своим опытом.

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

Автоинкремент не будет строго ускорять вашу базу данных, но вы все равно должны избегать