Влияние нового дизайна сайта компании на индексацию и рейтинг сайта в поисковых системах

После смены шаблона возможно временное снижение трафика. Робот поисковой системы выполняет сканирование и индексацию веб-страниц заново. Зачастую, полное индексирование сайта среднего размера занимает несколько недель. Чем больше сайт, тем продолжительнее этот период. Как правило, все показатели посещаемости полностью восстанавливаются после переиндексации.

Смена цветовой схемы не влияет на рейтинг в поисковой системе.

Когда следует подключать новый дизайн?

Выполняйте подключение, когда посетителей немного.  Если трафик вашего сайта зависит от сезона, то подключение нового дизайна  стоит проводить во время «затишья». Это снизит влияние возможных проблем.
Помните о том, что при подключение дизайна сайта может меняться его позиция в результатах поисковой выдачи.

Почему во время Free Trial дизайна не выросли продажи?

Free Trial  служит для того, чтобы определиться с выбором дизайна. Например: спросить у друзей или постоянных покупателей,  какой дизайн удобен для выбора товаров на вашем сайте.

Free Trial  не влияет на рост продаж. На количество продаж можно будет ориентироваться только после полной переиндексации сайта.

Чем быстрее вы сможете определиться с дизайном, тем раньше поисковый робот сможет начать “работу с вами”. Также вы сможете вернуться на свой старый дизайн, не дожидаясь окончания Free Trial, просто подключите свой шаблон в кабинете.

Как ускорить переиндексацию сайта с помощью Google Webmaster?

Для этого вам нужно использовать «Инструменты веб-мастера». Зарегистрируйтесь в Google Webmaster, где вы найдете  огромное количество полезных функций и сможете ускорить индексацию ключевых страниц сайта, после того как определитесь с дизайном для своего сайта.

Далее выполните такие действия:

1. Зайдите в инструменты для вебмастеров http://www.google.com/webmasters/

2. Выберите ваш сайт, страницу которого вы хотите отправить на индексацию.

3. Открыть меню «Сканирование — Посмотреть как Googlebot». 
   

4. Ввести в поле (1) адрес страницы, которую хотите добавить в индекс (или оставить поле пустым, если это главная страница сайта) и нажать кнопку «Получить и отобразить» (2).
   

5. Подождать несколько секунд, пока страница перезагрузится и напротив добавленного url появится кнопка «Запросить индексирование».
   

6. Нажать кнопку «Запросить индексирование».

7. Во всплывающем окне выбрать «Сканировать этот URL и прямые ссылки» и нажать кнопку «Отправить».
   

Таким образом, будет сформирован ручной запрос (пинг) на сканирование сайта роботом Google. Обратите внимание, что количество запросов ограничено:

• если было выбрано «Сканировать только этот URL», то доступно 500 запросов;
• если было выбрано «Сканировать этот URL и прямые ссылки», то в вашем распоряжении есть только 10 запросов.

Если вы хотите добавить на индексацию новый сайт целиком, то стоит просто пропинговать 10 (или меньше) основных страниц, на которых расположены ссылки на внутренние страницы сайта. Это может быть пару страниц групп, Главная, О нас, Статьи, Новости и т.д.   Направленный на эти страницы робот успешно “съест” все остальные страницы, доступные по ссылкам с тех, которые пропингованы, и все основные страницы попадут в индекс. Остальные внутренние страницы, которые найдет робот, не будут добавлены мгновенно, но будут поставлены в очередь на индексирование и скоро попадут в индекс.

Обратите внимание.  Если же вы добавили новую статью или новость, и хотите ускорить ее индексацию, то лучше оставить запрос только данного url без связанных страниц.

Важно: Google не гарантирует индексацию страницы после таких запросов.

Лучше и быстрее сканируется новый и свежий контент, а также контент, в котором были какие-либо изменения.

elsevierscience

Регулярная оценка и расширение контента в Scopus: информация для издательств

Scopus является крупнейшей единой базой мировой научной литературы, которая охватывает издания от более чем 5000 издательств. Индексируемые журналы, книги и материалы конференций доступны миллионам пользователей Scopus, которые в свою очередь знакомятся с вашим контентом и ссылаются на него в своих статьях, заявках на получение грантов, отчетах и заявках на патенты. Для удовлетворения информационных потребностей широкого круга исследователей, Экспертный совет по отбору контента (Content Selection & Advisory Board, CSAB) регулярно рассматривает поступающие предложения по включению в Scopus нового контента.

Scopus позволяет:

• повысить «видимость» ваших публикаций

• получить доступ к глобальному сообществу исследователей и экспертов (для программ рецензирования)

• отслеживать результативность ваших публикаций

• отслеживать конкурентные издания.

Процесс оценки изданий

Международные эксперты нашего Совета по отбору контента регулярно рассматривают новые издания, используя количественные и качественные показатели. Стоит отметить, что только периодические издания могут быть рекомендованы для включения в Scopus. Периодические издания включают  журналы, книжные серии или материалы периодических конференций. Рекомендации могут быть поданы издательствами или редакторами изданий. Индивидуальные исследователи и библиотекари также могут рекомендовать издания для включения в Scopus при условии поддержки такой рекомендации издательством и/или редактором. До подачи рекомендации о включении периодического издания в Scopus следует выполнить следующие шаги:

• Проверьте текущие списки изданий Scopus, чтобы убедиться в том, что они не содержат рекомендуемое издание: «Список журналов, индексируемых в Scopus» на данной странице

• Ознакомьтесь с обращением Экспертного совета: «Знакомство со Scopus и работа экспертного совета по отбору контента» (A General Introduction to Scopus and the Work of the Content Selection & Advisory Board)

• Ознакомьтесь с критериями отбора, указанными ниже 

• После этого воспользуйтесь «Формой подачи изданий в Scopus» (Scopus Title Suggestion Form). Ознакомьтесь с разъяснениями и рекомендациями по заполнению формы. 

• Ознакомьтесь с часто задаваемыми вопросами о роли редактора (Role of an Editor)

• Прочитайте часто задаваемые вопросы о «Процессе отбора контента» (Content selection process) (PDF, 1.08 MB)

Лицо, рекомендующее издание, и издательство, будут проинформированы о результатах оценки и причине(-ах) принятия того или иного решения. Этапы оценки могут отслеживаться с помощью уникального номера Tracking ID (предоставляется во время подачи рекомендации) в «Трекере оценки изданий» (Title Evaluation Tracker).

Критерии отбора журналов

Для того чтобы журнал был рассмотрен, он должен отвечать следующим минимальным критериям:

• Содержать рецензируемый контент; описание процесса рецензирования должно быть размещено в открытом доступе

• Регулярно публиковаться и иметь номер ISSN, зарегистрированный в Международном центре ISSN (ISSN International Centre)

• Контент должен быть актуальным и понятным для международной аудитории, то есть иметь ссылки в латинской транскрипции, аннотации и названия статей на английском языке

• Заявления об издательской этике и недобросовестной издательской практике должны быть размещены в открытом доступе

Члены Совета являются экспертами в отдельных областях знаний и работают над поиском и отбором литературы, отвечающей требованиям и стандартам научно-исследовательского сообщества, представителями которого они являются. Журналы, соответствующие минимальным критериям и допущенные к оценке Экспертным советом, будут оцениваться по следующим критериям в пяти категориях:

Переоценка изданий

Качество контента имеет первостепенное значение для Scopus. Поэтому журналы, в дополнение к строгому процессу оценки и отбора перед включением в Scopus, должны демонстрировать способность поддерживать высокое качество из года в год.

Чтобы определить качество журналов, Scopus проводит ежегодную программу переоценки, в результате которой определяются журналы, демонстрирующие неудовлетворительные показатели. Качество журналов определяется тремя различными способами:

1. По результатам оценки журналов по шести метрикам и критериям, которым должны соответствовать все журналы в базе данных Scopus, выявляются журналы с неудовлетворительными показателями и направляются на переоценку. Если журнал не соответствует ни одному из шести контрольных показателей в течение двух лет подряд, экспертный совет проводит переоценку журнала на основе критериев отбора изданий в Scopus (Scopus title selection criteria), в результате чего индексация новых выпусков журнала в Scopus может быть прекращена. 

2. Журналы с неудовлетворительными показателями выявляются с помощью инструмента для анализа данных под названием «Radar». Данный инструмент используется один раз в год и позволяет идентифицировать журналы, демонстрирующие поведение, не соответствующее другим журналам (например, резкий и экспоненциальный рост количества статей, необъяснимые и внезапные изменения страны происхождения, высокие уровни самоцитирования журналов и т.д.). Все журналы, идентифицированные с помощью инструмента Radar, подлежат переоценке Экспертным советом в том же году. Переоценка происходит на основе критериев отбора изданий в Scopus (Scopus title selection criteria) и может привести к прекращению индексации новых выпусков журнала в Scopus. 

3. Журналы, к которым имеются обоснованные претензии со стороны пользователей, покупателей или заинтересованных сторон, подлежат переоценке. Переоценка проводится в год получения претензии на основе критериев отбора изданий в Scopus (Scopus title selection criteria) и может привести к прекращению индексации новых выпусков журнала в Scopus. 

1. Метрики и критерии

Один раз в год Scopus проводит анализ всех журналов в базе данных. Метрики и контрольные показатели, которые должны контролировать журналы, чтобы не попасть на переоценку:

Если журнал демонстрирует неудовлетворительные показатели по любому из указанных шести критериев, то Scopus уведомит его об этом и предоставит возможность улучшить как минимум один показатель в течение года. Если в течение года журналу удалось улучшить как минимум один показатель, он не будет подлежать переоценке в текущем году. Однако, если журнал не будет соответствовать всем шести критериям на протяжении двух лет подряд, он будет подлежать переоценке независимым экспертным советом по отбору контента (Content Selection & Advisory Board, CSAB).

Критерии для проведения переоценки идентичны критериям отбора контента в Scopus (content selection criteria), используемым для отбора новых изданий. По завершению переоценки, экспертный совет принимает решение касательно продолжения или прекращения индексирования журнала в Scopus (контент, включенный в Scopus до даты переоценки, остается в Scopus).

Дополнительная информация о критериях, процессе и сроках переоценки изданий представлена на странице «Процесс и сроки переоценки в Scopus» (Scopus Re-evaluation Workflow and Timelines).

2. Инструмент «Radar»

В 2017 году был запущен инструмент «Radar» — алгоритм анализа данных компании Elsevier, способный определять нетипичное поведение журналов в базе данных Scopus. Примерами нетипичного поведения журналов являются следующие события: быстрые и необъяснимые изменения в количестве публикуемых статей, необъяснимые изменения в географии авторов или аффилированных организаций. Кроме того, алгоритм анализирует уровень самоцитирования и наличие претензий к журналу. Данный инструмент продолжает непрерывно совершенствоваться благодаря включению в него новых примеров и правил. Он запускается один раз в год проверяет всю базу журналов Scopus, насчитывающую более 23700 изданий, на предмет нетипичного поведения.

