UniData UniQuery - два СО
Хорошо, я почти ничего не знаю по языку SQL, и мне интересно, каковы возможные причины медлительности двух WITH против одного WITH в unidata.
База данных насчитывает около 1 миллиона строк.
Т.е. /
SELECT somewhere WITH Column1 = "str" AND WITH Column2 = "Int" 5<минут
По сравнению с
SELECT somewhere WITH Column1 = "str" ~1 секунда
где-то индексируется (насколько мне известно)
так что я делаю не так?
Если требуется дополнительная информация, просто спросите, не уверены, что предоставить.
И в чем разница между СО и ГДЕ?
2 ответа
Это не SQL, это UniQuery.
Чтобы уточнить это для вас, вы не можете проиндексировать файл (somewhereв данном случае) только столбцы файла. Вы можете найти Column1 индексируется и Column2 не является. Введите LIST.INDEX somewhere чтобы узнать, какие столбцы были проиндексированы.
По вашему вопросу вы только сравнили выбор в столбце 1 с выбором в столбце 1 и столбце 2 и предположили, что гораздо более медленный ответ вызван исключительно тем, что вы выбрали 2 столбца. Ваш следующий текст должен был выбрать только в столбце 2 и посмотреть, как медленно это было.
Существует много возможных причин, объясняющих разницу в ответах, кроме индексации. В UniData столбцы определяются как "элементы словаря". Существуют различные типы элементов словаря. Самым базовым является элемент словаря D-типа, который является прямой ссылкой на поле в записи. Другой тип - это I или V-тип, который является производным полем. Производное поле может быть таким же простым, как возвращение константы, или настолько сложным, как выполнение эквивалентного выполнения JOIN с другим файлом и / или какой-либо формой сложного вычисления. Это должно быть просто, чтобы увидеть, что разные столбцы могут обрабатывать очень разные объемы обработки.
Другие причины заключаются в том, насколько глубоко в записи находится столбец (ссылки на первые поля будут быстрее, чем поля в записи), а также потенциальное кеширование запросов, которое может повлиять на время ваших SELECT.
Для получения дополнительной информации, ознакомьтесь с руководствами базы данных в Rocket Software.
Один столбец SELECT в индексированном поле даже не потребует чтения каких-либо записей файла данных. Если вы загляните внутрь, вы увидите, что индексный файл является обычным хеш-файлом, а один столбец SELECT будет просто означать, что запись индексного файла с ключом "str" читается. Это может вернуть тысячи и тысячи ключей менее чем за секунду.
Добавив второй столбец, вы, вероятно, заставляете систему читать все эти тысячи и тысячи записей, ДАЖЕ ЕСЛИ ВТОРАЯ КОЛОННА УКАЗАНА. Это займет больше времени.
В целом, индекс поля с небольшим количеством уникальных значений имеет сомнительное значение. Если второй столбец содержит данные, которые имеют большое количество возможных значений, что приводит к меньшему количеству записей с каждым конкретным значением индекса, то было бы лучше расположить SELECT таким образом, чтобы используемый индекс находился во втором столбце. Я не уверен, но для этого можно просто изменить порядок столбцов в операторе SELECT. В противном случае вам может потребоваться запустить два оператора SELECT вплотную.
В качестве примера предположим, что в файле 600000 записей с Column1 = "str" и 2000 записей с Column2 = "int":
>SELECT somewhere WITH Column2 = "int"
>>SELECT somewhere with Column1 = "str"
Прочитает 2000 записей и должен вернуться почти мгновенно.
Если комбинация Column1 и Column2 - это то, что вы будете часто выбирать, то вам может потребоваться создать новый элемент словаря, который объединяет эти два элемента, и построить индекс для этого.
При этом система U2 не должна занимать 5 минут, чтобы просмотреть файл с миллионами записей. Существует очень хороший шанс того, что файл сильно переполнен, и его необходимо изменить по модулю, чтобы повысить производительность.