У меня несколько проблем с очень медленным оператором UPDATE, использующим две таблицы с большим количеством строк.
Я незнаком с использованием первичных ключей и индексов, что, без сомнения, является частью проблемы, но я также обеспокоен тем, что это может быть связано с тем, что я использую 32-битныйверсия сервера MS SQL.
Данные импортируются из двух старых файлов Visual Fox Pro * .DBF.Поскольку данные содержат опечатки и другие ошибки, я сначала импортировал их в две временные таблицы как типы данных varchar (255).Затем я очистил / отредактировал эти временные таблицы, чтобы убедиться, что интересующие меня столбцы имеют правильный тип данных.Затем я импортировал их в две таблицы с именами WORK и MAST.Это все работало нормально, хотя и медленно.
Обе таблицы содержат в основном типы данных varchar (50), а также типы данных int, tinyint, decimal и date.
WORK содержит около 600 000 строк с 21 полем.
MASTсодержит около 6 500 000 строк с 26 полями.
Основное замедление возникло, когда я попытался скопировать три строки из MAST в три строки в WORK, используя следующий запрос.Это заняло 4 часа.
USE DATABASE
UPDATE WORK
SET w_timeOS = t2.m_timeOS,
w_distance = t2.m_distance,
w_state = t2.m_state
FROM MAST as t2
WHERE
WORK.w_date = t2.m_date
and WORK.w_siteNum = t2.m_SiteNum
and WORK.w_location = t2.m_location
В операторе set поля timeOS и distance являются целыми числами, а состояния - varchar (5).
В предложении where датазначения имеют формат даты, siteNum - целое число, а местоположения - varchar (1), который, я думаю, мне следует преобразовать в целое число ...
Где, по какому поводу вы бы порекомендовали поставить индекс?
Дата, siteNum и location, вместе взятые, являются уникальными для MAST, и они также все в WORK, однако может быть несколько подходящих строк для каждой комбинации этих полей в таблице WORK.
Однако, если я добавлю еще одно поле, w_employee, то они также будут уникальными в таблице WORK.
Должен ли я добавить индекс, используя w_date, w_siteNum и w_location для таблицы WORK?
Должен ли я также добавить индекс к m_date, m_siteNum и m_location в таблице MAST, который, как упоминалось выше, не был бы уникальным, если бы я не добавил m_employee?
Или есть какой-то лучшеКстати, (возможно, используя их в качестве внешних ключей?), учитывая, что обе таблицы по существу совместно используют одну и ту же информацию всех трех полей, даже если они уникальны только в MAST, что требует добавления поля m_employee в таблицу WORK, чтобы сделать его уникальным?
Было бы лучше, чем объединение трех предложений where?
Вам кажется, что это занимает слишком много времени, даже учитывая текущее отсутствие индексов?
Я использую MSSQL Server 12.0.2000, 32-разрядный, с использованием MSMS 17.6, в 64-разрядной системе Windows 7 с двухъядерным процессором AMD FX-4100 с тактовой частотой 3,6 ГГц, оперативной памятью DDR3 8 ГБ и практически пустой 1 ТБЖесткий диск SATA 7200 об / мин, 6 ГБ / с, на котором установлены ОС, SQL и MSMS.
Наблюдая за системными ресурсами, ядро ЦП не получает 50%, ОЗУ, используемое системой, составляет менее 4 ГБ, сам сервер SQL использует около 1,5 ГБ.
Доступ к жесткому диску кажется очень медленным - около 2 МБ / с.Я проверил жесткий диск и не обнаружил плохих или ожидающих ошибок секторов.
Исходя из этого, я подозреваю, что это не проблема с системными спецификациями, или с тем фактом, что он работает под 32-битной версией SQL, поскольку из того, что я читал, он поддерживает до 2,5 ГБ ОЗУ на32-битная версия.
Любые предложения, указатели и т. д., будет принята с благодарностью.Я потратил час или около того, пытаясь составить это, в надежде, что оно будет кратким, так что извините, если это не так.Я прошу прощения, если это слишком многословно, но я попытался добавить как можно больше информации, которую я считаю уместной.
Спасибо за любую помощь, которую вы можете предоставить.