Журналы, идентифицированные инструментом Radar, подлежат переоценке Экспертным советом в текущем году. Критерии оценки идентичны критериям отбора контента в Scopus (content selection criteria), используемым для отбора новых изданий. По завершению переоценки, экспертный совет принимает решение касательно продолжения или прекращения индексирования журнала в Scopus (контент, включенный в Scopus до даты переоценки, остается в базе данных).

3. Претензии к журналам

Журнал также может быть направлен на переоценку в случае возникновения претензий к нему на уровне издательства или журнала. Проблемы, связанные с такими журналами, выявляются Scopus или исследовательским сообществом. Любые претензии подлежат тщательной проверке. Если они являются обоснованными, то издание будет добавлено в перечень изданий для переоценки Экспертным советом (переоценка состоится в год выявления проблемы или претензии). Критерии оценки идентичны критериям отбора контента в Scopus (content selection criteria), используемым для отбора новых изданий. По завершению переоценки, экспертный совет принимает решение касательно продолжения или прекращения индексирования журнала в Scopus (контент, включенный в Scopus до даты переоценки, остается в базе данных).

Издания, которые перестали индексироваться в Scopus по результатам проведения переоценки, перечислены в файле под названием «Издания, индексация которых прекращена» на данной странице.

Все вопросы, связанные с переоценкой изданий, направляйте на адрес эл. почты: [email protected]

Заявления об издательской этике и недобросовестной издательской практике

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

Каждый журнал, индексируемый в Scopus, должен иметь заявления об издательской этике и недобросовестной издательской практике, которые должны быть опубликованы в открытом доступе. Scopus возлагает ответственность по исполнению и соблюдению этих политик на каждого издателя, чьи издания индексируются в базе данных. Scopus не требует наличия каких-либо конкретных формулировок, касающихся заявлений об издательской этике и недобросовестной издательской практике, но отмечает, что:

• Крупные издательства публикуют детальные заявления о соблюдении норм издательской этики на своих веб-сайтах. Например, это делает компания Elsevier.

• Ряд отраслевых организаций публикуют исчерпывающие рекомендации и советы, которые могут быть использованы любым издательством. Например:

o Комитет по этике научных публикаций (COPE)

o Всемирная ассоциация медицинских редакторов (WAME)

o Международный комитет редакторов медицинских журналов (ICMJE)

o Единые стандарты представления результатов испытаний (CONSORT)

• Рекомендации в отношении принципов, которые должны лежать в основе заявлений об издательской этике и недобросовестной издательской практике (PEMS)

Дополнительная информация о значимости этики в научно-исследовательской и издательской деятельности доступна по адресу www.ethics.elsevier.com, кроме того, можете посмотреть следующий вебинар.

Типы книг и критерии их отбора

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

1. Предметные области: фокус на социальные и гуманитарные науки, а также естественные науки, технику и медицину

2. Типы книг: монографии, сборники научных трудов, крупнейшие справочные издания, учебники для магистратуры

3. НЕ индексируются: диссертации, учебники для студентов, атласы, ежегодники, биографии, научно-популярные книги, учебные пособия и т. д.

Отбор книг осуществляется по принципу издательства (индивидуальные книги не рассматриваются). Поскольку оценка производится по каждому издательству, Экспертный совет по отбору контента не принимает в ней участие. Выбором издательств занимается специальная группа высококвалифицированных экспертов. Все подходящие книги отобранных издательств включаются в Scopus.

Издательства могут рекомендовать свои книги для включения в Scopus с помощью формы для рекомендации книг в Scopus (Scopus Books Suggestion form). Оценка книг возможна при условии, что они соответствуют следующим минимальным критериям:

1. Все книги должны содержать номер ISBN.

2. Все книги должны быть доступны в цифровом формате (PDF или XML).

3. Все метаданные должны быть записаны в ONIX или MARC.

4. Все метаданные должны содержать коды предметной области BIC или BISAC.

5. Весь контент книги должен быть на английском языке.

6. Типы рассматриваемых книг: монографии, сборники научных трудов, крупные справочные издания и учебники для магистратуры.

Перечни книг от издательств, отвечающих минимальным критериям, будут рассмотрены в соответствии со следующими критериями отбора:

1. Репутация и импакт издательства

2. Размер и предметная область перечня книг (предпочтительная(-ые) предметная(-ые) область(-и): гуманитарные и / или социальные науки).

3. Доступность и формат контента

4. Издательская политика и миссия редакции

5. Качество публикуемого контента

Один раз в год (каждое лето) специальная группа экспертов оценивает все рекомендуемые книги на основании описанных выше критериев. По завершению оценки Scopus связывается с издательствами книг и сообщает о ее результатах.

По всем вопросам обращайтесь в отдел по рекомендациям книг для включения в Scopus (Scopus book suggestion).

Критерии отбора материалов конференций

Материалы конференций являются важным компонентом научной литературы во многих предметных областях, особенно в области инженерных и компьютерных наук, физики и математики. Scopus индексирует только полнотекстовые материалы конференций. В настоящее время в базу данных включено около 8 миллионов документов с почти 100 000 конференций. Отбор материалов конференций осуществляется с учетом актуальности конференции для предметной области и ее качества. Приоритет отдается материалам конференций, опубликованным авторитетными организациями и издательствами в соответствующих предметных областях. Scopus не рассматривает заявки на включение в базу данных отдельных материалов конференций. Периодические издания материалов конференций, которые имеют зарегистрированный номер ISSN, могут быть рекомендованы для включения в Scopus в соответствии с вышеуказанным процессом оценки изданий.

В России действует Консультативный совет по включению контента в базу данных Scopus. Это экспертный совет, в задачи которого входит: 

• повышение качества российских научных журналов
• консультирование издателей и редакторов региональных научных журналов по вопросам подготовки издания для включения в Scopus
• предварительное рассмотрение локальных журналов и рекомендации по улучшению изданий
• детальное рассмотрение российских журналов и рекомендации для принятия в Scopus.

Оценить готовность журнала для подачи в Scopus

О.В. Кириллова «Редакционная подготовка научных журналов по международным стандартам» в формате PDF

О. В. Кириллова «Индекс цитирования Scopus: критерии отбора журналов и перспективы включения российской экономической периодики» в формате PDF

О.В. Кириллова «Значение и основные требования к представлению aффилиации авторов в научных публикациях»

О.В. Кириллова «Как оформить статью и научный журнал в целом для корректного индексирования в международных наукометрических базах данных»

О.В. Кириллова «Как научному журналу сохранить родной язык и охватить англоязычную аудиторию»

О.В. Кириллова «О влиянии языка статей на показатели научных журналов в международных наукометрических базах данных»

О.В. Кириллова «Состояние и перспективы представления российских медицинских журналов и публикаций в базе данных Scopus» в формате PDF

FAQ о журналах в Scopus: Оптимизация процесса подачи заявок на включение в Scopus для Редакторов и Издателей

FAQ: Роль Редактора

Индексация элементов проекта—ArcGIS Pro | Документация

По умолчанию ArcGIS Pro создает и динамически обновляет индекс элементов в вашем проекте. Индекс используется для создания результатов поиска в проекте. Карты, компоновки и другие элементы, хранящиеся в файле проекта (.aprx), индексируются, когда вы их создаете, импортируете или добавляете в проект. Папки, базы данных, наборы инструментов и другие элементы, хранящиеся вне файла проекта, индексируются, когда вы добавляете подключения к ним.

Индексируются только те элементы, которые могут использоваться ArcGIS Pro. Например, если папка в проекте содержит шейп-файл и файл Microsoft PowerPoint, шейп-файл индексируется, а файл PowerPoint нет.

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

Индекс поиска, используемый в ArcGIS Pro, отличается от индекса поиска, используемого в ArcMap и ArcCatalog. Он хранится в другом месте, использует другое содержание и поддерживает другие элементы.

Индексируемые элементы

Индексируются следующие элементы и наборы элементов:

• Компоновки
• Карты
• Отчеты
• Пакетные задания Reviewer
• Задачи
• Облачные подключения BIM
• Облачные хранилища
• Базы данных
• Папки
• Notebooks
• Серверы
• Наборы инструментов

Для подключений баз данных и наборов инструментов индексируются и подключения, и их содержание. Для подключений папок индексируется только содержание папки. (Поиск по проекту не возвращает имена папок.) Для подключений к облаку и серверу индексируется только подключение, но не содержание хранилища сервера или облака.

Местоположение индекса

Индекс ArcGIS Pro состоит из двух индексов: индекса проекта и индекса ресурсов. Индекс проекта хранится в домашней папке проекта. Он отслеживает элементы, хранящиеся в файле проекта, такие как карты и компоновки. Индекс ресурсов хранится в директории вашего профиля пользователя в <user profile>\AppData\Local\ESRI\Index. Он отслеживает элементы, такие как базы данных, наборы инструментов и подключения, которые добавляются в проект.

Индекс ресурсов содержит записи для элементов, связанных с любыми и всеми вашими проектами. Каждый из проектов A, B и C имеют свой собственный индекс проекта, но используют один и тот же индекс ресурсов. Элементы в индексе ресурсов индексируются только один раз, вне зависимости от того, в скольких проектах они используются. Например, если оба проекта A и B содержат подключение к папке C:\Data\Wildfires, содержание этой папки индексируется только один раз.

При выполнении поиска в проекте, вернутся результаты и от индекса проекта, и от индекса ресурсов. Результаты из индекса ресурсов вернутся только для элементов, связанных с проектом, в котором выполняется поиск. Например, если в проект A добавлена база геоданных с именем oak_glen.gdb, ее можно найти при поиске в этом проекте. Ее невозможно найти при поиске в проекте B, пока она не будет добавлена в проект B (или расположена в папке, добавленной в проект B).

Динамическое индексирование

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

Однако если содержание элемента изменяется после того, как он был индексирован, индекс не отражает это изменение. Например, новые файлы, добавленные в уже проиндексированную папку, не индексируются динамически. (Содержание нового подключения к папке будет.) Аналогично, если вы удаляете или перемещаете файлы из индексированной папки, индекс не распознает, что их нет. Индекс не отражает изменений такого рода до тех пор, пока он не будет накопительно обновлен или удален и перестроен.

Индексирование существующих проектов

Иногда существующие проекты могут оказаться не индексированными. Это происходит, например, если вы получили проект от кого-то еще или использовали команду Сохранить как для создания проекта. Это также может случиться, если проект создан, когда индексирование было выключено. В таких случаях проект индексируется, как только происходит одно из следующих событий:

• Вы добавили в проект базу данных, набор инструментов или подключение.
• Индекс является накопительно обновляемым.
• Вы выполнили поиск в проекте (вместо поиска на портале) на панели Каталог, в виде Каталог или диалоговом окне обзора.

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

