Есть ли какая-либо разница в производительности между использованием текстовых и целочисленных и встроенных в приложение константных столбцов типа в MySQL и php?

0

В моем случае у меня есть таблица, в которой хранится коллекция записей с подобной информацией, но каждая из которых имеет уникальный столбец типа, используемый в различных частях моего приложения. Я знаю, я знаю, что это "микро-оптимизация", но она является неотъемлемой частью моего приложения (она будет хранить много записей), и я бы хотел, чтобы она была оптимизирована, и мне также просто интересно, быстрее ее использовать тип текста и выберите его как
SELECT... WHERE type = 'some_type' или использовать константу PHP, такую как const SOMETYPE = 1; run_query ('SELECT... WHERE type ='.SOMETYPE); ?

  • 0
    В интерпретируемом языке, таком как php, CONSTANT заменяется каждый раз, когда вы запускаете код, и тогда оптимизация не так хороша. При тестировании может быть много причин, почему это не имеет значения, например, сколько запросов в секунду вы будете выполнять, оптимизация вашего сервера и т. Д.
  • 0
    И нам нужно знать, объявлены ли они как «define ()» или как «const Constant»
Показать ещё 3 комментария
Теги:
optimization
performance
constants

2 ответа

0

Доминирующее время, затрачиваемое на любой запрос, - это выбор строк для работы. Функции, строка vs int и т.д. Делают лишь незначительные различия в производительности. Сосредоточьтесь на том, что чисто для вашего кода, и что сводит к минимуму количество затронутых строк.

Как только вы это сделаете, свести к минимуму количество обратных рейсов на сервер. Тем не менее, я создал много веб-страниц, которые выполняют 20-50 запросов (каждая из них оптимизирована); производительность страницы адекватна.

Вы также можете рассмотреть тип данных ENUM.

sex ENUM('unk', 'male', 'female') NOT NULL

дает вам WHERE sex = 'male', реализуемый как однобайтное целое число под обложками.

0

Сравнение строк всегда будет медленнее, чем целочисленное сравнение. Как правило, выполняется то, что строка хранится в отдельной таблице, возможно, называется standard_types или тем, что имеет смысл для хранения "констант". В этой таблице есть уникальное поле id, на которое могут ссылаться другие таблицы.

Таким образом, если вам нужны строки для отчетности, запросы отчетности могут присоединиться к таблице "типы" для строк отображения. В идеале, на мой взгляд, значения id должны отражать стандартные числа, которые могут быть выражены как значения перечисления или константы в клиентском коде; это минимизирует зависимость от таблицы "типы" для запросов без отчетности.

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

  • 0
    @Uuerdo, пожалуйста, уточните. так ты имеешь в виду, что не будет заметной разницы в производительности, если я использую строковый тип в db или числовой тип wuthin db и обращаюсь к ним в PHP с помощью констант ??
  • 0
    Нет, я говорю, что числовые типы почти всегда быстрее, независимо от того, являются они постоянными или нет, не имеет значения. Я просто говорил, что вы можете получить лучшее из обоих миров, сохранив строки один раз в отдельной таблице поиска и сославшись на них по числовому идентификатору; так что фактическое связывание происходит с числовыми значениями идентификаторов для этих строк; и если значения идентификатора известны заранее, будучи enum или постоянными значениями на стороне клиента; на строку никогда не нужно ссылаться напрямую.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню