2013-05-14 2 views
0

У нас есть приложение, которое выполняет задание для обработки ряда строк из представления mssql. Этот вид содержит много строк, а данные вставляются с дополнительным столбцом (dataid), установленным для идентификации, предназначенным для использования нами, чтобы узнать, как далеко через набор данных, который мы получили.Помните, насколько далеко вы получили, когда хрустили большую таблицу MSSQL?

Некоторое время назад у нас были некоторые проблемы, когда вы получали только первые n строк с размером данных, большим y (y - последний самый последний последний обработчик данных, который мы обработали). Казалось, что строки не были возвращены в правильном порядке, а это значит, что когда мы захватили ряд строк, казалось, что dataid некоторых из строк был неуместен, а это означало, что мы обработали строку с dataid 100, когда мы на самом деле была только получали до 95.

например

окно/диапазон 100 строк на каждом хруст. но если dataid данных строк не находится в последовательном порядке, запрос, получающий следующие 100 строк, может содержать данные, которые действительно должны были быть расположены в следующем хрусте. И тогда строки будут пропущены при выполнении следующего хруста.

Заказ на данные поможет решить проблему, но это способ замедлить работу. Есть ли у вас какие-либо предложения, как это можно было бы сделать лучше/работать?

Когда я говорю много строк, я имею в виду несколько миллиардов строк, и да, если вы думаете, что это абсолютно безумно, вы совершенно правы!

Мы используем Dapper для сопоставления строк с объектами. Это полностью прочитанное.

Надеюсь, этот вопрос не слишком расплывчатый. Спасибо заранее!

+0

У вас есть указатель на 'dataid'? Является ли это индексированным представлением? – Jodrell

+0

Мы делаем, и производительность была довольно хорошей, с около 700 млн. Рядов, но производительность за последние несколько дней действительно сильно ухудшила базу данных. Я не знаю, был ли обновлен/перестроен индекс, но я узнаю, так ли это. База данных удалена, поэтому у меня нет доступа, и я не знаю, какие операции были запущены на ней, если новые данные были добавлены и т. Д. – Moulde

+0

вам нужно посмотреть фактический план выполнения, как это было предложено моим ответ ниже http://stackoverflow.com/a/16539083/659190 – Jodrell

ответ

2

Заказ на данные поможет решить проблему, но это способ замедлить работу.

Примените соответствующие индексы.

Единственный ответ на вопрос «почему мой запрос медленный»: How To: Optimize SQL Queries.

+0

** Предложение ** по-прежнему действует, но он использует MS SQL Server, а не MySQL ... –

+0

помечен как сервер MS SQL, поэтому план запроса будет более подходящий. Та же концепция. – Jodrell

+0

У нас уже есть указатель на столбец dataid, который используется при заказе, когда мы добавили индекс, он выглядел довольно быстро, но не более того, может ли восстановление индекса исправить это? и как быстро должен быть указатель в правильном столбце? Я имею в виду, сколько строк может обрабатывать сервер sql sql при добавлении правильных индексов? – Moulde

0

Если вы хотите работать только с последними 100, дайте взять 1000000, вы можете посмотреть разбиение данных.

Что нужно включить в индекс 999999000000?

1

Неясно, что вы подразумеваете, смешивая 'view' и 'insert' в том же предложении. Если вы действительно имеете в виду представление, что проектовIDENTITYfunction, то вы можете остановиться прямо сейчас, это не сработает. Для возобновления работы необходимо иметь сохраненную закладку. ИДЕНТИФИКАЦИЯ, спроектированная в SELECT по представлению, не соответствует критериям сохранения.

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

Смежные вопросы