Проекты не индексируют содержание, хранящееся в Microsoft OneDrive. Если проект и все его содержание хранятся в OneDrive, поиск по проекту не даст результатов. Однако если проект, хранящийся в OneDrive, ссылается на содержание, которое не хранится в OneDrive, указанное содержание индексируется.

Внимание:

Облачные сервисы хранилища, такие как Microsoft OneDrive Google Drive не поддерживаются, если иное не указано в документации по конкретным инструментам и функциям. Более подробно о ArcGIS Pro и сервисах облачного хранилища.

Содержание, включенное в индекс

Если элемент индексирован, из него извлекается информация и хранится в индексе. Для разных элементов индексируется различное содержание. В индексе может содержаться следующая информация:

• Имя элемента.
• Теги, описания, краткая информация, кредиты и ограничения использования – содержание, извлеченное из метаданных ArcGIS, связанных с этим элементом (если существует). Если метаданные элемента отформатированы в соответствии со стандартом FGDC Content Standard for Digital Geospatial Metadata, то они не включается в поисковый индекс ArcGIS Pro; обновите их до формата метаданных ArcGIS, чтобы метаданные элемента были проиндексированы.
• Название, экстент, пространственная привязка, максимальный масштаб, образец – содержание, извлеченное из метаданных ArcGIS, связанных с этим элементом (если существует). Если его не существует, для определения подходящего значения используются данные элемента. Например, имя элемента используется в качестве заголовка. Если набор пространственных данных проиндексирован, создается образец, если его не было.
• Дата последнего изменения, формат растра и имена каналов, тип сенсора изображения, дата получения, азимут солнца и углы высот, информация о продукте и т.д. – свойства элемента, используемые для определения соответствующего значения.

Опции индексирования

Опции индексирования на странице Настроек ArcGIS Pro позволяют конфигурировать индекс для соответствия вашим требованиям. Некоторые из опций индексирования описываются далее. Другие описаны в разделе Обновить индекс поиска для элементов проекта.

Индексация содержимого сетевого диска

По умолчанию элементы, хранящиеся на сетевом диске, который добавлен в проект, не индексируются. Для индексации содержимого сетевого диска выполните следующие действия. При следующем накопительном обновлении индекса, индексируется содержание сетевых дисков, добавленных в проект как подключения к папке.

1. Откройте диалоговое окно Опции одним из следующих способов:
   • Если проект уже открыт, щелкните вкладку Проект и выберите Опции.
   • Запустите ArcGIS Pro и щелкните Настройки внизу начальной страницы.

   Откроется диалог Опции.

2. Щелкните вкладку Индексация.
3. Поставьте отметку Индексировать элементы на сетевых дисках.
4. Нажмите OK.

   Вы можете добавлять сетевые элементы в проект либо по пути UNC, либо по букве диска (при условии, что сетевой диск смонтирован на вашем компьютере). Периферийные устройства, напрямую подключенные к компьютеру, например флеш-память USB или внешний диск, определяются как локальные диски.

Индексация содержимого многопользовательской базы данных

По умолчанию файлы подключения к многопользовательской базе данных (.sde) индексируются, а содержание базы данных — нет. Это означает, что вы можете найти базу данных при поиске по проекту, но не можете найти содержащиеся в ней наборы данных. Это верно независимо от того, добавляется ли многопользовательская база данных напрямую в проект или это элемент в подключении к папке.

Для индексации содержания многопользовательской базы данных — которая может потребовать значительных ресурсов — вы должны сделать две вещи: добавить базу данных в проект с помощью команды Добавить базу данных и соответствующим образом настроить опции индексирования. При следующем накопительном обновлении индекса содержание индексируется. Процесс описывается в следующих шагах.

1. При необходимости добавьте базу данных в проект.
2. Откройте диалоговое окно Опции одним из следующих способов:
   • Если проект уже открыт, щелкните вкладку Проект и выберите Опции.
   • Запустите ArcGIS Pro и щелкните Настройки внизу начальной страницы.

   Откроется диалог Опции.

3. Щелкните вкладку Индексация.
4. Отключите опцию Пропустить подключение к многопользовательской базе данных.
5. Нажмите OK.

Отключение индексирования

Если вы знаете, где находятся данные, или у вас есть необходимость поиска в проектах, вы можете отключить индексирование. Если индексирование отключено, новые элементы при добавлении в проект не индексируются. Существующие индексы используются, но не обновляются. Запланированная задача, используемая для периодического обновления индекса, удаляется.

1. Откройте диалоговое окно Опции, используя один из следующих методов.
   • Если проект уже открыт, щелкните вкладку Проект и выберите Опции.
   • Запустите ArcGIS Pro и щелкните Настройки внизу начальной страницы.

   Откроется диалог Опции.

2. Щелкните вкладку Индексация.
3. Под Настроить, будет ли создаваться индекс, и как он будет использоваться щелкните Не создавать индекс.
4. Нажмите OK.

Удаление индекса

Если проекты или данные, с которыми вы работаете, значительно изменились, вы можете удалить индекс. Если вы удаляете индекс, а опция, которая использует индекс, включена – создается новый индекс. Если индексирование отключено, новые индексы не строятся.

Удаление индекса удаляет индекс ресурсов, но не проекта. Поиск все равно возвращает результаты для таких элементов, как карты, компоновки и отчеты. Для удаления индекса проекта в конкретном проекте, перейдите к папке проекта в Windows и удалите папку Index.

Выполните следующие шаги для удаления индекса из ресурсов:

1. Откройте диалоговое окно Опции одним из следующих способов:
   • Если проект уже открыт, щелкните вкладку Проект и выберите Опции.
   • Запустите ArcGIS Pro и щелкните Настройки внизу начальной страницы.

   Откроется диалог Опции.

2. Щелкните вкладку Индексация.

   Отображен текущий размер индекса.

3. Щелкните Удалить индекс.
4. Нажмите OK.

Административное управление настройками

Администраторы программного обеспечения могут предоставлять значения по умолчанию для параметров индексирования и предотвращают возможность изменения этих значений. Если настройки заблокированы администратором, отображается сообщение. Более подробно об административном управлении настройками.

Связанные разделы

Отзыв по этому разделу?

Индексация разделов каталога

Эта вкладка позволяет управлять индексацией разделов каталога.

На вкладке отображается список разделов каталога, подлежащих индексации и текущее состояние индексов.

Индексация ведется на уровне разделов.

При индексации раздела каталога создается список полей товаров и их значений, входящих в этот раздел и все его подразделы или указанное количество подразделов (см. Режимы индексации), по которому можно строить фильтрацию вывод товаров на страницах сайта.

Примечание: Индексации подлежат только поля типов данных товаров, помеченные как фильтруемые.

Добавление индексируемых разделов

Для добавления разделов каталога в список индексируемых на вкладке «Индексация» нажмите кнопку «Добавить категорию для индексации».

В появившемся окне выберите раздел каталога, для товаров которого хотите построить индекс.

В случае если у вас настроена индексация с указанием глубины вложенности (см. Режимы индексации), вам будет предложено ввести уровень вложенности индексации.

Выбранный раздел будет добавлен в список индексируемых.

Для создания индекса по разделу кликните по ссылке «Проиндексировать» в строке соответствующего раздела.

В появившемся диалоговом окне нажмите кнопку «Запустить».

Примечание: Не закрывайте окно браузера до окончания процесса индексации.

По окончании индексирования будет выведено диалоговое окно, уведомляющее об окончании индексации.

Примечание: По умолчанию за одну итерацию обрабатывается 25 записей, это значение можно изменить в параметре конфигурации catalog.index.limit (см. описание)

В таблице разделов каталога, подлежащих индексации, для проиндексированного раздела состояние индекса сменится на «Проиндексирован» и рядом с ним появится ссылка «Переиндексировать» для принудительного перестроения индекса, а так же в колонке «Дата индексации» будет отображена дата и время последней индексации.

Примечание: Не рекомендуется объединять в одном индексе разделы каталога с сильно отличающимися категориями товаров (например телевизоры, холодильники и шкафы). Система может отказать в пострении индекса если суммарное количество различных фильтруемых полей товаров, входящих в индекс, превышает оптимальное для построения фильтров. В этом случае следует провести раздельную индексацию вложенных подразделов выбранного раздела каталога.

Удаление индексируемых разделов

Для удаления индекса поставьте чекбокс напротив в строке с удаляемым разделом и нажмите на появившуюся кнопку . Также удалить индексируемый раздел можно через контекстное меню.

Вывод фильтров для проиндексированных разделов каталога

При выводе страниц с товарами проиндексированных разделов каталога рекомендуется использовать следующие макросы:

• Для вывода формы фильтрации объектов каталога catalog getSmartFilters().
• Для вывода списка объектов каталога, с учетом параметров фильтрации catalog getSmartCatalog().

Режимы индексации

Индексация разделов каталога производится в двух режимах: с указанием глубины вложенности и без.

Режим работы индексации настраивается с помощью параметра конфигурации catalog.index.advanced-mode (см. описание)

В обычном режиме индексации (catalog.index.advanced-mode=0) при добавлении раздела индексируются товары этого раздела и всех его подразделов.

В режиме с указанием глубины вложенности (catalog.index.advanced-mode=1) индексируются товары выбранного раздела и указанного при добавлении количества подразделов.

Рассмотрим различия в работе режимов на иллюстрации:

Автоматическая переиндексация

При наличии у хостинг-провайдера возможности периодического запуска скриптов (cron), вы можете включить автоматическую переиндексацию, для этого нужно назначить значение параметра конфигурации catalog.reindex-on-cron-event-enable = «1» (см. описание).

Подробная информация о настройке периодического выполнения скриптов в UMI.CMS доступна по ссылке.

При установке  параметра конфигурации catalog.allow-auto-update-filter-index = «1» (см. описание) включается автоматическое обновление индексов при измении/создании/удалении страниц товаров.

Что такое Индексация сайта — описание и особенности

Что такое индексация сайта

Индексация сайта — процесс сбора и обработки контента, представленного на сайте, поисковой системой. Индексация сайта подразумевает проверку файлов, открытых для сканирования поисковыми роботами. Это могут быть музыкальные, текстовые файлы, а также фильмы в различных форматах, предназначенных для онлайн-просмотра или скачивания пользователем на ПК.

Занимаются сканированием поисковые роботы (пауки). Они обрабатывают страницы ресурса, присутствующие на них изображения, текст, видео и другую информацию, включая программный код. Чтобы этот процесс прошел быстрее, сайты нужно добавить в панели вебмастеров Яндекс и Google и выставить необходимые настройки.

Страницы, прошедшие сканирование, добавляются в базу данных поисковика. В ней поисковая система ищет результаты, соответствующие запросам пользователей. Индексирование – ключевой нюанс успешной раскрутки сайта. Этим обусловлены следующие факты:

