Ответ
После оптимизации необходимо оценивать комплекс метрик, а не одну. Ключевые из них:
- Время выполнения (Execution Time / Duration) — прямой показатель улучшения. Сравните
ДОиПОСЛЕ. - Потребляемые ресурсы:
- Логические чтения (Logical Reads) — количество страниц, прочитанных из кэша данных. Сильное снижение указывает на более эффективное использование индексов и меньшее обращение к данным.
- Физические чтения (Physical Reads) — чтения с диска. Их уменьшение снижает нагрузку на I/O.
- План выполнения (Execution Plan):
- Убедитесь, что исчезли дорогостоящие операции: Table Scans, Key Lookups, Sorts в памяти.
- Появились эффективные операции: Index Seek, Merge Join.
- Снизилась оценочная стоимость (Estimated Subtree Cost).
Практический пример анализа (псевдокод):
-- До оптимизации
-- Время: 1500 мс, Logical Reads: 10,000
SELECT * FROM Orders WHERE Status = 'Pending' ORDER BY CreatedDate;
-- После добавления индекса (Status, CreatedDate)
-- Время: 25 мс, Logical Reads: 150
SELECT * FROM Orders WHERE Status = 'Pending' ORDER BY CreatedDate;Вывод: Успешная оптимизация подтверждается существенным снижением времени выполнения и количества логических чтений, а также более оптимальным планом запроса.
Ответ 18+ 🔞
А, ну ты, блядь, про метрики после оптимизации! Давай, сука, разжую, как надо оценивать, а то некоторые думают, что если запрос быстрее на глазок побежал — то уже пиздец какой успех.
Слушай сюда, главная ошибка — смотреть на одну цифру и охуевать. Это как оценивать машину только по цвету, блядь. Надо комплекс метрик, пачка, овердохуища показателей.
Вот на что смотреть, чтобы не облажаться:
-
Время выполнения (Execution Time) — это, блядь, самое очевидное. Засекаешь, сколько тормозило ДО, и сколько щас. Если разница — хуй с горы, то зачем вообще парился? Но и тут засада: однажды выполнилось быстро, а в проде — пиздец. Поэтому смотрим дальше.
-
Жрун ресурсов (Потребляемые ресурсы):
- Логические чтения (Logical Reads) — вот это, сука, важный показатель! Сколько страниц из кэша оперативки он прочёл. Если это число упало в разы — ты молодец, блядь. Запрос теперь меньше жрёт общей памяти сервака, другим запросам больше остаётся. Красота.
- Физические чтения (Physical Reads) — а это уже чтение с диска, с этих ваших SSD/HDD. Если их стало меньше — ты снизил нагрузку на самое узкое, блядь, горлышко. Диск теперь не скрипит, как одержимый. Все довольны.
-
План выполнения (Execution Plan) — вот тут, ёпта, настоящая магия. Ты должен в него въехать.
- Исчезло ли что-то ужасное? Сканы всей таблицы (Table Scan), эти ёбаные Key Lookups (когда по индексу нашёл, а потом ещё в кучу лезет за остальными полями), сортировки в памяти (Sort) — всё это пожиратели времени. Их не должно быть.
- Появилось ли что-то хорошее? Чистые поиски по индексу (Index Seek), мердж-джойны (Merge Join) для сортированных данных. Красота, блядь.
- Оценочная стоимость (Estimated Subtree Cost) — в целом должна упасть. Это как итоговая смета от SQL Server: "Раньше операция стоила 100 условных единиц, а теперь 1.5". Хули ещё надо?
Вот тебе живой пример, чтобы не быть пиздаболом:
-- Было до оптимизации (старый код, говно)
-- Время: полторы секунды (1500 мс), Логических чтений: 10,000 (дохуя!)
SELECT * FROM Orders WHERE Status = 'Pending' ORDER BY CreatedDate;
-- Стало после (добавил индекс (Status, CreatedDate), красава)
-- Время: 25 миллисекунд, Логических чтений: всего 150
SELECT * FROM Orders WHERE Status = 'Pending' ORDER BY CreatedDate;Итоговый вывод, блядь: Если у тебя время упало в разы, логических чтений стало на порядок меньше, а в плане вместо скана красуется красивый Index Seek — значит, ты не просто так хуйней страдал. Оптимизация удалась, можно идти пить чай. Если что-то одно улучшилось, а другое нет — подозрение ебать чувствую, копай глубже.