УДАЛИТЕ Команду, является слишком медленным в Таблице с Кластерным индексом
Используйте класс UIScreen для определения фрейма приложения.
CGRect usableSpace = [[UIScreen mainScreen] applicationFrame];
Возвращенный прямоугольник - это размер экрана минус строка состояния. Не используйте идиомы пользовательского интерфейса для определения доступного пространства, поскольку они не рассчитаны на будущее.
Кстати, UIViewController может автоматически изменять размеры представлений содержимого (включая представления с прокруткой), а также предоставлять вам другие полезности, такие как автоповорот. Подумайте об этом, если это уместно в вашей ситуации.
4 ответа
Так как это таблица журналов, делать ее кластеризованной не нужно.
Маловероятно, что вы будете искать ее по Id .
Измените свой PRIMARY KEY , чтобы он не кластеризовался. Это будет использовать метод хранения HEAP , который быстрее на DML :
ALTER TABLE FTPLog DROP CONSTRAINT Primary_Key_Name
ALTER TABLE FTPLog ADD CONSTRAINT Primary_Key_Name PRIMARY KEY NONCLUSTERED (FTPLogId)
, и просто выдаст:
SELECT @MaxFTPLogTime = DATEADD(day, -10 , GETDATE())
PRINT @MaxFTPLogId
DELETE FROM FTPLog WHERE LogTime <= @MaxFTPLogTime
Это может быть медленным, потому что при большом удалении создается большой журнал транзакций. Попробуйте удалить его по частям, например:
WHILE 1 = 1
BEGIN
DELETE TOP (256) FROM FTPLog WHERE FTPLogId <= @MaxFTPLogId
IF @@ROWCOUNT = 0
BREAK
END
Это генерирует меньшие транзакции. И это смягчает проблемы с блокировкой, создавая передышку для других процессов.
Вы также можете изучить секционированные таблицы . Это потенциально позволяет удалить старые записи, удалив весь раздел.
Проверьте плотность вашей таблицы (используйте команду DBCC showcontig для проверки плотности) Плотность сканирования [Best Count: Actual Count] этот параметр должен быть ближе к 100%, а параметр Logical Scan Fragmentation должен быть ближе к 0% для лучшей производительности вашей таблицы. Если это не так, переиндексируйте и повторно фрагментируйте индекс этой таблицы, чтобы повысить производительность выполнения вашего запроса.
Я предполагаю, что эта таблица не только огромна с точки зрения количества строк, но и что она действительно активно используется для регистрации новых записей, когда вы пытаетесь ее очистить.
Предложение Andomar должен помочь, но я бы попытался очистить его, когда вставки не выполняются.
Альтернатива: Когда вы пишете журналы, вы, вероятно, не так сильно заботитесь об изоляции транзакции. Поэтому я бы изменил уровень изоляции транзакции для кода / процессов, которые записывают записи журнала, чтобы вы могли избежать создания огромных tempdb (кстати, проверьте, сильно ли растет tempdb во время этого Операция DELETE)
Кроме того, я думаю, что удаление из кластерного индекса не должно происходить медленнее, чем из некластеризованного: вы все еще физически удаляете строки.