• страницы, не прошедшие индексацию, не показываются в выдаче поисковика, т.к. индексация сайта необходима для его участия в поиске;
• у каждой ПС свой поисковый робот, который добавляет страницы в базу, к примеру, у Google это Googlebot;
• настройка индексации – базовый уровень SEO-оптимизации онлайн-ресурса.

Чтобы веб-сайт удачно прошел индексирование, в первую очередь, нужно проверить открыт ли этот ресурс для захода поискового бота. Для этого обязательно должен быть файл под именем robots.txt. Он есть по умолчанию во многих CMS, однако проверить факт нахождения этого файла нужно обязательно. В нем должны быть прописаны правила, разрешающие вход робота и, при необходимости, запрещающие сканирование отдельных страниц:

User-agent: *
Disallow: …

Для быстрой проверки индексации следует в поисковой строке браузера написать команду site:[адрес страницы]. Это инициирует поиск всех страниц указанного сайта, прошедших индексацию.

Индексация заработной платы в 1С 8.3 ЗУП

Один из часто возникающих вопросов — это как производится индексация зарплаты в 1С 8.3 ЗУП. Дело в том, что индексации заработка обычно предшествует индексация штатного расписания. В программе предусмотрено, что может производиться индексация не только окладов, но и так называемой совокупной тарифной ставки. К тому же индексацию можно производить «по-старому», задействовав для этого скрытые по умолчанию из интерфейса документы. Рассмотрим, как проиндексировать зарплату в 1С 8.3 ЗУП пошагово на примере.

Подробнее смотрите в онлайн-курсе «ЗУП 3.1 кадровый и зарплатный учет от А до Я»

Нормативное регулирование

Согласно статье 134 ТК РФ, работодатель обязан выполнять индексацию заработной платы в связи с ростом индекса потребительских цен.

По данным Росстата индекс потребительских цен за 12 месяцев 2017 года составил 2,5 %.

Бюджетные учреждения проводят индексацию согласно трудовому законодательству и иным нормативно правовым актам. Порядок индексации заработной платы в иных учреждениях определяется работодателем в коллективном договоре, соглашении или локальном нормативном акте.

Письмо Роструда от 19.04.2010 N 1073-6-1 предусматривает обязанность работодателя прописать положение об индексации заработной платы в локальные нормативные акты организации.

Также стоит учитывать, что в статье 5.27 КоАП РФ предусмотрена ответственность за нарушение трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права.

Индексация штатного расписания

Индексацию штатного расписания в 1С ЗУП 3.1 выполните с помощью документа Изменение штатного расписания (Зарплата — Изменение штатного расписания).

Получите понятные самоучители 2021 по 1С бесплатно:

Выполнение индексации штатного расписания с помощью этого документа предполагается только в том случае, если в программе ведется история изменения штатного расписания (Настройка – Кадровый учет – Настройка штатного расписания – Ведется история изменения штатного расписания).

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

В документе Изменение штатного расписания:

1. Укажите дату изменения – дата, с которой будет зарегистрировано изменение (индексация) штатного расписания;
2. Подберите сотрудников – при индексации происходит изменение позиций, поэтому необходимо воспользоваться командой Изменить позицию и в окне подбора выбрать позиции для индексации;
3. После заполнения табличной части документа позициями выполните индексацию, воспользовавшись командой Заполнить показатели. В открывшемся окне выберите показатели, которые требуется проиндексировать. Далее, если необходимо отразить именно индексацию этого показателя, укажите для них вид заполнения Умножить на и определите показатель индексации.

После этого для всех подобранных в документ позиций изменится размер выбранных показателей:

Таким образом в документе можно проиндексировать (изменить) любые доступные показатели.

По умолчанию в документе отображаются только те показатели, которые входят в совокупную тарифную ставку (Настройка – Расчет зарплаты – Показатели, определяющие состав совокупной тарифной ставки). Однако в документ можно вывести и остальные показатели. Для этого воспользуйтесь командой табличной части документа Еще – Отображаемые показатели и выберите показатели.

Индексация штатного расписания, если используются тарифные группы

Если в 1С ЗУП 3.1 используются тарифные группы, т.е. в настройках установлен флажок Используются тарифные группы (Настройка – Расчет зарплаты), созданы группы в справочнике Тарифные группы (Настройка – Тарифные группы) и эти группы используются в позициях штатного расписания, тогда по таким позициям сначала утвердите новые тарифные группы документом Утверждение тарифной группы (Зарплата – Утверждение тарифной группы), а уже потом на его основании создайте Изменение штатного расписания по тем позициям, которые используют эти тарифные группы. Рассмотрим на примере.

На 01.01.2019 документом Утверждение тарифной группы установлены тарифы для Тарифной группы Слесаря (с привязкой к базовому тарифу).

С 01.11.2019 происходит индексация. Поэтому на 01.11.2019 вводится новый документ Утверждение тарифной группы. Он может быть введен из формы справочника Тарифная группа по кнопке Установить новые тарифы.

В документе Утверждение тарифной группы указывается новое значение базового тарифа и тарифы каждого разряда пересчитываются автоматически. Если же привязки к базовому тарифу нет, новое значение тарифов вводится по каждому разряду.

Далее из этого документа создается документ Изменение штатного расписания по кнопке Изменить штатное расписание. В нем автоматически будут изменены значения тарифов у позиций, где используется данная тарифная группа.

Индексация заработка

Ввод на основании документа «Изменение штатного расписания»

Для регистрации индексации заработка сотрудников в 1С 8.3 ЗУП используйте документ Изменение плановых начислений (Зарплата – Изменение оплаты сотрудников – Изменение плановых начислений). Этот документ можно ввести на основании документа Изменение штатного расписания – команда Изменить начисления сотрудников.

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

Рассмотрим на примере, как происходит расчет коэффициента индексации в документе Изменение плановых начислений.

В документе Изменение штатного расписания был отражен факт увеличения окладов всех позиций путем умножения на коэффициент 1.1, а также увеличения процента расчета ежемесячной премии с 10% до 12%.

В частности, произошло изменение оклада позиции Газомерщик/Производственный отдел.

Далее на основании Изменения штатного расписания вводится документ Изменение плановых начислений. Документ заполняется автоматически и происходит расчет коэффициента индексации для каждого сотрудника.

На позиции Газомерщик/Производственный отдел трудится сотрудник Геранькин Г.Г. У сотрудника произошло увеличение оклада с 20 000 до 22 000 (в 1.1 раза), а процент премии изменился с 10 до 12. Коэффициент индексации в документе рассчитывается следующим образом:

• Коэффициент индексации = Новый ФОТ / Старый ФОТ = (22 000 + 22 000 *12%) / (20 000 + 20 000*10%) = 24 640 / 22 000 = 1,12

Ручной ввод документа «Изменение плановых начислений» для регистрации индексации

Если изменение штатного расписания не отражалось или не ведется история изменения штатного расписания, то документ Изменение плановых начислений создайте из журнала документов Изменение оплаты сотрудников (раздел Зарплата).

Сотрудникам организации с 1 января выполняется индексация заработка:

• Оклад увеличивается на коэффициент 1,05;
• Процент ежемесячной премии с 10% до 15%.

В документе Изменение плановых начислений для регистрации такой индексации заполните документ нужными сотрудниками, установите флажок Учитывать как индексацию заработка и отразите изменение начислений, используя команду Заполнить показатели:

После этого произойдет изменение оклада и премии, а также расчет коэффициента индексации. Расчет коэффициента индексации выполнится следующим образом (на примере сотрудника Жасмин З.К.):

• Коэффициент индексации = Новый ФОТ / Старый ФОТ = (47 250 + 47 250 *15%) / (45 000 + 45 000*10%) = 54 337,5 / 49 500 = 1,09772727

Индексация штатного расписания и заработка сотрудников «по-старому»

По умолчанию из интерфейса скрыты документы, которыми можно проводить индексацию штатного расписания и зарплаты в 1С 8.3 ЗУП «по-старому» — это Индексация штатного расписания (Кадры — Индексация штатного расписания) и Индексация заработка (Зарплата — Индексация заработка).

Для того, чтобы стал виден документ Индексация штатного расписания:

• В разделе Кадры по кнопке в виде «шестеренки», расположенной в правом верхнем углу, выберите пункт Настройка навигации:
• В открывшейся форме в левой таблице найдите документ Индексация штатного расписания и добавьте его в правую таблицу (двойным щелчком мыши или с помощью кнопок, расположенных между таблицами):

После этого документ Индексация штатного расписания можно создать из раздела Кадры:

Для отображения в интерфейсе документа Индексация заработка в разделе Зарплата по кнопке в виде «шестеренки», расположенной в правом верхнем углу, также выберите пункт Настройка навигации.

В открывшейся форме в левой таблице найдите документ Индексация заработка и добавьте его в интерфейс также, как документ Индексация штатного расписания:

Документ Индексация заработка станет доступен в разделе Зарплата:

Ограничением данных документов является то, что в отличие от документов Изменение штатного расписания и Изменение плановых начислений в них можно производить индексацию только ограниченного количества показателей: Оклада, Тарифных ставок (дневной, часовой). Однако они имеют и преимущество перед документами индексации «по-новому» — в них можно настраивать округление:

Для того, чтобы провести индексацию штатного расписания и заработка в 1С 8.3 ЗУП заполните поле Коэффициент индексации:

В организации с 1 октября производится индексация окладов и тарифных ставок на 10%.

Чтобы индексация штатки была зарегистрирована с 1 октября 2019 г. в качестве Месяца укажите – Октябрь 2019:

Дата документа на индексацию не влияет.

В разделе Индексируемые показатели настройте округление значений показателей:

В поле Коэффициент индексации укажите значение – 1,10 (индексация на 10%):

Индексация штатного расписания будет закончена.

На основании документа Индексация штатного расписания создайте документ Индексация заработка:

В документе Индексация заработка расчет и заполнение будут произведены автоматически:

См. также:

Если Вы еще не подписаны:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

После оформления подписки вам станут доступны все материалы по 1С ЗУП, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

терминология — Что значит индексация в контексте Git?

что такое индексирование?

индексирование (также: indexing, staging) — это процесс добавления текущего содержимого (изменённого) файла в индекс (также: index area, staging area).

какой командой выполняется это добавление?

командой add:

$ git add файл

что при этом происходит с технической точки зрения?

берётся содержимое файла, впереди к нему дописывается немного служебной информации, высчитывается sha1sum от получившегося (это т.н. хэш), затем всё это сжимается и сохраняется в файле в каталоге .git/objects. имя файла уникально, т.к. формируется на основании полученного хэша.
затем в файл .git/index дописывается ещё одна запись о добавленном файле (сохраняется имя файла, а также тот самый хэш, и ещё некоторое количество служебной информации):

| файл         | хэш | ... |
| каталог/файл | хэш | ... |

и что, этот файл

