|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
"Мягкая" система типов в MySQL, с неявным приведением по контексту - расслабляет. Сегодня очередной раз убедился, что за типами данных надо следить. Суть того, что получилось сегодня, продемонстрирую на модели. Создадим модельную таблицу: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Миллион записей, даты в пределах текущего года, в каждой записи - некое значение. Задача - для каждой даты подсчитать сумму этих неких значений. Предполагая, что не все даты имеются в таблице (генерация данных делает такую ситуацию почти нереальной, но предположим...), использовать генерируемую таблицу-календарь. То есть вроде бы запрос очевиден: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
На моей рабстанции этот модельный запрос выполняется где-то за 3,27-3,31 секунды. Конечно, запрос хочется немного ускорить. Создадим покрывающий индекс: Код: sql 1.
Отлично. Запрос выполняется за 2,88-2,92 секунды. Можно ли его ещё ускорить? Оказывается, можно, да ещё как! и всего-то для этого надо обратить внимание на типы. Поле dt в таблице, по которому выполняется связывание, имеет тип DATE. А что насчёт рекурсивного CTE? А вот там тип получающегося поля определяется якорем (нерекурсивным запросом), и оно - строковое! Изменим генератор календаря так, чтобы он сразу генерировал поле типа DATA: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Есть! время выполнения запроса уменьшилось вдвое, и теперь составляет 1,41-1,45 секунды. Если не создавать индекса, разница не столь значительна - начальные 3,27-3,31 секунды уменьшаются до 2,51-2,55 секунды. Но всё равно - вполне заметно. В общем, не надейтесь на MySQL, следите за типами сами. И вам воздастся. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 10:08 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
А если так? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В синтаксисе мог наврать, но идея, надеюсь, понятна. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2021, 01:50 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
miksoft А если так? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В общем, конечно, так ещё лучше. Без индекса и DATE - 1,61 Без индекса с DATE - 1,44 С индексом без DATE - 0,83 С индексом и DATE - 0,56 Разница от явного приведения типа - всё равно значительна. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2021, 08:02 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
Akina, очень полезно. CAST часто необходим оказывается. с agregat не понял но тоже + скорость. надо почитать ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2021, 23:50 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
Akina Без индекса и DATE - 1,61 Без индекса с DATE - 1,44 С индексом без DATE - 0,83 С индексом и DATE - 0,56 Разница от явного приведения типа - всё равно значительна. Код: sql 1. 2. 3.
А этот фрагмент сильно зависит от указания DATE ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2021, 00:37 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
Akina Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2021, 00:39 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
miksoft Akina Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2021, 01:23 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
ну и если кто-то хоть чуть-чуть заглядывал в С/С++ то там как правило указывать тип данных ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2021, 01:27 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
miksoft Что немного странно для столь малого набора данных - всего лишь сотни записей. miksoft А этот фрагмент сильно зависит от указания DATE ? Да собственно именно тут и нужно указание типа, именно этот DATE и убирался, что приводило к увеличению времени обработки. miksoft Кстати, сюда, наверное, тоже имеет смысл DATE вставить. нет, если в сравнении один из операндов имеет тип даты-времени, а второй константа, то второй приводится к этому типу. https://dev.mysql.com/doc/refman/8.0/en/type-conversion.html If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2021, 07:55 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
Akina miksoft А этот фрагмент сильно зависит от указания DATE ? Да собственно именно тут и нужно указание типа, именно этот DATE и убирался, что приводило к увеличению времени обработки. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 00:00 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
Akina miksoft Что немного странно для столь малого набора данных - всего лишь сотни записей. Akina miksoft А если так? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В общем, конечно, так ещё лучше. Без индекса и DATE - 1,61 Без индекса с DATE - 1,44 С индексом без DATE - 0,83 С индексом и DATE - 0,56 Разница от явного приведения типа - всё равно значительна. Агрегацию я специально предложил убрать в подзапрос, чтобы join с конвертацией был не на миллион записей, а на сотни. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 00:05 |
|
За типами данных надо следить!
|
|||
---|---|---|---|
#18+
miksoft а влияет всего лишь на несколько сотен конвертаций. miksoft Я имел в виду, если его самостоятельно запустить. Без остальной части запроса. Тут как раз разницы нет - вернее, есть, но она не регистрируется, слишком мала. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 07:55 |
|
|
start [/forum/topic.php?fid=47&msg=40122043&tid=1827838]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
154ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 244ms |
total: | 498ms |
0 / 0 |