UniData UniQuery - два СО

Question

Хорошо, я почти ничего не знаю по языку SQL, и мне интересно, каковы возможные причины медлительности двух WITH и одного WITH в unidata.

База данных содержит около 1 миллиона строк.

Т.е. /

SELECT somewhere WITH Column1 = "str" AND WITH Column2 = "Int" 5 <минут </p>

По сравнению с

SELECT somewhere WITH Column1 = "str" ~ 1 секунда

где-то индексируется (насколько мне известно)

так что, я не так делаю?

Если требуется дополнительная информация, просто спросите, не знаете, что предоставить.

Также в чем разница между СО и ГДЕ?

Answer 1

Это не SQL, а UniQuery.

Чтобы уточнить это для вас, вы не можете индексировать файл (somewhere, в данном случае), только столбцы файла. Вы можете обнаружить, что Column1 проиндексирован, а Column2 нет. Введите LIST.INDEX somewhere, чтобы узнать, какие столбцы были проиндексированы.

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

Существует множество возможных причин, объясняющих разницу в ответах, кроме индексации. В UniData столбцы определяются как «элементы словаря». Существуют различных типов элементов словаря. Самым базовым является элемент словаря D-типа, который является прямой ссылкой на поле в записи. Другой тип - это I или V-тип, который является производным полем. Производное поле может быть таким же простым, как возврат константы, или настолько сложным, как выполнение эквивалентного выполнения JOIN с другим файлом и / или какой-либо формой сложного вычисления. Это должно быть просто, чтобы увидеть, что разные столбцы могут обрабатывать очень разные объемы.

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

Для получения дополнительной информации ознакомьтесь с руководствами базы данных по адресу Rocket Software .

Answer 2

Один столбец SELECT в индексированном поле даже не потребует чтения каких-либо записей файла данных.Если вы загляните внутрь, вы увидите, что индексный файл является обычным хеш-файлом, а один столбец SELECT будет просто означать, что запись индексного файла с ключом «str» читается.Это может вернуть тысячи и тысячи ключей менее чем за секунду.

После добавления второго столбца вы, вероятно, заставляете систему читать все эти тысячи и тысячи записей, ДАЖЕ ЕСЛИ ВТОРАЯ КОЛОННА ЕСТЬINDEXED.Это измеримое время займет больше времени.

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

В качестве примера предположим, что в файле содержится 600 000 записей с Column1 = "str" ​​и 2000 записей с Column2 = "int":

>SELECT somewhere WITH Column2 = "int"
>>SELECT somewhere with Column1 = "str"

Будет читать 2000 записей и должен возвращаться почти мгновенно.

Если комбинация Column1 и Column2 - это то, что вы часто выбираете, то вам может потребоваться создать новый элемент словаря.который объединяет их и строит для них индекс.

При этом система U2 не должна занимать 5 минут, чтобы просмотреть файл с миллионами записей.Очень высока вероятность того, что файл сильно переполнен, и для повышения производительности его размер нужно изменить с помощью большего модуля.