записи в этом файле заново пересоздаются в результате переключения содержимого рабочего каталога командой checkout. кстати, именно из этого файла программа git черпает информацию о том, какие именно изменения должны быть зафиксированы с помощью commit-а (используется содержимое этого файла и при некоторых других операциях — см. подробнее в документации). среди других команд, добавляющих либо удаляющих записи в этом файле, стоит отметить reset, rm, stash.

так для чего он вообще нужен, этот «индекс»?

с технической точки зрения основная цель его существования — избежать (ресурсоёмких) операций с файлами в рабочем каталоге (working tree) при выполнении команды commit. благодаря его наличию при выполнении команды commit не производится никаких манипуляций с файлами в рабочем каталоге — ни поиск изменённых файлов, ни сжатие их текущего содержимого. (оговорка: при наличии опций -a/--all/-p/--patch/--interactive команды commit все эти оптимизации «идут коту под хвост»: выполняется и поиск и сжатие).

Создание и использование индекса для повышения производительности

Если вы часто выполняете поиск в таблице в Access или сортируете ее записи по определенному полю, вы можете ускорить эти операции, создав индекс для поля. Access использует индексы в таблице так же, как вы используете индекс в книге: для поиска данных Access ищет расположение данных в индексе. В некоторых случаях, например для первичного ключа, Access автоматически создает для вас индекс. В других случаях вы можете захотеть создать индекс самостоятельно.

В этой статье представлены индексы и рассказывается, как решить, какие поля индексировать, а также как создать, удалить или изменить индекс. Здесь также объясняются условия, при которых Access автоматически создает индексы.

В этой статье

Примечание: Вы не можете использовать методы, описанные в этой статье, для создания индекса для таблицы в веб-базе данных. Производительность веб-базы данных зависит от производительности нескольких факторов, таких как сервер SharePoint, на котором размещена веб-база данных.

Что такое индекс?

Вы можете использовать индекс, чтобы помочь Access быстрее находить и сортировать записи. Индекс хранит расположение записей на основе поля или полей, которые вы выбираете для индексации. После того, как Access получит местоположение из индекса, он может извлечь данные, перейдя непосредственно в правильное местоположение. Таким образом, использование индекса может быть значительно быстрее, чем сканирование всех записей для поиска данных.

Решите, какие поля индексировать

Вы можете создавать индексы, основанные на одном поле или на нескольких полях. Вероятно, вы захотите проиндексировать поля, которые вы часто ищете, поля, которые вы сортируете, и поля, которые вы присоединяете к полям в других таблицах в запросах нескольких таблиц. Индексы могут ускорить поиск и запросы, но они могут снизить производительность при добавлении или обновлении данных. Когда вы вводите данные в таблицу, содержащую одно или несколько проиндексированных полей, Access должен обновлять индексы каждый раз при добавлении или изменении записи.Добавление записей с помощью запроса на добавление или путем добавления импортированных записей также может быть медленнее, если целевая таблица содержит индексы.

Примечание: Первичный ключ таблицы индексируется автоматически.

Вы не можете индексировать поле с типом данных OLE Object, Calculated или Attachment. Для других полей рассмотрите возможность индексации поля, если применимо все следующее:

• Тип данных поля — краткий текст (текст в Access 2010), длинный текст (памятка в Access 2010), число, дата / время, авто-число, валюта, да / нет или гиперссылка.

• Вы ожидаете поиска значений, хранящихся в поле.

• Вы ожидаете сортировки значений в поле.

• Предполагается, что в поле будет храниться много разных значений. Если многие значения в поле совпадают, индекс не может значительно ускорить запросы.

Многопольные индексы

Если вы думаете, что часто будете искать или сортировать по двум или более полям одновременно, вы можете создать индекс для этой комбинации полей.Например, если вы часто устанавливаете критерии для полей Vendor и ProductName в одном запросе, имеет смысл создать индекс с несколькими полями для обоих полей.

При сортировке таблицы по индексу с несколькими полями Access сначала выполняет сортировку по первому полю, определенному для индекса. Вы устанавливаете порядок полей при создании индекса с несколькими полями. Если есть записи с повторяющимися значениями в первом поле, Access выполняет сортировку по второму полю, определенному для индекса, и так далее.

Вы можете включить до 10 полей в многопольный индекс.

Создать индекс

Чтобы создать индекс, вы сначала решаете, хотите ли вы создать индекс с одним полем или индекс с несколькими полями. Вы создаете индекс для одного поля, задав свойство Indexed . В следующей таблице перечислены возможные настройки для свойства проиндексировано .

Если вы создаете уникальный индекс, Access не позволит вам ввести новое значение в поле, если это значение уже существует в том же поле в другой записи.Access автоматически создает уникальный индекс для первичных ключей, но вы также можете запретить повторяющиеся значения в других полях. Например, вы можете создать уникальный индекс для поля, в котором хранятся серийные номера, чтобы не было двух продуктов с одинаковыми серийными номерами.

Создать индекс с одним полем

1. В области навигации щелкните правой кнопкой мыши имя таблицы, в которой вы хотите создать индекс, а затем выберите Design View в контекстном меню.

2. Щелкните имя поля для поля, которое вы хотите проиндексировать.

3. В разделе Свойства поля щелкните вкладку Общие .

4. В свойстве проиндексировано щелкните Да (дубликаты ОК) , если вы хотите разрешить дублирование, или Да (без дубликатов) , чтобы создать уникальный индекс.

5. Чтобы сохранить изменения, нажмите Сохранить на панели быстрого доступа или нажмите CTRL + S.

Создать индекс с несколькими полями

Чтобы создать индекс с несколькими полями для таблицы, вы включаете строку для каждого поля в индексе и включаете имя индекса только в первую строку. Access рассматривает все строки как часть одного индекса до тех пор, пока не дойдет до строки, содержащей другое имя индекса.Чтобы вставить строку, щелкните правой кнопкой мыши место, куда вы хотите вставить строку, а затем выберите Вставить строки в контекстном меню.

1. В области навигации щелкните правой кнопкой мыши имя таблицы, в которой вы хотите создать индекс, а затем выберите Design View в контекстном меню.

2. На вкладке Design в группе Показать / скрыть щелкните Indexes .

   Появится окно индексов. Измените размер окна, чтобы отображались пустые строки и свойства индекса.

3. В столбце Имя индекса в первой пустой строке введите имя индекса. Вы можете назвать индекс после одного из полей индекса или использовать другое имя.

4. В столбце Имя поля щелкните стрелку, а затем щелкните первое поле, которое вы хотите использовать для индекса.

5. В следующей строке оставьте поле Имя индекса пустым, а затем в столбце Имя поля щелкните второе поле для индекса. Повторяйте этот шаг, пока не выберете все поля, которые хотите включить в индекс.

6. Чтобы изменить порядок сортировки значений поля, в столбце Порядок сортировки окна Индексы щелкните По возрастанию или По убыванию .Порядок сортировки по умолчанию — По возрастанию.

7. В окне Индексы в разделе Свойства индекса установите свойства индекса для строки в столбце Имя индекса , который содержит имя индекса. Задайте свойства в соответствии со следующей таблицей.

   Этикетка	Стоимость
   Первичная	Если Да , индекс является первичным ключом.
   Уникальный	Если Да , каждое значение в индексе должно быть уникальным.
   Игнорировать нули	Если Да , записи со значением Null в индексированных полях исключаются из индекса.

8. Чтобы сохранить изменения, щелкните Сохранить на панели инструментов быстрого доступа или нажмите CTRL + S.

9. Закройте окно индексов.

Удалить индекс

Если вы обнаружите, что индекс становится ненужным или слишком сильно влияет на производительность, вы можете удалить его.Когда вы удаляете индекс, вы удаляете только индекс, а не поле или поля, на которых он построен.

1. В области навигации щелкните правой кнопкой мыши имя таблицы, в которой вы хотите удалить индекс, а затем выберите Design View в контекстном меню.

2. На вкладке Design в группе Показать / скрыть щелкните Indexes .

   Появится окно индексов.Измените размер окна, чтобы отображались пустые строки и свойства индекса.

3. В окне «Индексы» выберите строку или строки, содержащие индекс, который вы хотите удалить, и нажмите клавишу DELETE.

4. Чтобы сохранить изменения, нажмите Сохранить на панели быстрого доступа или нажмите CTRL + S ..

5. Закройте окно Индексы .

Просмотр и редактирование указателей

Вы можете просмотреть индексы таблицы, чтобы взвесить их влияние на производительность или убедиться, что определенные поля проиндексированы.

1. В области навигации щелкните правой кнопкой мыши имя таблицы, в которой вы хотите изменить индекс, а затем выберите Design View в контекстном меню.

2. На вкладке Design в группе Показать / скрыть щелкните Indexes .

   Появится окно индексов. Измените размер окна, чтобы отображались пустые строки и свойства индекса.

3. Просматривайте или редактируйте индексы и свойства индексов в соответствии с вашими потребностями.

4. Чтобы сохранить изменения, нажмите Сохранить на панели быстрого доступа или нажмите CTRL + S ..

5. Закройте окно Индексы .

Автоматическое создание индекса

В некоторых случаях Access автоматически создает для вас индексы. Например, индекс автоматически создается для любого поля или полей, которые вы назначаете в качестве первичного ключа таблицы.

Другой источник автоматического создания индекса — это параметр AutoIndex on Import / Create в диалоговом окне Access Options . Access автоматически индексирует любые поля с именами, которые начинаются или заканчиваются символами, введенными в поле AutoIndex on Import / Create , например ID , key , code или num .Чтобы просмотреть или изменить текущую настройку, выполните следующие действия:

1. Щелкните File > Options .

2. Щелкните Object Designers , а затем в разделе Table design добавьте, отредактируйте или удалите значения в поле AutoIndex on Import / Create . Используйте точку с запятой (; ) для разделения значений.

   Примечание: Если имя поля начинается или заканчивается значением, указанным в поле, поле автоматически индексируется.

3. Щелкните ОК .

Поскольку каждый дополнительный индекс требует Access для выполнения дополнительной работы, производительность снижается при добавлении или обновлении данных. Поэтому вам может потребоваться изменить значения, отображаемые в поле AutoIndex при импорте / создании , или уменьшить количество значений, чтобы минимизировать количество создаваемых индексов.

Верх страницы

Индексирование очень больших таблиц.Краткое руководство по передовой практике… | by Kovid Rathee

DATA ENGINEERING

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

Последний раз эта статья обновлялась 5 августа 2021 года. Спасибо Джону Троллопу за указание. допустил несколько досадных опечаток.

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

Проблемы с медленными запросами чаще возникают при работе с большими таблицами. Мы можем видеть медленные запросы в двух разных типах настроек: одна не критична по времени, а другая критична. Давайте поговорим о , что такое медленные запросы для наиболее важного в первую очередь.Если вы разрабатываете приложение, хорошее практическое правило — писать часто выполняемые запросы таким образом, чтобы они возвращали ответ в течение 500 мс. Для аналитических систем (некритичных по времени) это очень субъективно. Отчеты и инструменты бизнес-аналитики могут быть непростыми. Кто-то однажды сказал мне, что работа с единой панелью управления бизнес-аналитикой занимает целый день, и это их не особо беспокоило.

