Зачем использовать предложение INCLUDE при создании индекса?
Я использовал код @alexbw для построения параболы. Он работает очень хорошо. Я могу изменить набор цветов для функции. Для вычисления мне потребовалось около 1 мин и 30 секунд. Я использовал Intel i5, графику 2gb, 8GB RAM.
Код следующий:
import numpy as np
import matplotlib.pyplot as plt
from matplotlib import cm
import matplotlib.collections as mcoll
import matplotlib.path as mpath
x = np.arange(-8, 4, 0.01)
y = 1 + 0.5 * x**2
MAP = 'jet'
NPOINTS = len(x)
fig = plt.figure()
ax1 = fig.add_subplot(111)
cm = plt.get_cmap(MAP)
for i in range(10):
ax1.set_color_cycle([cm(1.0*i/(NPOINTS-1)) for i in range(NPOINTS-1)])
for i in range(NPOINTS-1):
plt.plot(x[i:i+2],y[i:i+2])
plt.title('Inner minimization', fontsize=25)
plt.xlabel(r'Friction torque $[Nm]$', fontsize=25)
plt.ylabel(r'Accelerations energy $[\frac{Nm}{s^2}]$', fontsize=25)
plt.show() # Show the figure
И результат: https://i.stack.imgur.com/gL9DG.png
4 ответа
Если столбец находится не в WHERE / JOIN / GROUP BY / ORDER BY , а только в списке столбцов в предложении SELECT .
Предложение INCLUDE добавляет данные на самом нижнем / листовом уровне, а не в дереве индекса.
Это уменьшает индекс, потому что он не является частью дерева
INCLUDE столбцы не являются ключевыми столбцами в индексе, поэтому они не упорядочены.
Это означает, что он бесполезен для предикатов, сортировки и т. Д., Как я упоминал выше. Однако это может быть полезным, если у вас есть остаточный поиск в нескольких строках из ключевого столбца (столбцов)
Основные столбцы индекса отсортированы, но включенные столбцы не отсортировано. Это экономит ресурсы при обслуживании индекса, но при этом позволяет предоставлять данные во включенных столбцах для покрытия запроса. Итак, если вы хотите охватить запросы, вы можете указать критерии поиска, чтобы найти строки в отсортированных столбцах индекса, но затем «включить» дополнительные несортированные столбцы с данными, не связанными с поиском. Это определенно помогает уменьшить объем сортировки и фрагментации при обслуживании индекса.
Вы могли бы использовать INCLUDE, чтобы добавить один или несколько столбцов на конечный уровень некластеризованного индекса, если, сделав это, вы сможете «покрыть» свои запросы.
Представьте себя необходимо запросить идентификатор сотрудника, идентификатор отдела и фамилию.
SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5
Если у вас есть некластеризованный индекс для (EmployeeID, DepartmentID), после того, как вы найдете сотрудников для данного отдела, вам нужно будет выполнить «поиск по закладкам», чтобы получить фактическую полную запись о сотруднике, просто чтобы получить столбец фамилии. Это может обойтись довольно дорого с точки зрения производительности, если вы найдете много сотрудников.
Если вы включили эту фамилию в свой индекс:
CREATE NONCLUSTERED INDEX NC_EmpDep
ON Employee(EmployeeID, DepartmentID)
INCLUDE (Lastname)
, тогда вся необходимая информация будет доступна на конечном уровне не- кластерный индекс. Просто выполнив поиск в некластеризованном индексе и найдя своих сотрудников для данного отдела,
Причины, по которым (включая данные на конечном уровне индекса) были хорошо объяснены. Причина, по которой вы дважды встряхиваете по этому поводу, заключается в том, что при выполнении запроса, если у вас нет дополнительных столбцов (новая функция в SQL 2005), SQL Server должен перейти к кластеризованному индексу, чтобы получить дополнительные столбцы что занимает больше времени и увеличивает нагрузку на службу SQL Server, диски и память (в частности, буферный кеш) по мере загрузки новых страниц данных в память, потенциально выталкивая другие, более часто необходимые данные из буферного кеша.