У меня есть таблица product, в которой столько столбцов. Основной ключ: productid. Там 50 000 строк, но когда я выдаю инструкцию select, например select * from products, то для получения полных данных требуется 10 минут. Поэтому посоветуйте мне, что делать в результате, я могу быстрее выполнять свой запрос.Как ускорить простой запрос SQL Server 2000
Является ли ваш основной ключ также ключом кластеризации на этом столе?
Если вы делаете SELECT * ...., вы будете в основном всегда получите полное сканирование таблицы. Нет ничего, что могло бы ускорить этот запрос - вы хотите, чтобы все строки, все столбцы - так что вы все это получили, и это занимает время, которое требуется.
Если делать больше «сосредоточены» запросы как
SELECT col1, col2 FROM dbo.Products WHERE SomeColumn = 42
затем у вас есть шанс ускорить эту работу, используя соответствующие индексы.
Извините, 50.000 строк в таблице и 10 минут - даже с нулевым индексом он не должен занимать 10 минут. Получите реальность - это не плохой индекс, по крайней мере, один. – TomTom
@TomTom Вы не знаете, какие типы столбцов - если есть капли и т. Д., Это может занять много времени. – Bridge
Какой мой ответ на самом деле говорит - но это маловероятно, особенно если вы выбираете * из полей, которые не передают данные о блобе, извините. Данные Blob должны быть прочитаны явно. – TomTom
Купить лучший компьютер.
Серьезно.
SQL Server 2000 был удален много лет назад, поэтому это OLD-установка. 50.000 продуктов - шутка - любая таблица ниже 1 миллиона - ничто.
Но когда я выдаю запрос выбора, например, выбираю * из продуктов, он принимает 10 минут , чтобы получить полные данные.
Предполагая, что это по локальной сети, не более медленное подключение к Интернету, может быть 2 причины:
A выбрать * из таблицы не требуется более пары секунд для передачи всех данных по локальной сети. Точка. Если в тюке нет тонн двоичных данных (т. Е. Количества HUGH данных в некоторых полях).
Как ваш специалист по локальной базе данных, чтобы провести анализ. Начните с загрузки оборудования, затем перейдите в режим блокировки. Подумайте о переходе на более современную технологию. К настоящему времени у вас много поколений.
«50.000 продуктов - шутка - любая таблица ниже 1 миллиона - ничто». Я бы сказал, это зависит от количества (и размера) столбцов. – vstrien
Я говорю «нет». Шутки в сторону. Это похоже на то, что «хорошо, маленькая коробка не весит много», а йо уэй «зависит от того, что вы положили», когда «много» начинает составлять 100 тонн. Если у вас нет бинарных/текстовых полей с сотнями мегабайт каждый, это НЕ зависит от количества столбцов. Они могут различать от 0,05 до 0,5 секунды, но не от 0,05 секунды до 10 минут. – TomTom
Если сканирование таблицы (или кластеризованного индекса) является единственной вещью (которая должна быть в случае выбора из таблицы без примененного фильтра), время выполнения во многом зависит от скорости передачи данных. Один из вариантов - увеличить эту скорость (скорость сети, скорость диска и т. Д.), Другой вариант - уменьшить объем данных, которые необходимо передать (т. Е. Уменьшить количество столбцов). Я согласен с вами в том, что анализ специалиста базы данных - это правильная вещь. – vstrien
Поскольку критерий (ГДЕ) отсутствует, время, которое занимает ваш запрос, связано не с выбором (определяющим, какие строки выбрать), но, скорее всего, из-за большого объема данных.
Единственное решение:
Не используйте
SELECT *, но выбрать только те столбцы, которые вам необходимы.
Плотный размер? Извините, количество вещей, которые вы пытаетесь транспортировать в своем автомобиле, слишком велико.Невозможно упаковать - небольшая коробка? 50 000 строк - это то, что я сканирую таблицу через 0.x секунд на современном компьютере. Это не вопрос SIZE как таковой. – TomTom
Учитывая определенную среду (компьютер, установка SQL Server 2000, нефильтрованный запрос), уменьшение размера данных является единственным способом сократить время работы. Настройка среды также является опцией, но IMHO не является прямым решением, которое входит в диапазон разработчика SQL. – vstrien
Вы вообще использовали SQL Server от soneone else? Вполне возможно, что сервер перегружен, потому что что-то еще использует все IOPS - там, видно, что какой-то идиот не знал, что такое индекс. Причина медленности может быть совершенно не связана с размером данных в этом запросе. Это может быть даже плохой жесткий диск (это тоже видно). Если это «машина для разработчиков, только один пользователь, современный компьютер», да, но с учетом информации - может быть дюжина вещей, включая сломанный терминатор SCSI (и да, SQL 2000 - это время, когда люди использовали SCSI еще). – TomTom
Выберите меньшее количество столбцов. – vstrien
сколько полей есть и какой тип? '*' часто слишком много возвращенных столбцов. и ... если один из них оказался «IMAGE», «BLOB» - тогда это могут быть ваши горячие точки. –
Вам действительно нужны все строки и все столбцы в одном выражении select? Решите, что вы на самом деле хотите выбрать, и что вы хотите фильтровать, и создайте соответствующие индексы для тех столбцов, которые вы указали в своем окончательном заявлении. – Bridge