Довольно много поработав с большими таблицами (> 1 миллиарда записей), я понял, что мы можем позаботиться о нескольких вещах, выполняя для них индексацию.

Создание и поддержка индекса для огромной таблицы обходится дороже, чем для небольших таблиц. Всякий раз, когда вы создаете индекс, копия индексированного столбца + первичный ключ создается на диске, и индекс сохраняется в памяти в максимально возможной степени. Если в индексе есть все данные, необходимые для запроса, он никогда не перейдет к реальной таблице. Например, если вы отфильтровали данные для customer_id и сгруппировали по год , а индекс находится на (customer_id, год) , и вы не запрашиваете что-либо еще в инструкции SELECT , тогда запрос не перейдет к таблице на диске для извлечения записей, поскольку индекс удовлетворяет всем требованиям к данным для запроса.

Вы должны стремиться иметь оптимальные индексы для всех запросов, то есть индексы, которые покрывают большую часть, если не все, столбцы, которые должны использовать индекс в таких операциях, как фильтрация, группировка, сортировка, выбор и т. Д. Эти индексы называются покрывающими индексами. Они покрывают требования к вашим запросам.

Чем больше индексов, тем медленнее вставляются; чем больше индексов, тем больше занимают диск и память.

Составить указатель сложно. Если в вашей системе имеется множество запросов, один или даже несколько индексов могут не соответствовать требованиям всех этих запросов.Это опасно! Как упоминалось ранее, первая реакция — это создание индекса, который соответствует вашим запросам, без использования индексов.

Накладные расходы на индексы велики. Каждый раз, когда вы добавляете индекс, запись в индексированную таблицу становится медленнее, так как каждый раз при поступлении записи приходится балансировать больше структур B-дерева. Стоимость определенно выше, когда записи B-дерева не являются последовательными, поэтому чаще всего лучше выбрать существующий индекс и изменить его, добавив еще один столбец или изменив порядок столбцов, или и то, и другое.

Уменьшите занимаемую площадь, изменив существующий индекс вместо того, чтобы бездумно добавлять новые индексы.

Чтобы это произошло, вы должны глубоко разбираться в своих запросах. Было бы здорово иметь каталог, который сообщает вам, для какого запроса требуется какой индекс, чтобы изменения, которые вы вносите в индекс, не оказали непреднамеренного воздействия на остальные запросы.

MySQL поддерживает оперативные изменения для операций с индексами — поэтому, если вы создаете или удаляете индекс, чтение и запись в таблице не будут затронуты во время создания индекса.Об этом говорится в документации, но я видел проблемы с этим. Для повышения производительности операций с индексами используйте инструмент Percona pt-online-schema-change. Это проверено и проверено.

Балансировка большого B-дерева требует больше ресурсов, чем балансировка меньшего B-дерева. При секционировании ваша таблица под капотом разбивается на более мелкие подтаблицы, но вы не узнаете об этом, если не перейдете на диск и не увидите, что вместо одного для вашей таблицы созданы разные файлы таблиц. То же самое и с индексами в этой таблице.

Основной мотив индексации и разделения один и тот же — отбрасывать данные для запросов. Помимо отбрасывания данных с помощью сокращения разделов, разделы также имеют положительный побочный эффект, о котором я только что упомянул — это дает нам меньшие деревья для балансировки и меньшие индексы для пересчета.

Еще одно практическое правило — использовать секционирование для действительно больших таблиц, то есть таблиц, содержащих не менее 100 миллионов строк. После завершения разделения все ваши запросы к разделенной таблице должны содержать partition_key в предложении WHERE , в противном случае это будет полное сканирование таблицы, что эквивалентно линейному поиску по всей таблице.

Разделение приводит к уменьшению B-деревьев / индексов, следовательно, меньше работы по пересчету этих индексов при вставках.

Чтобы индексация работала, у вас должно быть подходящее поле, которое могут использовать все ваши запросы. Существует множество различных типов разделов, которые вы можете использовать для своих данных. Узнайте больше о них здесь.

Хотя это должно быть покрыто созданием покрывающих индексов, я думаю, что это заслуживает отдельного упоминания, потому что индексы могут только помочь вам скрыть неправильное написание запросов.Дисковые операции обходятся дорого. Я продолжаю использовать аналогию Джима Грея для демонстрации дискового ввода-вывода, поскольку это важно понимать в текущем контексте.

Операции сортировки без использования индекса выполняются на диске. Диски медленные. Чтобы избежать операций с диском, убедитесь, что вы ищете подсказки и информацию в EXPLAIN PLAN вашего запроса. Когда вы видите filesort , знайте, что он будет пытаться уместить всю таблицу в памяти множеством кусков.Если таблица слишком велика для размещения в памяти, она создаст временную таблицу на диске и сделает это там. Обратите внимание на , используя filesort с комбинацией или без нее, используя временную . Когда MySQL не может выполнить сортировку с использованием индекса, с использованием файлового порта будет отображаться в плане.

Чтобы понять это всесторонне, просмотрите эту очень старую публикацию, написанную кем-то, кто работает над оптимизатором MySQL. Хотя пост старый, я думаю, что он все еще актуален, и в этой части мало что изменилось.

Есть несколько вещей, о которых вы должны позаботиться при сортировке — помните, что вы не можете пропустить столбцы в индексе. Вы не можете написать запрос, который упорядочивает по x, z и ожидать, что он будет полностью использовать индекс для индекса. Индекс также не будет работать, если у вас есть фильтр диапазона или предложение IN в первом столбце. Это также не будет работать, если два столбца (x, y) отсортированы в запросе в другом порядке, то есть ORDER BY x ASC, y DESC .Если вы не позаботитесь ни об одном из этих пунктов, индекс не выполнит запрос.

Суть этого момента заключалась в том, чтобы донести идею использования индексов и для сортировки, иначе это будет очень дорогостоящей операцией.

Работа с большими таблицами в базах данных — это весело. Это действительно когда вы понимаете тонкости системы баз данных, ее сильные и слабые стороны. Я бы посоветовал вам создать тестовую базу данных, сгенерировать тестовые данные для заполнения большой таблицы и выполнить запросы, чтобы понять, как все это работает.Практика превосходит теорию.

Благодарим Кая Сассновски за этот доклад, который подтвердил и укрепил мои годы изучения индексирования в MySQL.

Это часть серии статей о производительности баз данных и SQL для Науки о данных. Вот некоторые из них —

10 самых популярных вопросов и ответов об индексах SQL Server

Введение

Без сомнения, немногие технологии в SQL Server вызывают столько же путаницы и распространение дезинформации, как индексы.В этой статье рассматриваются некоторые из наиболее часто задаваемых вопросов и некоторые, которые следует задавать, но часто не задают. Мы будем использовать SQL Server 2016 в качестве примеров и инструмент для анализа плана выполнения запросов SQL Server, ApexSQL Plan, чтобы изучить влияние индексов на типичную бизнес-проблему: таблицу клиентов.

Вопрос 1: Что такое индекс?

Когда-то наиболее распространенными примерами использования указателей были словари и телефонные книги. В сегодняшнем связанном обществе с доступными онлайн-ресурсами, которые всего двадцать лет назад были бы отвергнуты как чистая фантазия, вполне возможно, что вы никогда не держали ни один из них в своих руках! Итак, давайте посмотрим на онлайн-ресурс: список исчезающих видов, который ведет Всемирный фонд дикой природы на своем веб-сайте www.worldwildlife.org. Список начинается так:

Он продолжается и на момент написания состоит из двух страниц. Беглый взгляд на список показывает, что виды расположены в алфавитном порядке по их общим названиям. Но представьте, что вы биолог и привыкли использовать латинские имена. Как бы вы нашли запись для видов Thunnus и Katsuwonus ? Что ж, вам нужно читать до самого конца списка, так как у него есть общее название тунец (как в вашем сэндвиче!) И он последний в алфавитном списке по общему названию.»Отлично!» думаешь. Не так сложно прочитать две страницы, чтобы найти то, что я ищу.

А теперь представьте, что этот список содержит все известные виды в мире (около 8,7 миллиона), составленные аналогичным образом. Прочитать этот список, чтобы найти вид по латинскому названию, не доставит вам большого удовольствия и потребует большого количества операций ввода-вывода на компьютере. В базе данных ввод-вывод часто (если не всегда) является самым большим узким местом.

Если мы сможем сократить количество операций ввода-вывода, необходимых для поиска нужной информации, мы сможем эффективно дать бутылке горлышко большего размера.

Это сокращение также приведет к дополнительным преимуществам, таким как сокращение времени ЦП, времени ожидания, использования кеша и т. Д.

Таким образом, цель индекса в таблице базы данных — уменьшить количество операций ввода-вывода. Чтобы понять, как это работает, нам нужно сначала взглянуть на таблицу, у которой нет индексов.

Вопрос 2: Как выглядит таблица без индексов?

SQL Server хранит все данные во всех своих файлах для всех баз данных на 8К страницах. Для каждой базы данных есть как минимум два файла: один для данных, который имеет тип файла по умолчанию.mdf и один для журнала, который использует .ldf в качестве типа файла по умолчанию. Каждая таблица в базе данных имеет одну или несколько страниц. Чтобы отслеживать эти страницы, SQL Server использует специальный набор страниц, называемых страницами IAM (для карты распределения индексов). Несмотря на слово «Индекс» в названии, IAM также используются для неиндексированных таблиц. Это так называемые кучи.

Куча очень похожа на то, что подразумевает ее название: неупорядоченная куча вещей. Это может быть грязное белье, остатки строительных материалов, беспорядок, оставленный на пляже во время прилива, или, как в данном случае, куча страниц для таблицы в SQL Server.Ничего не организовано каким-либо образом, кроме страниц IAM, которые связаны друг с другом, поэтому SQL Server может найти все страницы данных для таблицы. Графически это выглядит примерно так:

Источник: © Microsoft.com

Все данные есть, но единственный способ найти что-либо — это прочитать их с самого начала. Для очень большого стола это будет ужасно неэффективно. Посмотрим, что будет с такой таблицей.

Начнем с создания таблицы клиентов.Во-первых, вот DDL для таблицы клиентов:

Затем давайте заполним его данными с помощью ApexSQL Generate:

Теперь давайте воспользуемся ApexSQL Plan, чтобы изучить этот простой запрос:

Когда мы просматриваем предполагаемый план выполнения, мы видим:

Главное, что будет делать SQL Server, — это сканирование таблицы.Это означает, что он будет читать все строки этой таблицы, пока не найдет строку с идентификатором клиента 50000. Интересно, что если мы наведем курсор на большую стрелку справа налево в предполагаемом плане, мы увидим следующее:

