Недостатки цитирования целых чисел в запросе Mysql?

мне любопытно невыгоде цитирование целых чисел в MYSQL запросовНедостатки цитирования целых чисел в запросе Mysql?

Например

SELECT col1,col2,col3 FROM table WHERE col1='3';

SELECT col1,col2,col3 FROM table WHERE col1= 3;

Если есть снижение производительности, что размер его и почему это происходит? Есть ли другие недостатки, кроме того, что производительность?

Благодаря Эндрю

Edit: Причина этого вопроса
1. Потому что я хочу, чтобы понять разницу, потому что мне интересно
2. Я экспериментировал с пути прохождения составных ключей от моя база данных в моем php-коде как psudo-Id-keys (PIK). Эти ПИК используются для таргетинга на запись. Например, если первичный ключ (AreaCode, категория, RecordDtm)

Мой PIK в URL будет выглядеть следующим образом:

index.php?action=hello&Id=20001,trvl,2010:10:10 17:10:45

И я выбрал бы эту запись так:

$Id = $_POST['Id'];//equals 20001,trvl,2010:10:10 17:10:45 
$sql = "SELECT AreaCode,Category,RecordDtm,OtherColumns.... FROM table WHERE (AreaCode,Category,RecordDtm) = ({$Id}); 
$mysqli->query($sql): 
......and so on.

В этот момент запрос не будет работать из-за datetime (который должен быть указан), и он открыт для SQL-инъекции, потому что я не избежал этих значений. Учитывая тот факт, что я не всегда буду знать, как построены мои PIK, я бы написал функцию, разделяющую Id PIK в запятых, очищает каждую часть с помощью real_escape_string и помещает ее обратно вместе со значениями, указанными. Например: $ Id = "'20001', 'trvl', '2010: 10: 10 17:10:45'" Конечно, в этой функции, которая разламывается и очищает идентификатор, я могу проверить, действительно ли значение это число или нет. Если это число, не цитируйте его. Если это ничего, кроме строки, то процитируйте ее.

источник

2011-02-07 andrew

Почему бы просто не делать правильные вещи, а не беспокоиться о том, что синтаксический анализатор запросов исправит ваши ошибки? –

Почему бы не всегда придерживаться * чего-то, а не беспокоиться о преждевременных оптимизациях? – strager

Потому что я хочу узнать немного больше о том, почему мы не просто всегда ставим кавычки вокруг всех значений в запросах. Я экспериментирую с тем, чтобы передавать составные ключи из базы данных в виде одного идентификатора psudo в PHP-коде. – andrew

-1

Have a look at this. Они провели некоторые оценки эффективности между различными типами полей.

источник

2011-02-07 06:16:35

Это типы данных, а не неявное преобразование. Во-вторых, размеры типов данных различны - VARCHAR (4) принимает такое же количество байтов, что и INT. –

По моему мнению, в случае, о котором вы упомянули, нет стоимости исполнения/размера. Даже если есть, то это очень незначительно и не повлияет на ваше приложение как таковое.

источник

2011-02-07 06:18:27

Да, но, конечно, это упрощенный пример. У меня нет ни одного запроса, который бы так прост. Я думаю, что @Chris Henry хорошо объясняет этот факт, что в более сложном запросе это вызовет проблему с производительностью. – andrew

@Andrew - @Chris объясняет производительность накладных расходов в сочетании с Joins, что является правильным. Но в случае, если его единственное неявное преобразование типа для проверки экуативности в условии where, оно все равно незначительно. Проверьте также ответ Дэвида, который дает экспериментальные значения. –

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

SELECT col1, col2, col3 FROM table WHERE col1 = '3';

Если col1 не является строковым типом, MySQL должен преобразовать '3' в этот тип. Этот тип запросов на самом деле не имеет большого значения, поскольку накладные расходы на производительность этого преобразования составляют пренебрежимо мало.

Однако, когда вы пытаетесь сделать то же самое, когда, скажем, соединяете 2 таблицы, каждая из которых содержит по несколько миллионов строк.Если столбцы в предложении ON не то же типа данных, то MySQL будет конвертировать несколько миллионов строк каждый раз, когда выполнения запроса, и что где накладная производительность приходит.

источник

2011-02-07 06:23:12

Я этого не совсем понимаю. Разве он не просто конвертировал бы тип данных один раз для всего запроса? Т.е. конвертировать '3' в 3 в начале, а затем использовать его? – andrew

По вашему запросу, да, преобразование будет сделано один раз. Однако при присоединении для правильного сравнения соединяемые столбцы должны быть одного и того же типа, следовательно, преобразуя каждую строку в таблицу. –

интересный.Я вижу, как это будет очень медленно. Спасибо – andrew

Это дает неправильное представление о типе данных для столбца. Как посторонний, я полагаю, что колонка, о которой идет речь, CHAR/VARCHAR & соответственно выбирает операции.

В противном случае MySQL, как и большинство других баз данных, будет неявно преобразовывать значение в любой тип данных столбца. В этом нет никакой проблемы с производительностью, о которой я знаю, но существует риск того, что поставка значения, требующего явного преобразования (с использованием CAST or CONVERT), приведет к ошибке.

источник

2011-02-07 06:23:33

В моей практике у меня были случаи, когда mysql неожиданно выбрасывал не постоянное значение (цитированное целое число), а само поле. Таким образом, индекс не использовался. – zerkms

Что такое CAST и CONVERT? – andrew

@andrew: Я понял, что это то, что вы используете для явного изменения типов данных, но на всякий случай я добавил ссылку на документацию. –

Строки также имеют другой порядок сортировки по номерам.

Сравнить:

SELECT 312 < 41

(выходы 0, потому что 312 численно приходит после того, как 41)

к:

SELECT '312' < '41'

(выходами 1, потому что '312' лексикографически до «41»)

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

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

источник

2014-06-03 10:37:28 Thomas

Недостатки цитирования целых чисел в запросе Mysql?

ответ

Смежные вопросы