Предполагаемые строки = 1! Это потому, что SQL Server ожидает только одного клиента с совпадающим идентификатором. Могло быть больше (поскольку на данный момент ничто не может предотвратить это), но нет никакого способа узнать наверняка.

Хорошо, теперь давайте запустим этот запрос, чтобы узнать, что мы можем узнать.Самое интересное — это вкладка чтения ввода-вывода:

Имеется 2506 логических операций чтения — по одному на каждую страницу в таблице. Кроме того, существует равное количество операций чтения с упреждающим чтением. Это физические чтения, которые SQL Server выполняет в ожидании необходимости. Итак, какая часть таблицы это? Этот запрос сообщает нам, сколько страниц используется этой таблицей:

И этот запрос говорит нам:

Верно! SQL Server должен был прочитать все страницы таблицы, кроме одной! Возможно, вы думали, что он найдет соответствующую строку примерно на полпути? Это было бы ожидаемое время выполнения, верно? O (n / 2)? Но поскольку SQL Server выполняет операции упреждающего чтения, чтобы минимизировать количество операций чтения, он завершает чтение всех страниц данных.(Другая страница содержит метаданные.)

Если бы эта таблица была частью загруженной системы OLTP и имела миллионы строк и тысячи одновременных поисков, это сильно затруднило бы использование системных ресурсов. Даже если бы вы могли удерживать всю таблицу в пуле буферов, это сделало бы эти буферы недоступными для других запросов. В любом случае это сделает сервер слабым. Правильное индексирование — это лекарство!

Вопрос 3. Какие типы индексов доступны в SQL Server?

SQL Server поддерживает индексацию для различных нужд.Заимствуя документацию Microsoft, они доступны в SQL Server 2016:

Источник: © 2017 Microsoft

Полнотекстовые, пространственные и XML-индексы выходят за рамки данной статьи. Мы сконцентрируемся на кластерных и некластеризованных индексах и рассмотрим некоторые из их расширений, включая уникальные и отфильтрованные индексы, а также полезность включенных столбцов.Хотя это не упомянуто выше, мы также не будем рассматривать в этой статье индексы columnstore или таблицы в памяти.

Как описано выше, кластеризованный индекс влияет на то, как данные фактически хранятся. В куче строки данных хранятся в произвольном порядке. Они пишутся везде, где подходят, с минимальной нагрузкой на ресурсы SQL Server, такие как пул буферов и подсистема ввода-вывода. С другой стороны, когда вы создаете кластерный индекс для таблицы, организация данных изменяется так, что теперь они упорядочены в соответствии с указанными ключами.Весь индекс организован в виде B-дерева («B» означает сбалансированный), где конечные узлы являются фактическими страницами данных, а один или несколько уровней узлов индекса построены поверх конечных узлов вплоть до единственного корневого узел. Результат дает некоторые гарантии относительно асимптотической производительности индекса. Большинство операций (поиск, вставка и удаление) выполняются в O (журнал n ), где n — количество записей в индексе.

Некластеризованный индекс разделяет концепцию B-дерева для узлов индекса с теми же гарантиями производительности.Однако такие индексы , а не не влияют на организацию страниц данных, которые могут быть кластеризованы или нет. Некоторые дополнительные функции некластеризованных индексов:

• Уникальные индексы — где записи индекса должны быть уникальными, и SQL Server гарантирует, что они
• Отфильтрованные индексы — это индексы, построенные с помощью предложения WHERE, чтобы ограничить то, что включается в индекс.
• Включенные столбцы — которые могут содержать подмножество неключевых столбцов как часть индекса.

Если вы обдумаете значение этих описаний, вы увидите, что таблица — это , — куча, или — кластеризованный индекс. Другие последствия заключаются в том, что, поскольку конечный узел кластеризованного индекса является страницей данных, нет необходимости во включенных столбцах (поскольку все столбцы находятся на странице данных) или отфильтрованных индексах (поскольку кластеризованный индекс — это вся таблица по определению) . Более тонкое понимание заключается в следующем: поскольку теория B-Tree не оговаривает уникальность ключа, кластеризованный индекс может иметь строки с повторяющимися ключами.В этом случае SQL Server добавит к индексу скрытый уникальный определитель (4-байтовое целое число), чтобы обеспечить уникальность.

Вопрос 4. Что происходит при создании кластерного индекса?

Как объяснялось в ответе на вопрос 3 выше, когда вы создаете кластерный индекс, порядок строк на страницах данных изменяется. Добавляя кластеризованный индекс к нашему рабочему примеру, команда проста:

Мы можем просмотреть и запустить это в ApexSQL Plan. Во-первых, давайте посмотрим на примерный план выполнения:

Ориентировочный план показывает только операцию по созданию индекса. Это означает, что он обрабатывается внутри и / или SQL Server предпочитает не раскрывать подробности. Однако сделать вывод о том, что должно произойти, несложно:

1. Прочтите все страницы таблицы
2. Сортировать строки по указанному ключу
3. Заполнять новые страницы отсортированными строками (до коэффициента заполнения)
4. Закрепите новые страницы в постоянном хранилище
5. Освободите страницы, используемые строками данных, перед созданием индекса.

Если мы действительно выполним это, мы сможем увидеть некоторые из этих действий:

Это вполне соответствует ожиданиям! При чтении справа налево содержимое таблицы считывается (сканирование таблицы), 100 000 строк отправляются на сортировку, затем отсортированный набор данных отправляется в операцию IndexInsert, которая создает узлы индекса. Оператор параллелизма указывает обеспечение для параллельной операции IndexInsert, которая может выполняться во многих параллельных потоках в зависимости от количества доступных процессоров.Наконец, новые строки вставляются в таблицу. Мы не видим оператора для освобождения неиспользуемых страниц, но тогда это фоновая операция, которую вы никогда не увидите в плане выполнения.

Теперь, когда у нас есть кластерный индекс, повлияет ли это на наш исходный запрос?

Теперь примерный план выглядит так:

Первоначальное сканирование таблицы было заменено поиском по кластерному индексу.Поможет ли это уменьшить количество операций ввода-вывода, используемых для получения этой строки? Давайте посмотрим!

Это огромная разница в ! Исходные 2500 считываний сократились до трех. Поскольку мы знаем, что для этой строки есть только одна страница данных (поскольку строка имеет общую длину <8090 - тема для другой статьи), мы можем сделать вывод, что два других ввода-вывода предназначены для страниц, содержащих узлы индекса. Мы можем подтвердить это простым запросом:

Что возвращает:

соответствует нашим ожиданиям, и ввод-вывод читает.

Графически наш кластерный индекс теперь имеет такую ​​структуру:

Источник: © Microsoft.com

Вопрос 5. А как насчет некластеризованных индексов?

Пока что мы искали клиентов только по их идентификатору.Что, если бы мы вместо этого хотели искать клиента по имени? Что-то вроде этого, возможно:

Предполагаемый план выполнения сейчас:

О, нет! Мы вернулись к операции сканирования. (На этот раз это сканирование кластерного индекса, поскольку, как упоминалось ранее, таблица является либо кучей, либо кластеризованным индексом, и мы просто включили в нее таблицу Customers.Но становится еще хуже! Фактическое количество операций ввода-вывода увеличилось на !

Это потому, что SQL Server теперь также использует узлы индекса при сканировании страниц данных. Что можно сделать в этой ситуации? Конечно, добавьте некластеризованный индекс!

Давайте воспользуемся этим DDL для создания индекса:

Имея это на месте, давайте еще раз попробуем SELECT. На этот раз план выглядит так:

Теперь мы видим, что выполняется поиск по индексу с использованием нового индекса, за которым следует поиск по ключу. Поиск ключа необходим, поскольку мы написали:

и SQL Server должен вернуться к страницам данных, чтобы получить другие столбцы в строке.Причина — поиск ключа из-за того, как SQL Server строит некластеризованные индексы. Вам будет простительно думать, что некластеризованный индекс содержит указатель на страницы, содержащие строку данных. На самом деле это не так. Вместо указателя (например, номера сектора на диске) некластеризованный индекс сохраняет ключ кластеризованного индекса , если есть кластеризованный индекс. Конечно, прежде чем мы сюда попали, мы поместили кластерный индекс в таблицу Customers! Как следствие, мы получаем ключевой поиск.Если вы догадались, что это означает отдельный поиск в кластерном индексе, вы были правы!

Итак, снижает ли некластеризованный индекс наши операции ввода-вывода? Давайте проведем реальный пробег и посмотрим:

Как показано, наблюдается существенное сокращение операций ввода-вывода. Возможно, вы ожидали всего 3 чтения, как в примере с кластеризованным индексом, который мы использовали ранее. Однако нет никакой гарантии, что в таблице присутствует только одна Кейтлин Майерс. Давайте проверим, что:

возвращает:

Итак, чтение ввода-вывода на самом деле вполне реалистично.

Название «некластеризованный» происходит от того простого факта, что этот тип индекса не является кластеризованным. Что это такое, это B-дерево, построенное поверх таблицы (которая может быть сгруппирована или скопирована в куча). Итак, если есть также кластеризованный индекс, некластеризованный индекс живет рядом с кластеризованным индексом, и его записи указывают на конечный уровень этого индекса — страницы данных. Некластеризованный индекс имеет такую ​​структуру:

Источник: © Microsoft.ком

Вопрос 6: А как насчет включенных столбцов? Чем они могут помочь?

Вы видели, что запрос, использующий некластеризованный индекс, должен искать другие столбцы с ключевым поиском в кластеризованном индексе. Что, если бы вы часто запрашивали только часть других столбцов? Что, если бы вы часто искали номер телефона клиента? Вот тут и пригодятся включенные столбцы. Если я изменю некластеризованный индекс следующим образом:

затем запустите этот запрос:

План выполнения меняется на это:

Больше никаких ключей! Чтения ввода-вывода также уменьшаются:

Итак, мы видим положительную пользу включенных столбцов.Это, естественно, вызывает вопрос: «Почему бы просто не добавить включенные столбцы в индекс в первую очередь?» Чтобы понять, почему, сначала рассмотрите следующее: хотя ключевые столбцы хранятся на всех уровнях индекса, неключевые столбцы сохраняются только на конечном уровне . Во избежание путаницы, хотя некластеризованный индекс указывает на страницы данных, его листья являются частью самого B-дерева.

Почему бы не поместить включенные столбцы в ключи индекса? Причин несколько:

• Стоимость хранения.Если включенные столбцы не нужны для других типов поиска, их исключение из списка ключей позволяет сократить записи в указателе и получить более плоское B-дерево. Это приводит к меньшему количеству операций ввода-вывода индекса.
• Ограничения SQL Server. В настоящее время в индексе может быть не более 16 ключевых столбцов, и в целом эти ключевые столбцы не могут превышать максимальный размер индекса в 900 байт.
• Включенные столбцы могут быть типами данных, которые нельзя использовать в качестве столбцов индекса.Например, nvarchar (max), varbinary (max), xml и другие не могут быть ключевыми столбцами, но может включать столбца.

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

Хотя мы не упомянули об этом, вы можете поместить некластеризованный индекс в кучу — это таблица без кластеризованного индекса.В этом случае любой поиск на страницах данных является поиском RID. «R» означает строку, а RID состоит из виртуального адреса, который включает номер файла и номер страницы страницы данных, а также слот строки на странице данных.

Вопрос 7: Что насчет первичных ключей (и ключей в целом)?

До сих пор мы избегали обсуждения первичных ключей. Это не случайность. Слишком часто кластерные индексы и первичные ключи объединяются, как будто это одно и то же.Они не! Вот почему мы оставили их до сих пор. Лучше всего получить твердое представление о типах индексов, прежде чем вводить ключи.

Чтобы быть отношением в формальном, реляционно-алгебраическом смысле слова, таблица (то, что большинство РСУБД называют отношениями ) должна иметь ключ — некоторый столбец или набор столбцов, которые вместе взятые однозначно идентифицируют строку в стол. Однако ключ — это не индекс. Он может (и обычно поддерживается) поддерживается индексом , но в его основе ключ — это ограничение — условие, которое база данных должна поддерживать для сохранения ссылочной целостности.Вы можете увидеть разницу, создав первичный ключ для таблицы Customers в примере, который мы используем:

Обратите внимание, что оператор добавляет ограничение , а не индекс . Он добавляет именно такое ограничение в столбец CustomerID.Теперь, когда у нас уже есть как кластеризованный, так и некластеризованный индекс, это дает интересный результат. В обозревателе объектов SSMS теперь мы видим три индекса !

Новый был создан как вспомогательный индекс для реализации ограничения. Обратите внимание, что это некластеризованный. Если вы думали, что первичные ключи должны быть кластеризованными индексами, подумайте еще раз. Интересно, что SQL Server не распознал, что уже существует покрывающий кластерный индекс, и не использовал его.Я подозреваю, что построение индексов так, как мы это делаем здесь, хорошо для инструкций, но не оптимально для правильного проектирования, поэтому команда разработчиков SQL Server еще не работала над этим пограничным случаем и, возможно, никогда не сделает этого.

До того, как мы добавили ограничение первичного ключа, было возможно и допустимо добавлять новых клиентов с теми же идентификаторами клиентов, что и у существующих клиентов. Давай, попробуй! Однако теперь, когда ПК установлен, это больше невозможно.

Хотя может быть только один первичный ключ , могут быть и другие ключи, если другие комбинации столбцов действительно уникальны.При их создании используется аналогичный синтаксис:

Эта операция создает уникальное ограничение , а также добавляет индекс поддержки:

Первичные ключи необходимы, чтобы таблица соответствовала теории отношений.На практике они очень полезны (как и уникальные ключи) для ссылочной целостности и являются хорошим способом заставить базу данных проверять ваши предположения о входящих данных.

Вопрос 8: Должен ли мой первичный ключ также быть ключом кластеризованного индекса?

По умолчанию SQL Server создает кластерный индекс при создании новой таблицы с первичным ключом:

Эта команда создает ключ, подкрепленный кластеризованным индексом (с именем, предоставленным системой):

Однако то, что это действие по умолчанию, не означает, что это всегда лучший выбор.Хотя первичный ключ должен поддерживаться индексом для реализации ограничения, индекс не нужно кластеризовать, как мы видели выше. Более того, цели первичных ключей и кластеризованных индексов могут не совпадать.

По сути, ограничение первичного ключа позволяет SQL Server поддерживать то важное свойство, что таблица не может иметь повторяющихся строк. Фактически, уникальные ограничения делают то же самое. Поскольку они поддерживаются индексами, ключи также полезны для поиска, поскольку

1. Для любого ключа может быть только одна строка
2. Индекс позволяет использовать операцию поиска, которая обычно требует меньше операций ввода-вывода.

С другой стороны, кластеризованные индексы могут обеспечить преимущество в производительности при чтении таблицы в порядке индекса. Это позволяет SQL Server лучше использовать чтение с упреждающим чтением, которое асимптотически быстрее, чем постраничное чтение. Кроме того, кластерный индекс не требует уникальности. Если две или более строк имеют один и тот же ключ кластеризованного индекса, добавляется уникальность, чтобы гарантировать, что все строки в индексе являются уникальными.

Возвращаясь к нашей таблице клиентов, это совершенно правильная настройка индекса / ключа:

Здесь мы предполагаем, что большинство операций чтения выполняется по фамилии, имени (кластеризованный индекс) и что большинство поисков выполняется по идентификатору клиента (первичный ключ). (SQL Server добавит уникальный указатель к кластеризованному индексу, поскольку он не знает, будут ли конфликты ключей или нет.Здесь важно тщательно продумать, какое расположение лучше всего подходит для нового стола. Проконсультируйтесь с бизнес-пользователями о том, как будет использоваться таблица. Помните, что большинство отчетов носит последовательный характер. Выберите соответствующую индексацию, а затем проверьте ее. Используйте реальные рабочие нагрузки и посмотрите, соответствует ли фактическое использование схеме индексирования. Если нет, отрегулируйте его по своему усмотрению.

Вопрос 9: Что это за «отсутствующие индексы» в плане выполнения

Иногда в план выполнения включается сообщение об отсутствии индекса.Например, если я удалю индексы из таблицы Customer и попробую выполнить поиск по CustomerID, полученный план будет выглядеть следующим образом:

Текст, выделенный зеленым цветом выше, как раз и является таким сообщением. По сути, SQL Server говорит, что если бы в столбце CustomerID был индекс, стоимость всего запроса могла бы быть снижена на 99,8%! Это снизило бы стоимость почти до нуля. Вместо просмотра таблицы он может использовать операцию поиска по индексу.

Тогда возникает вопрос: следует ли всегда реализовывать отсутствующий индекс? Как это часто бывает, «как бывает!» это единственный верный ответ.Это годовой запрос, который выполняется без индекса за 10 минут? Возможно, вы можете оставить этот недостающий индекс в покое. Это запрос, который выполняется тысячи раз в секунду с загруженного сервера электронной коммерции? Возможно, вам стоит выполнить рекомендацию! Не думайте, что мама знает лучше! Перед тем, как что-либо делать, вам необходимо обдумать это и понять модели использования и стоимость индекса. Подумайте об этом…

Вопрос 10: Могу ли я иметь слишком много индексов?

На самом деле есть совет, гласящий, что вы должны просто проиндексировать каждый столбец в своей таблице, чтобы ни один план выполнения никогда не имел отсутствующего индекса.Это хороший совет? Опять же, это зависит от обстоятельств.

Базы данных хранилища данных часто имеют календарную таблицу. В этой таблице будет строка для каждой даты и столбцы для каждого возможного использования: MonthNumber, QuarterNumber, HalfYearNumber, MonthText, FullDateText, Is_Holiday, Is_BusinessDay и многие, многие другие. Такая таблица статична. Часто первичный ключ (и кластеризованный индекс) представляет собой целочисленный столбец или столбец даты с датой, соответствующей другим столбцам в строке. Эта таблица никогда (или редко) изменяется.Кроме того, он не слишком большой. (Сколько строк вам понадобится на столетие?) В такой таблице индексация каждого столбца может иметь смысл. Вы можете иметь отфильтрованные индексы для различных флагов, индексов по возрастанию и по убыванию, большинство из которых будут некластеризованными.

Теперь рассмотрим нашу таблицу клиентов. Если мы проиндексируем каждый столбец, что произойдет, когда мы добавим нового клиента?

Фактический план выполнения для этого:

Все эти индексы необходимо поддерживать! Эта работа может быстро накапливаться, поэтому, если у вас нет статической таблицы (например, календарной таблицы), индексация каждого столбца обычно является плохой идеей!

Сводка

Правильная индексация таблицы SQL Server является ключом к обеспечению стабильной и оптимальной производительности.При разработке структуры индекса необходимо учитывать множество факторов. Почти ни одно из этих соображений невозможно сделать без консультации с бизнес-пользователями, которые понимают данные и то, как они будут использоваться, хотя вполне может оказаться, что после того, как новая таблица будет использоваться в течение некоторого времени, будут представлены другие параметры индексации. самих себя.

В этой статье сделана попытка ответить на некоторые из наиболее важных вопросов об индексировании в целом и, в частности, о том, как это делается в SQL Server.Однако на самом деле мы только поцарапали поверхность. Каждый вопрос, на который здесь дан ответ, может быть отдельной полной статьей или, возможно, серией статей! Кроме того, мы вообще не рассматривали другие типы индексов (например, XML-индексы) и не рассматривали объекты в памяти и то, как они меняют картину для новых выпусков SQL Server.

Следите за обновлениями, чтобы увидеть более подробные статьи об индексировании SQL Server.

проекты /  идентификатор проекта  / базы данных / (по умолчанию) / операции / ASA1MTAwNDQxNAgadGx1YWZlZAcSeWx0aGdpbi1zYm9qLW5pbWRhEgopEg
 

список операций gcloud firestore
 

Описание операций gcloud firestore  имя-операции  

{
  "операции": [
    {
      «имя»: «проекты /  идентификатор проекта  / операции / AyAyMDBiM2U5NTgwZDAtZGIyYi0zYjc0LTIzYWEtZjg1ZGdWFmZWQHEjF0c2Flc3UtcmV4ZWRuaS1uaWIkY»
      "метаданные": {
        "@type": "тип.googleapis.com/google.firestore.admin.v1.IndexOperationMetadata ",
        "общий": {
          "operationType": "CREATE_INDEX",
          "startTime": "2020-06-23T16: 52: 25.697539Z",
          "состояние": "ОБРАБОТКА"
        },
        "progressDocuments": {
          "workCompleted": "219327",
          "workEstimated": "2198182"
        }
       },
    },
    ...
 

 PUT / my-index-000001
{
  "настройки": {
    "показатель": {
      "number_of_shards": 3, 
      "number_of_replicas": 2 
    }
  }
} 

 PUT / my-index-000001
{
  "настройки": {
    "number_of_shards": 3,
    «количество_реплик»: 2
  }
} 

 PUT / тест
{
  "настройки": {
    "number_of_shards": 1
  },
  "mappings": {
    "характеристики": {
      "field1": {"type": "text"}
    }
  }
} 

 PUT / тест
{
  "псевдонимы": {
    "псевдоним_1": {},
    "alias_2": {
      "filter": {
        "term": {"user.id": "kimchy"}
      },
      "маршрутизация": "шард-1"
    }
  }
} 

 PUT / журналы
{
  "псевдонимы": {
    "<журналы_ {сейчас / M}>": {}
  }
} 

 {
  "подтверждено": правда,
  "shards_acknowledged": правда,
  "index": "журналы"
} 

 PUT / тест
{
 "настройки": {
 "index.