Что делать, если неправильно указан индекс, адрес или фамилия на посылке (письме)
Что делать, если неправильно указан индекс, адрес или фамилия получателя посылки или письма
Дата публикации: 25.01.2018
Верно указанный сопроводительный адрес и индекс почтового отправления является одной из гарантий того, что получатель посылки точно её получит в контрольные сроки, отведенные на доставку. В противном случае, если индекс или адрес получателя указаны неправильно, то вероятнее всего посылка задержится или вовсе не будет доставлена конечному адресату. И в данном случае перекладывать ответственность на сотрудников Почты России не стоит.
Необходимо правильно понимать схему пересылки почтовых отправлений: посылки и письма на территории России первоначально доставляются не по конкретному адресу получателя (город, улица, дом), а именно по индексу, который условно является адресом того или иного отделения почтовой связи (ОПС). Индекс необходим для облегчения сортировки корреспонденции, в том числе автоматической.
На самом первом этапе приёмки почтового отправления и первичной его обработки сотрудник почты не проверяет соответствие полного адреса и индекса. Максимум на что может обратить работник сортировочного пункта при ручной обработке — это на несоответствие индекса ОПС и города, в котором это ОПС должно находиться. В этом случае посылка вероятнее всего сразу же будет возвращена отправителю.
Ниже рассмотрим каждый случай в отдельности и попробуем разобраться, что делать, если неправильно указали индекс или адрес. Дойдет ли посылка в этом случае? А также разберем момент, когда неверно указаны фамилия или имя получателя.
Указан неправильный индекс или в индексе допущена ошибка. Дойдет ли посылка?
Пожалуй, самой распространенной ошибкой при заполнении сопроводительного адреса к посылке или письму является неправильный индекс. Индекс, о чем я уже говорил выше, является условным цифровым адресом отделения почтовой связи, куда должна быть направлена посылка. Если ошибка в индексе не была выявлена на первоначальных этапах обработки и сортировки почтового отправления, то посылка (письмо) будет направленно именно в то ОПС, индекс которого ошибочно указал отправитель. А уже в конечном отделении почтовой связи, куда прибудет отправление, если будет выявлено, что адрес получателя не попадает в зону обслуживания этого отделения – будет произведен досыл посылки. Досыл производится в отделение, которое обслуживает адрес (дом) получателя.
Основное, что теряет получатель, если был неправильно указан индекс – это время. То есть посылка до адресата дойдет гораздо позже, чем это было бы при благоприятных условиях. И следует понимать, что досылка посылки из соседнего ОПС будет произведена гораздо быстрее, чем из отделения другого города.
Правда, иногда посылка может остаться дожидаться своего получателя в почтовом отделении по индексу, то есть досыл не производится!
Если индекс не был указан совсем, а такое может случиться, для примера, с простым письмом, то обработка такого почтового отправления производится вручную. Корреспонденция при этом направляется по адресу.
Стоит понимать, что на деле не всегда всё происходит так, как описано выше. В любой момент на каком-то этапе обработки ваше почтовое отправление может быть возвращено назад отправителю. Поэтому зная точно, что на посылке индекс написан с ошибкой, старайтесь отслеживать отправление по трек-номеру и действовать уже по ситуации.
Указан неправильный адрес или в адресе (улица, дом, квартира) допущена ошибка.
В данном случае возможны три варианта ошибок:
- В адресе, то есть в названии города, района, улицы/проспекта/переулка допущена лишь опечатка или орфографическая ошибка.
- Если какая-то часть адреса написана неразборчиво или вовсе не указана
- Адрес указан с ошибкой (указана не та улица, дом или квартира).
В первом случае, вероятнее всего проблем вообще быть не должно. На почте работают люди, которые хорошо знакомы с обслуживаемой ими территорией. Поэтому если в адресе есть какая-то опечатка, то им несложно будет догадаться, куда в конечном итоге следует доставить письмо или посылку.
Во втором случае, если сотрудник почты не сможет разобрать, номер дома или квартиры, а в некоторых случаях название улицы – посылка скорее всего останется дожидаться получателя в почтовом отделении. Храниться почтовое отправление будет в течение 15-30 дней (зависит от вида отправления), а потом будет отправлено обратно. В данном случае главным помощником получателя будет служить трек-номер, с помощью которого можно отслеживать отправление. Статус посылки при этом скорее всего будет «Прибыло в место вручения».
Иногда отправление может быть возвращено отправителю с пометкой
Если на посылке неразборчиво написан номер квартиры, почтальоны иногда импровизируют: извещение о посылке опускают ни в чей-то конкретный ящик, а кладут на подоконник или в другое видное место в подъезде.
Третий вариант наиболее сложный. Ведь если указан хотя бы не тот номер квартиры, то посылка (мелкий пакет), извещение или письмо может быть опущено в чужой почтовый ящик. Вины почтальона в этом случае не будет. Поэтому и в данном случае стоит «вооружаться» номером почтового идентификатора посылки и постоянно ее отслеживать. После прибытия ее в отделение почтовой связи, нужно сразу идти на почту и объяснять всю ситуацию сотруднику. На почте работают обычные нормальные люди, поэтому вероятнее всего свою посылку вы получите. В противном случае отправителю необходимо будет идти на свою почту с чеком и паспортом и писать
Указана неправильно фамилия (фамилия или имя написаны с ошибкой)
Случаи, когда в фамилии или имени получателя допущена ошибка, нередки. Могут быть варианты, как и с адресом, когда присутствует лишь какая-то несущественная опечатка (пропущена буква или вместо одной буквы написана другая) или фамилия (имя) полностью указана иная.
В первом варианте посылка вероятнее всего будет выдана.
Во втором случае по правилам сотрудник Почты России не должен выдавать посылку, хотя естественно с работником можно попробовать договориться. При этом шанс договориться будет гораздо выше, если адрес вашей прописки совпадает с адресом, указанным на посылке. Но естественно и совпадение адресов не является гарантией того, что вы получите свою посылку. Ведь по правилам отправление выдается только тому человеку, кому оно действительно предназначается.
Если договориться не получается, то отправитель посылки должен написать заявление о том, что на посылке указал неправильную фамилию (имя).
Мне лично удавалось получить денежный перевод на довольно-таки приличную сумму, когда в сопровождении к переводу не был вообще указан адрес, а моя фамилия была написана без имени и в женском роде (не Иванов, а Иванова). Об этом случае можно почитать в самом конце статьи: «Не приходит наложенный платеж«.
Буду благодарен, если в комментариях ниже будете делиться случаями из своей жизни, когда на ваших посылках или письмах был неправильно указан индекс, адрес или фамилия. Доходила ли посылка в этих случаях, отдавали ее вам работники почты?
Похожие статьи:
На посылке указан неверный индекс. Дойдет ли посылка до адресата?
Подскажите, какие могут быть перспективы у покупки у которой неверно указан индекс.Сейчас она трекнулась на импорте в Москве, и идёт вероятно в Дзержинск (город нашей области), а нужно в Нижний Новгород. Не сталкивались ли вы с таким?
===================
Добавлено модератором:
- При отправке посылки указал не правильный индекс. Что делать?
- Неверный индекс на международной посылке. Получу ли я такую посылку?
При отправке посылки указал не правильный индекс. Что делать?
Индекс – важная составляющая почтового адреса получателя, по которому осуществляется доставка посылки. Он представляет собой код почтового отделения, использование которого существенно облегчает и ускоряет сортировку почтовой корреспонденции по территориальному признаку. Именно по этой причине сортировка отправлений осуществляется именно по индексу, а не по конкретному адресу получателя.Случаи, когда при отправлении посылки указывается неверный индекс встречаются довольно часто. Именно по этой причине почта России предусмотрела возможность внесения изменений в почтовые реквизиты (индекс, адрес, ФИО получателя) после отправки посылки. Все, что для этого нужно — написать соответствующее заявление (на специальном бланке почты России или в свободной форме) и оплатить услугу. Вместе с заявлением и квитанцией об оплате услуги по изменению данных, необходимо предоставить чек об отправке отправления реквизиты которого требуется изменить, а также сведения о его получателе, указанные при отправке посылки. После получения этих данных, изменения в почтовые реквизиты отправления будут внесены в течение 5-7 дней.
Неверный индекс на международной посылке. Получу ли я такую посылку?
Как была написано выше, индекс – кодовое обозначение почтового отделения, обслуживающего определенный район или целый населенный пункт. После сортировки, отправления направляются в почтовые отделения именно в соответствии с индексом, а потом уже распределяются работниками почты по конкретным адресам. Если индекс указан неверно, то и направится посылка не туда, куда нужно. Однако ничего страшного в этом нет, такое отправление тоже можно получить.Если посылка была отправлена с треком и отслеживается на всем пути следования, необходимо дождаться появления записи о том, что отправление прибыло в почтовое отделение и готово к вручению. Там его и можно будет получить, предъявив паспорт. К сожалению, воспользоваться таким вариантом решения проблемы можно не всегда. Актуально оно лишь в тех случаях, когда почтовое отделение, в которое прибыла посылка, находится недалеко от места вашего пребывания.
Если же посылка прибыла, к примеру, в другой город – можно попробовать дозвониться до почтового отделения и объяснить сложившуюся ситуацию сотрудникам по телефону. Не исключено, что такой звонок существенно ускорит пересылку посылки в нужное отделение в соответствии с указанным на ней адресом.
Все это актуально в тех случаях, когда отправление отслеживается. Но даже если отследить посылку нельзя (нет трека), после поступления отправления в почтовое отделение сотрудники заметят расхождение между индексом и адресом получателя. В таких случаях они должны перенаправить посылку по нужному адресу, изменив индекс. Вопрос лишь в том, сколько это займет времени и как быстро будет проведена данная процедура.
Почтовый индекс в алиэкспресс — что такое, как узнать, что делать если неправильно указал
Ответ:
Здравствуйте, Владимир! При регистрации на сайте и оформлением первого заказа, пользователи сталкиваются с таким пунктом, как указание контактных данных и адреса покупателя.
Что такое почтовый индекс в алиэкспресс?
Данный параметр используется для более быстрого доставления посылок с алиэкспресс. Он ничем не отличается от общепринятых норм в Российской Федерации. Почтовый индекс — это номер отделения почты, к которому привязан адрес фактического нахождения адресата. Состоит от из 6 цифр.
Как узнать почтовый индекс для алиэкспресс?
Выяснить номер своего отделения почты России не сложно. Есть несколько способов.
!Обратите внимание — указывать стоит индекс того почтового отделения, которое привязано к вашему фактический адресу пребывания. Ведь именно в этот офис и прибудет посылка.
- Первый и самый достоверный способ — это зайти на сайт Почты и следовать приложенным инструкциям. Поиск отделений можно осуществить тут: https://www.pochta.ru/offices
- Второй способ более быстрый и простой. Заходим в поисковую систему Яндекс и вбиваем в поисковой строке адрес +индекс. Верхняя строка будет ответом.
Неправильно указан индекс на алиэкспресс
Как уже было отмечено выше — к заполнению поля индекс нужно подходить очень ответственно. Это основной показатель адреса, по которому пойдет посылка. Даже если адрес, указанный в строке и индекс не совпадают — служба доставки отправит бандероль в соответствии с индексом. В принципе местонахождения дома получателя указывается только для почтальона.
Что делать?
Можно попробовать связаться с тем отделением почты, которое вы указали при заполнении данных. По прибытию посылки к ним — они перенаправят ее.
Так как обычно, допускаются ошибки в 1 или 2 цифрах индекса, то заказ идет в другое отделение внутри населенного пункта. Уже на месте сотрудники понимают ошибку и перенаправляют бандероль в правильное место. Единственный минус — это срок доставки, он увеличивается.
Видео по теме
Онлайн оформление посылок, часто задаваемые вопросы
В каких отделениях Почты России можно сдать посылку, оформленную на портале pochta.ru?
Посылку можно сдать в любом отделении Почты России. Найти ближайшее к вам отделение можно здесь.
Я оформил и оплатил посылку на портале и пришел в отделение. Как сдать посылку без очереди, если в зале всегда находятся клиенты?
В отделении вы увидите объявление «Оставь посылку на стойке оператора без очереди». Подходите к этому объявлению и говорите, что у вас оформленная и оплаченная на портале посылка. Оператор увидит вас, подойдет и заберет вашу посылку.Я не знаю точный вес посылки. Что делать?
Все принимаемые посылки будут взвешиваться оператором для указания точного веса. Если полученный вес окажется меньше, чем был введен и оплачен на портале, то с вашей карты будет списана меньшая сумма, а оставшаяся будет разблокирована. Если же полученный вес будет больше введенного и оплаченного, то произойдет списание недостающей суммы с вашей карты.В какой момент времени с меня списываются деньги?
В момент оформления и оплаты на портале на вашей карточке будет авторизована (заморожена) сумма, соответствующая указанному весу. Окончательная сумма будет определена оператором при взвешивании. Эту сумму вы увидите в своём интернет-банке, когда пройдёт операция клиринга, обычно это занимает от 2 до 5 дней.Как я узнаю, что моя посылка, оставленная в отделении, была принята?
Вам на электронную почту придет письмо с уведомлением о приеме и чеком или же отказом в приеме с указанием причины. В таком случае вы должны забрать посылку из отделения не позднее 10 дней с момента получения отказа.Я сдал посылку в отделении, но на электронную почту ничего не пришло. Прошло более 12-ти часов с момента сдачи. В чем причина?
Нужно позвонить в отделение, в который вы сдавали посылку, назвать трек-номер (он находится на бланке, который вы распечатали на портале) и узнать статус.Я сдал посылку в отделении, но на мой адрес электронной почты поступил отказ в приеме, что мне делать?
Необходимо вернуться в отделение и уточнить причину отказа. Вы можете забрать посылку и заново зарегистрировать ее на портале с печатью нового бланка или воспользоваться любой иной услугой через оператора отделения.Я оформил и оплатил посылку на портале и сдал ее через 5 дней с момента регистрации, но мне пришел отказ из отделения в приеме по причине того, что посылка не оплачена. В чем причина?
Такое может быть в том случае, если истек лимит времени на блокировку денежных средств. Лимит по блокировке устанавливается банком, выпустившим вашу карту. В среднем длительность блокировки банками устанавливается от 3-х дней. Поэтому, мы рекомендуем сдавать посылку не позднее 72-х часов с момента оплаты посылки на портале. В данном случае вы забираете посылку и можете ее отправить через оператора отделения воспользовавшись одной из стандартных услуг. Разблокированная сумма не будет списана с вашего счета.Для получения доступа к порталу, при регистрации, запрашивается ввод адреса. Какой необходимо указать адрес?
При регистрации адрес — это необязательное поле. Указывайте адрес вашего фактического местонахождения или проживания. В момент регистрации посылки вы повторно укажите адрес отправления. Он может отличаться от того, который вы ввели при регистрации на портале.Я хочу зарегистрировать несколько посылок и оплатить их все сразу. Как это можно сделать?
На сегодняшний день вы регистрируете и оплачиваете каждую отдельную посылку.Какой вид посылки я могу оформить и оплатить на портале?
На портале вы можете оформить и оплатить обычную посылку и ускоренную посылку 1 класса по территории России.Какие могут быть максимальные размеры и вес посылки для пересылки по данному сервису?
Обычную посылку вы можете отправить весом до 10 кг, в упаковке, сумма длины, ширины и высоты которой не превышает 120 см, а любая из сторон не должна превышать 60 см. Негабаритную посылку можно отправить весом не более 20 кг, сумма измерения всех сторон упаковки менее 300 см. Посылку 1 класса – весом до 5 кг, в упаковке, сумма длины, ширины и высоты которой не превышает 70 см, а любая из сторон не должна превышать 36 см.Я хочу оформить и оплатить посылку с курьерской доставкой, как это можно сделать?
Для этого вам нужно обратиться к оператору отделения, который расскажет об услугах и поможет подобрать оптимальный вариант для отправки. Также вы можете вызвать курьера на дом или в офис на сайте или в мобильном приложении.Как оплатить оформленную посылку?
Чтобы можно было оплатить посылку онлайн необходимо выбирать введенные значения из выпадающего списка в следующих заполняемых полях – город отправителя, город получателя, вес, адрес отправителя, адрес получателя. Это необходимо для проверки корректности введенных данных. Если кнопка «Оплатить» так и не появилась, свяжитесь с нами по адресу [email protected].
В почтовом извещении неправильно указана фамилия. Что делать, если неправильно указан индекс, адрес или фамилия получателя посылки или письма. Например, вот так
Дата публикации: 25.01.2018
Верно указанный сопроводительный адрес и индекс почтового отправления является одной из гарантий того, что получатель посылки точно её получит в контрольные сроки, отведенные на доставку. В противном случае, если индекс или адрес получателя указаны неправильно, то вероятнее всего посылка задержится или вовсе не будет доставлена конечному адресату. И в данном случае перекладывать ответственность на сотрудников Почты России не стоит.
Необходимо правильно понимать схему пересылки почтовых отправлений: посылки и письма на территории России первоначально доставляются не по конкретному адресу получателя (город, улица, дом), а именно по индексу, который условно является адресом того или иного отделения почтовой связи (ОПС). Индекс необходим для облегчения сортировки корреспонденции, в том числе автоматической.
На самом первом этапе приёмки почтового отправления и первичной его обработки сотрудник почты не проверяет соответствие полного адреса и индекса. Максимум на что может обратить работник сортировочного пункта при ручной обработке — это на несоответствие индекса ОПС и города, в котором это ОПС должно находиться. В этом случае посылка вероятнее всего сразу же будет возвращена отправителю.
Ниже рассмотрим каждый случай в отдельности и попробуем разобраться, что делать, если неправильно указали индекс или адрес. Дойдет ли посылка в этом случае? А также разберем момент, когда неверно указаны фамилия или имя получателя.
Указан неправильный индекс или в индексе допущена ошибка. Дойдет ли посылка?
Пожалуй, самой распространенной ошибкой при заполнении сопроводительного адреса к посылке или письму является неправильный индекс. Индекс, о чем я уже говорил выше, является условным цифровым адресом отделения почтовой связи, куда должна быть направлена посылка. Если ошибка в индексе не была выявлена на первоначальных этапах обработки и сортировки почтового отправления, то посылка (письмо) будет направленно именно в то ОПС, индекс которого ошибочно указал отправитель. А уже в конечном отделении почтовой связи, куда прибудет отправление, если будет выявлено, что адрес получателя не попадает в зону обслуживания этого отделения – будет произведен досыл посылки. Досыл производится в отделение, которое обслуживает адрес (дом) получателя.
Основное, что теряет получатель, если был неправильно указан индекс – это время. То есть посылка до адресата дойдет гораздо позже, чем это было бы при благоприятных условиях. И следует понимать, что досылка посылки из соседнего ОПС будет произведена гораздо быстрее, чем из отделения другого города.
Правда, иногда посылка может остаться дожидаться своего получателя в почтовом отделении по индексу, то есть досыл не производится!
Если индекс не был указан совсем, а такое может случиться, для примера, с простым письмом, то обработка такого почтового отправления производится вручную. Корреспонденция при этом направляется по адресу.
Стоит понимать, что на деле не всегда всё происходит так, как описано выше. В любой момент на каком-то этапе обработки ваше почтовое отправление может быть возвращено назад отправителю. Поэтому зная точно, что на посылке индекс написан с ошибкой, старайтесь отслеживать отправление по и действовать уже по ситуации.
Указан неправильный адрес или в адресе (улица, дом, квартира) допущена ошибка.
В данном случае возможны три варианта ошибок:
- В адресе, то есть в названии города, района, улицы/проспекта/переулка допущена лишь опечатка или орфографическая ошибка.
- Если какая-то часть адреса написана неразборчиво или вовсе не указана
- Адрес указан с ошибкой (указана не та улица, дом или квартира).
В первом случае, вероятнее всего проблем вообще быть не должно. На почте работают люди, которые хорошо знакомы с обслуживаемой ими территорией. Поэтому если в адресе есть какая-то опечатка, то им несложно будет догадаться, куда в конечном итоге следует доставить письмо или посылку.
Во втором случае, если сотрудник почты не сможет разобрать, номер дома или квартиры, а в некоторых случаях название улицы – посылка скорее всего останется дожидаться получателя в почтовом отделении. Храниться почтовое отправление будет в течение 15-30 дней (зависит от вида отправления), а потом будет отправлено обратно. В данном случае главным помощником получателя будет служить трек-номер, с помощью которого можно отслеживать отправление. Статус посылки при этом скорее всего будет «Прибыло в место вручения» .
Иногда отправление может быть возвращено отправителю с пометкой «Неполный адрес» .
Если на посылке неразборчиво написан номер квартиры, почтальоны иногда импровизируют: извещение о посылке опускают ни в чей-то конкретный ящик, а кладут на подоконник или в другое видное место в подъезде.
Третий вариант наиболее сложный. Ведь если указан хотя бы не тот номер квартиры, то посылка (мелкий пакет), извещение или письмо может быть опущено в чужой почтовый ящик. Вины почтальона в этом случае не будет. Поэтому и в данном случае стоит «вооружаться» номером почтового идентификатора посылки и постоянно ее отслеживать. После прибытия ее в отделение почтовой связи, нужно сразу идти на почту и объяснять всю ситуацию сотруднику. На почте работают обычные нормальные люди, поэтому вероятнее всего свою посылку вы получите. В противном случае отправителю необходимо будет идти на свою почту с чеком и паспортом и писать заявление на изменение данных адресата .
Указана неправильно фамилия (фамилия или имя написаны с ошибкой)
Случаи, когда в фамилии или имени получателя допущена ошибка, нередки. Могут быть варианты, как и с адресом, когда присутствует лишь какая-то несущественная опечатка (пропущена буква или вместо одной буквы написана другая) или фамилия (имя) полностью указана иная.
В первом варианте посылка вероятнее всего будет выдана.
Во втором случае по правилам сотрудник Почты России не должен выдавать посылку, хотя естественно с работником можно попробовать договориться. При этом шанс договориться будет гораздо выше, если адрес вашей прописки совпадает с адресом, указанным на посылке. Но естественно и совпадение адресов не является гарантией того, что вы получите свою посылку. Ведь по правилам отправление выдается только тому человеку, кому оно действительно предназначается.
Если договориться не получается, то отправитель посылки должен написать заявление о том, что на посылке указал неправильную фамилию (имя).
Мне лично удавалось получить денежный перевод на довольно-таки приличную сумму, когда в сопровождении к переводу не был вообще указан адрес, а моя фамилия была написана без имени и в женском роде (не Иванов, а Иванова). Об этом случае можно почитать в самом конце статьи: « «.
Буду благодарен, если в комментариях ниже будете делиться случаями из своей жизни, когда на ваших посылках или письмах был неправильно указан индекс, адрес или фамилия. Доходила ли посылка в этих случаях, отдавали ее вам работники почты?
Почта России неожиданно серьезно осложнила и без того нелегкую жизнь получателем международных отправлений. Оказывается, с февраля на всех без исключения почтовых отправлениях, получаемых россиянами, должно присутствовать полное ФИО, включая отчество. Проще говоря — если в паспорте у вас есть отчество, то и на посылке оно должно присутствовать, иначе получить его вы не сможете.
Все нормально, посылки без отчества получать можно. Информация — в обновлении в конце топика.
Такая практика уже около года действует для отправлений, отправляемых внутри страны — без указания полного ФИО отправление не принимали к пересылке, но сейчас такие правила стали действовать и в отношении международных малых пакетов.
К сожалению, мне не удалось пока получить номер приказа, который устанавливает эти правила, но в наличии правил может убедиться каждый — позвонив на горячую линию почты России(8-800-2005-888).
А что делать? Изменить во всех своих адресах свое ФИО на полное. И само-собой, предупреждать всех продавцов, с которым имеете дело, о обязательном указании отчества.
Например, вот так
The Russian Post now requires full recipient’s name to be stated on a parcel – first name, middle name, last name. Therefore, can you please clearly indicate my full name on the parcel as follows: “Ivan Ivanovich Ivanov”. If any of the full name parts is omitted, the parcel will return to the country of origin.
А что делать, если вам уже идет посылка?
Вариант номер 1 — пойти на почту и попытаться убедить операторов в том, что изменить адрес затруднительно. Возможно, приказ до них еще не дошел, или они не обращают пока на него внимания.
Вариант номер 2, рекомендованный горячей линией — отправитель посылки должен на своей почте заполнить бланк заявления о смене адреса — форма CN17. В нем следует указать изменение имени получателя, и добавить к нему отчество.
Форма CN17:
Следует заметить, что некоторая часть китайских магазинов и площадок уже осведомлены о проблемах, и рекомендуют указывать полное ФИО:
Что делать если посылку отправли с ошибкой в фамилии?
Была у меня такая ситуация, отправитель допустил аж 3 ошибки. Я пришл в отделение Новой почты, показал паспорт и мне сказали что в декларации совершено другая фамилия. Так и не смог забрать посылку, пришлось звонить отправителю, они исправили ошибки и лишь потом я забрал посылку. Как мне сказали сотрудники, по их правилам допускается только лишь 2 ошибки в фамилии и инициалах. Так что если одна или две ошибки то идите смело и забирайте свою посылку. Для подстраховки, чтобы не бегать, можно им прозвонить.
У меня тоже была такая ситуация, когда посылку отправили с ошибкой. Пришлось звонить отправителю. Также есть различия ошибки на посылке или на почте при приеме посылке, поэтому все надо предварительно проверять перед отправкой. На почте надо объяснить ситуацию и связаться с отправителем.
Была такая ситуация совсем недавно. Отправитель опечатался в фамилии, одну букву пропустил (Сахбиева, вместо Сахабиева написал), на почте все таки выдали после нескольких раздраженных вздохов и ахов. Если ошибки незначительные, то посылкузаказное письмо вам выдадут, не переживайте!
У меня посылка шла из Китая, как оказалось в данных была ошибка в фамилии, но вс остальное правильно. Пришло извещение с ошибкой в фамилии и я боялась что мне не выдадут посылку, но на почте оператор посмотрела мой паспорт, а там ведь указана прописка и на посылке был указан мой номер мобильного телефона, поэтому она мне отдала посылку.
Если ошибка не слишком большая, например перепутана одна буква в фамилии или номер дома, то вполне возможно, что вам все же отдадут.
В большинстве своем тут не случается проблем, ну только если почтовый служащий адекватный.
Если не отдают, вам необходимо связаться с отправителем и попросить его написать заявление с исправленными ошибками.
Так чья именно ошибка? Отправителя или почты? На почте неправильно напечатали извещение или отправитель неправильно написал на посылке?
Есть разница.
И еще, если вы придете с паспортом и этим извещением, то может и выдадут без дополнительных действий с вашей стороны. Особенно если ошибка незначительная. Например, одна буква перепутана. Ну и если ваш адрес соответствует с указанным на извещении.
Если же не выдают, то отправитель должен идти в отделение, где отправлял посылку и сообщить, что ошибся, там много способов это исправить. Смотря от конкретной ситуации все зависит.
Случается такое, что отправитель посылки не правильно пишет имя или фамилию, допускает ошибку. Особенно это часто случается в посылках из Китая. Было дело, прислали посылку с ошибкой, но посылку мою мне отдали, ведь адрес был верный и инициалы тоже.
Вообще если есть ошибка, то оператор на почте может и не выдать посылку. В этом случае необходимо чтобы человек, отправивший посылку обратился в почтовое отделение, где была отправлена посылка и сообщил об этом.
Сегодня Вы узнаете, что делать в такой ситуации: Я допустил ошибку, когда заполнял адрес доставки в зарубежном интернет магазине. Придет ли моя посылка?
Сразу скажу, что это довольно обширный вопрос. Здесь главную роль играют сами сотрудники почты и то, в каком конкретно месте адреса была допущена ошибка.
Пока посылка находится в пути, она проходит через огромное количество сортировочных пунктов. Сотрудники почты, опираясь на данные, указанные на посылке, определяют, куда именно отправится Ваш заказ.
Если адрес будет написан с ошибкой, одни сотрудники почты, не разбираясь в проблеме, просто ставят пометку «Несоответствие адреса» и посылка отправляется отправителю (продавцу) обратно. Другие почтовики с большей человечностью относятся к своей работе – они постараются разобраться в сложившейся проблеме и отправить посылку по нужному адресу.
Ниже я разобрал несколько случаев написания ошибочного адреса и то, как на это могут отреагировать работники почты :
Неправильный индекс (ошибка в индексе)
Зачастую посылки с ошибочным и несуществующим индексом получают статус «Без индекса» и отправляются по тому адресу, который был указан на посылке (т.е. отправится к Вам). Иногда бывает и по-другому – посылку возвращают отправителю (продавцу).
Если указан ошибочный, но существующий почтовый индекс — посылка может отправиться по указанному (ошибочному) индексу. Попав не в то отделение ПОЧТЫ РОССИИ, посылка досылается уже на Ваш адрес.
Бывает так, что досыла не производится и посылка получает статус «Прибыло в место вручения». Тогда уже стоит насторожиться и своими силами (например, по телефону) добиться того, чтобы посылку перенаправили в Ваше почтовое отделение.
Как же определить, где в данный момент находится посылка, и какой статус она имеет («Прибыло в место вручения» или «Без индекса»)?! – Все просто. Нужно отслеживать посылку по трек-номеру. Если трек-номера нет, тогда печаль-беда и вмешаться в судьбу посылки Вам не суждено. Все будет зависеть от работников ПОЧТЫ РОССИИ.
Ошибка в названии улицы/проспекта/проезда/переулка
Если допущена банальная опечатка, ничего страшного нет. Работники почты разберутся в сложившейся проблеме и бросят извещение о пришедшей посылке в Ваш почтовый ящик.
Если прочесть название улицы будет невозможно, тогда посылка останется в стенах почтового отделения – здесь ее будут хранить в течение 30 дней. Пока посылка находится в статусе «Прибыло в место вручения» (это отслеживается по трек-номеру), Вы можете смело брать паспорт и бежать на почту без извещения и требовать выдать посылку. Запомните, если посылка с товаром пролежит на почте более 30 дней, она уедет обратно к продавцу.
Если Вы не знаете трека, тогда придется периодически заглядывать на почту с коробкой конфет или шоколадкой, чтобы почтальон поискал посылки, которые пришли на Ваши ФИО. А делать они это без трек-номера ой как не любят!
Написан не тот номер квартиры/дома (либо совсем не указан)
В этом случае, скорее всего, посылка будет ждать Вас в течение 30 дней на почте. Хотя, если у Вас маленький городок/село/деревня, где все друг друга знают, то почтальон отыщет нужный почтовый ящик и бросит туда извещение. Так же он может во время очередного обхода просто постучаться в дверь, чтобы уж наверняка удостовериться, что посылка полагается именно Вам.
Если извещения Вы не получили, а по трек-номеру у посылки уже давно статус «Прибыло в место вручения», смело бегите на почту – Вас там ждут!
Ошибка в имени или фамилии
Если не указано имя или фамилия, либо в них допущена опечатка (буквы перепутали, не дописали), но адрес на посылке все же сходится с адресом приписки (тот, что в паспорте), то Вам отдадут посылку без всяких возмущений. А вот, если Вас зовут Игорь, а посылка пришла на Максима – посылку не отдадут. Аналогичная ситуация и с фамилией – посылка, пришедшая Сидорову, не будет отдана Иванову.
Не написано отчество
Указывать отчество в адресе доставки не обязательно. Отсутствие отчества не является причиной для отказа в выдаче посылки. Запомните это раз и навсегда!
Стоит отметить, что на самой популярной торговой интернет площадке Китая AliExpress при заполнении адреса доставки предупреждают, что ПОЧТА РОССИИ в обязательном порядке требует отчество – ЭТО ВСЕ БРЕД! НЕ ОБРАЩАЙТЕ ВНИМАНИЯ! Есть официальное опровержение ПОЧТЫ РОССИИ, поэтому шлите всех лесом.
Ошибка в названии области, района, города, села и т.д.
Ошибки в названиях областей, районов, городов, республик и т.д. не критичны. Главное, чтобы почтовый индекс был указан правильно. По его коду соответствующие государственные органы легко определяют, в какое почтовое отделение должна придти посылка.
Еще вопросы остались? Если – да, то задавайте их в комментариях ниже!
Как решить проблему с вводом индекса в Android Pay
В платёжном сервисе Google Play присутствует специфичный для России баг с почтовыми индексами. Он хорошо знаком некоторым пользователям других сервисов Google, в том числе AdSense.
Дело в том, что хотя Google и знает индексы почтовых отделений во всех населённых пунктах России, но не до конца понимает такой термин, как «город федерального значения» и требует указать область, к которой он относится. У жителей Москвы и Санкт-Петербурга при попытке ввода индекса своего почтового отделения появляется сообщение об ошибке. Скриншоты в Android Pay делать нельзя, поэтому не удивляйтесь, что статья проиллюстрирована фотографиями.
Территориально город федерального значения находится внутри области, но у него особый пул индексов. При этом область имеет в приложении больший приоритет — именно это и приводит к ошибке. По какой-то причине Google не решает эту проблему уже несколько лет, однако существует два способа обойти её.
Первый способ: нужно указать в графе «Город» название своего города, затем ещё раз выбрать его в качестве области и ввести реальный индекс.
Второй способ: нужно указать в качестве города Москву или Санкт-Петербург, выбрать Московскую или Ленинградскую область и написать индекс любого областного города. Например, для Москвы подойдёт почтовое отделение 140500 в Луховицах, а для Санкт-Петербурга — 187111 в Киришах. Указание индекса — простая формальность и даже если Google решит отправить вам бумажное письмо, оно всё равно дойдёт до вашего настоящего адреса, просто его переадресуют из областного почтового отделения в то, что находится рядом с вашим домом.
Почтовый индекс 200983 отделение почты г. Санкт-Петербург
Адрес:
200983, Санкт-Петербург г Санкт-Петербург, Софийская улица, 81к1
Название:
Цех «Санкт-петербург аСЦ Цех посылок»Если почтовое отправление доставляется на это отделение почты, можно отследить посылку и узнать ее текущее местоположение, а также примерно рассчитать срок ее прибытия в место назначения.
Время работы почты
Работает- Ежедневно
круглосуточно
без перерыва
Написание индекса:
Вышестоящее отделение:
Услуги отделения:
Почтовые услуги универсальные
Почтовые услуги иные
Финансовые услуги
Розничные продажи
Услуги по подписке
Сетевые услуги
КиберПочт@
Горячая линия Почты России:
Email Почты России:
Телефон EMS Почта России:
Фотографии почты 200983
Почему (почти) все, что вы знаете об индексах базы данных, неверно
У разработчиков и администраторов баз данных есть множество вариантов настройки экземпляров баз данных SQL Server, когда возникают неизбежные проблемы с производительностью. Это может показаться нелогичным, но имеет смысл проверить, не используется ли у вас слишком много индексов . Прочтите, чтобы узнать почему. (И щелкните здесь, чтобы узнать, как справиться с окончанием срока службы SQL Server 2008 и SQL Server 2008 R2.)
Люди, как правило, используют свои индивидуальные подходы к настройке систем, обычно связанные с их основными сильными сторонами. Разработчики склонны настраивать код, с которым они работают: разработчики приложений в стеке приложений; разработчики баз данных с T-SQL и кодом хранимых процедур. Между тем, администраторы баз данных обычно сосредотачиваются на коде T-SQL, хранимых процедурах, и выигрывает «общая картина»: изменение и нормализация схемы, добавление индексов, использование проприетарных инструментов и функций той редакции SQL Server, к которой они обращаются (например, Resource Governor , OLTP в памяти и т. Д.), и, как и их коллеги-разработчики баз данных, код T-SQL. Наконец, есть инженеры инфраструктуры (и, неизбежно, руководство на уровнях, абстрагированных от повседневных тактических усилий), которые могут предложить «решить проблему аппаратным обеспечением» путем масштабирования памяти, ЦП или более быстрого хранилища, если это доступно через поставщиков облачных услуг.
Но есть ограничения
Однако эти возможности ограничены, когда вы работаете с комплексным решением, которое уже используется широкой публикой.Внести изменения в код сложно, и, если они правильно протестированы и выпущены, изменения кода не являются быстрым решением проблем с производительностью, которые необходимо исправить прямо сейчас .
Хотя обычно существует возможность «задействовать оборудование» для решения проблемы — особенно когда вы можете выполнять автоматическое масштабирование в облаке — вы в конечном итоге достигнете точки, когда это больше не будет жизнеспособным вариантом. Несмотря на то, что Microsoft хотела бы, чтобы это было так, не все развертывания SQL Server выполняются в Enterprise Edition.Многие из тех опций, которые существуют для подавления снижения производительности производства, отсутствуют в стандартной версии. Возможно, решение о развертывании Standard Edition было основано на стоимости, но часто это делается потому, что эти функции корпоративного класса не нужны, когда продукт планируется или выпускается. Существует множество решений и ситуаций, которые могут загнать вас в угол, когда дело доходит до вариантов настройки в кризисных ситуациях.
Пришло время сиять администраторам баз данных
Когда вы не можете быстро изменить код, не можете полагаться на функции Enterprise Edition и не можете масштабировать свое оборудование, бремя, как правило, ложится на администраторов баз данных.
Первым шагом администратора базы данных должно быть рассмотрение параметров уровня сервера или уровня базы данных, чтобы убедиться, что они установлены правильно. Например, проверьте параметры параллелизма, объем оперативной памяти, выделенной для SQL, по сравнению с остальными службами, работающими на сервере, наличие объема памяти, необходимого для нормальной работы операционной системы, параметры NUMA и т. Д. . Если что-то не установлено правильно, решение ситуации приводит к быстрому выигрышу.
Если это не сработает, пора обратиться к оптимизации, основанной на конкретной проблеме.
Что делать, если все плохо
Есть одна вещь, на которую я смотрю сразу (после настроек конфигурации), которая имеет тенденцию давать преимущества для таких проблем, как:
- Высокий процессор
- Чрезмерная блокировка
- Большое количество ключевых поисков
- Задержка ввода-вывода
- Общие проблемы «Моя база данных работает медленно»
Я смотрю на использование индекса, но не обязательно так, как вы ожидаете.Многие администраторы баз данных рассматривают добавление индексов как панацею от всех проблем с производительностью, особенно на уровне запросов / хранимых процедур. Я смотрю на противоположное: у нас слишком много индексов? Возможно, этот факт шокирует даже опытных администраторов баз данных. Многие люди утверждают, что индексы помогают ускорить процесс. Да, это правда, но они также имеют секретную цену: их нужно поддерживать. Я не имею в виду перестройку и реорганизацию индексов; я имею в виду накладные расходы на обновление этих индексов.
Видите ли, каждый раз, когда вы добавляете запись в таблицу с индексом на ней, должна выполняться операция не только для обновления самой таблицы, но и для обновления всех индексов, на которые эта вставка может повлиять. Эта необходимость поддерживать все затронутые индексы каждый раз при добавлении записи также необходима для любой другой операции, которая изменяет значение столбца или столбцов и связанных с ними индексов. И не забывайте об этих операциях удаления — то же самое касается и них. Каждая из этих операций считается индексной «записью».”
Прежде чем вы поймете, что я против индексов, давайте поговорим о преимуществах, которые они предоставляют: они заставляют определенные вещи происходить быстрее — обычно намного быстрее . Индексы существуют для быстрого обслуживания данных при правильном применении. Полезные индексы — это индексы, которые часто считываются, но редко записываются (обновляются) или читаются значительно чаще, чем обновляются. Индексы, которые редко — если вообще когда-либо — используются для выполнения операций чтения, но находятся в очень изменчивых столбцах, которые часто вставляются, обновляются или удаляются, являются плохим выбором для индексирования, которое на самом деле может принести гораздо больше вреда, чем пользы.
Допустим, у вас есть таблица, созданная для встреч с индексом assign_date. Вероятно, будет наблюдаться изрядное количество операций чтения и записи, но обычно дата встречи не меняется на уровне записи. Это не так уж и непостоянно, даже если на уровне таблицы вы видите много записей в этот индекс, потому что вы управляете успешной компанией, которая заказывает много встреч. Существует множество ситуаций, в которых будет выполняться поиск assign_date, что обычно приводит к гораздо большему, чем одно чтение.
И наоборот, индекс столбца date_modified для этой таблицы, специально созданный для инкрементной загрузки вашего хранилища данных, также будет обновляться каждый раз, когда в таблице создается новая строка, а также каждый раз, когда создается запись. измененный. Однако есть вероятность, что вы загружаете свое хранилище данных и используете индекс только один раз в день или даже реже. Для всех действий, кроме загрузки хранилища данных, этот индекс не будет полезен. Однако это будет чрезвычайно полезно для загрузки записей, измененных для определенного диапазона — критическая необходимость для инкрементной загрузки хранилища данных.Так будет с любым индексом, который приносит пользу лишь от случая к случаю.
К счастью, у нас есть способы узнать, насколько часто индексы используются и не используются. Я уже писал об этом некоторое время назад, и скрипты все еще актуальны. Я предлагаю вам прочитать основные сведения, которые можно получить из представления динамического управления статистикой использования, часть 1 и часть 2, чтобы получить представление о сценариях, используемых для определения неиспользуемых индексов.
Реальный мир, реальные выгоды
Недавно я был вовлечен в взаимодействие с клиентом, в ходе которого клиент загнал себя в угол, который я описал ранее.В течение многих лет компания увеличивала масштабы своего оборудования, когда сталкивалась с проблемами производительности баз данных в стандартной редакции SQL Server, пока не достигла точки, в которой не было места. Они не могли добавить ЦП из-за ограничения Standard Edition на 24 физических ядра. Клиент намного превысил объем оперативной памяти, который он мог использовать. Обновление SQL Server до Enterprise Edition было бы дорогостоящим решением и потребовало бы простоев, которые клиент не мог себе позволить.
Этот заказчик боролся с пиковой нагрузкой, которая находилась в кризисном состоянии: чрезвычайно большое время ожидания ресурсов ввода-вывода, дорогостоящий поиск ключей и высокая загрузка ЦП, связанная с трафиком, который был подготовлен специально для T-SQL.Сервер отставал и становился все более и более заблокированным по мере продолжения пикового трафика:
В то время как администратор баз данных клиента стремился добавить индексы для некоторых ключевых таблиц, чтобы помочь улучшить запросы, обращающиеся к специальному коду SQL, я применил другой подход: удалил все индексы, которые были в таблицах с наибольшим трафиком и чьи обновления мешает улучшить продолжительность и количество операций ввода-вывода для каждого запроса, поступающего в систему. Используя логику запросов в моих предыдущих статьях об использовании индекса, я смог сразу идентифицировать четырех кандидатов, которые я пометил как отключенные = 1 ниже:
Все эти индексы были сильно предвзяты в сторону того, чтобы они не использовались запросами пользователей, и, следовательно, существенно снижали производительность.Трое из четырех попали в описанную ранее проблему modified_datetime для своей группы хранилищ данных. У оставшегося индекса были явные признаки того, что он был создан непосредственно на основе отсутствующей подсказки индекса (с соглашением об именах DTA%, которое используется по умолчанию для подсказок индекса из объектов динамического управления отсутствующего индекса, которые также служат основой для Советник по настройке баз данных (также известный как DTA).
Я связался с командой хранилищ данных и обнаружил, что они не выполняют загрузку хранилища данных непосредственно в производственную базу данных; скорее, эта команда восстанавливает резервную копию предыдущего дня, а затем выполняет процесс инкрементной загрузки.Это объясняет отсутствие чтения по этим индексам. Между тем, все основные изменения индекса регистрировались. Обновление всех этих посторонних индексов увеличивало количество операций ввода-вывода и задержку в том, что уже было перегруженным экземпляром. Я даже подумал об отключении индекса, который я выделил красным выше, с 829K чтений, потому что при балансе с накладными расходами ввода-вывода для поддержания индекса (201M записей) эффективное количество чтений на запись по-прежнему было ошибкой округления.
Одно из самых сильных качеств любого специалиста по обработке данных — это способность сохранять спокойствие, когда он находится под давлением.Тысячи клиентов боролись с чрезвычайно медленным пользовательским интерфейсом, и каждая минута вела к появлению все большего количества неудобных клиентов. Для отключения индексов требуется монопольная блокировка схемы, и, учитывая объем происходящей нагрузки и блокировок, были некоторые стрессовые минуты, так как индивидуальный ALTER INDEX ON DISABLE; команды были поставлены в очередь. (Я выполнил каждое из команд в отдельном сеансе, чтобы позволить им завершиться независимо друг от друга.) Я не обязательно беспокоился, что будет увеличиваться блокировка от этих операторов, поскольку блокировка монопольной схемы снимается быстро, но я не был уверен, каких улучшений ожидать.
Было достаточно улучшений, и я счел их достаточно важными, чтобы поделиться преимуществами. Конечные пользователи видели, что выполнение запросов превышало 50 мсек или больше при включенных индексах. После этого оно упало до менее 3 мс. Кроме того, там, где они наблюдали экстремальные уровни ожидания диска / ввода-вывода перед изменением, после этого масштаб ожидания значительно снизился и был заменен обычными ожиданиями CX_PACKET, которые означают параллелизм и обычно являются безвредными. Фактически это указывало на лучшую пропускную способность, а затем мы начали наблюдать уменьшение количества блоков, уменьшение длины очереди и возврат не только к нормальной пиковой нагрузке, но и к лучше, чем к нормальной пиковой нагрузке .(На приведенном ниже графике ЦП показано улучшение по сравнению с почти 100% кризисом ЦП в предыдущий день.)
Что меня действительно удивило, так это то, что это действие также привело к тому, что эти дорогостоящие поисковые запросы были сняты с невероятной скоростью. Скорость поиска ключей составляла в среднем 4 миллиона в секунду; после изменения они сократились до приемлемых пределов, поскольку индексы стали отключенными. На следующем графике показано, каковы были уровни ключевых запросов в секунду за предыдущий день (заштрихованный диапазон):
Заключение
Хотя индексы критически важны для высокопроизводительной базы данных, они не панацея.Я предлагаю использовать минималистский подход к созданию индексов: всегда помните тот факт, что каждый индекс имеет накладные расходы. Выделение небольшого количества времени каждый месяц на анализ использования индекса также является хорошей профилактической мерой. Это должно служить напоминанием о том, насколько важно понимать, как базы данных используются внутри компании.
Что касается индексов, созданных для команды хранилища данных и никогда не использовавшихся в производственной среде? Оставляя их отключенными и не удаляя их, это позволяет группе хранилища данных включать их и восстанавливать их перед процессом ETL.Они получают все преимущества индексов, но индексы не создают накладных расходов для нормальной обработки транзакций, происходящей в производственной среде.
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 для таблицы клиентов:
CREATE TABLE [dbo]. [Customers] ( [CustomerID] [int] IDENTITY (1,1) NOT NULL, [FirstName] [nvarchar] (255) NULL, [LastName] [ nvarchar] (255) NOT NULL, [Street] [nvarchar] (255) NOT NULL, [StreetNumber] [nchar] (10) NOT NULL, [Unit] [nchar] (10) NULL, [City] [nvarchar] (255) NOT NULL, [StateProvince] [nvarchar] (255) NOT NULL, [ISO3_Country] [char] (3) NOT NULL, [EmailAddress] [varchar] ( 254) NULL, [HomePhone] [numeric] (15, 0) NULL, [MobilePhone] [numeric] (15, 0) NULL ) ON [PRIMARY] |
Затем давайте заполним его данными с помощью ApexSQL Generate:
Теперь давайте воспользуемся ApexSQL Plan, чтобы изучить этот простой запрос:
ВЫБРАТЬ * ОТ клиентов, у которых CustomerID = 50000; |
Когда мы просматриваем предполагаемый план выполнения, мы видим:
Главное, что будет делать SQL Server, — это сканирование таблицы.Это означает, что он будет читать все строки этой таблицы, пока не найдет строку с идентификатором клиента 50000. Интересно, что если мы наведем курсор на большую стрелку справа налево в предполагаемом плане, мы увидим следующее:
Предполагаемые строки = 1! Это потому, что SQL Server ожидает только одного клиента с совпадающим идентификатором. Может быть и больше (поскольку на данный момент ничто не может предотвратить это), но нет никакого способа узнать наверняка.
Хорошо, теперь давайте запустим этот запрос, чтобы узнать, что мы можем узнать.Самое интересное — это вкладка чтения ввода-вывода:
Имеется 2506 логических операций чтения — по одному на каждую страницу в таблице. Кроме того, существует равное количество операций чтения с упреждающим чтением. Это физические чтения, которые SQL Server выполняет в ожидании необходимости. Итак, какая часть таблицы это? Этот запрос сообщает нам, сколько страниц используется этой таблицей:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 18 19 20 21 22 23 24 | SELECT т.NAME AS TableName, строк AS RowCounts, SUM (a.total_pages) AS TotalPages, SUM (a.used_pages) AS UsedPages, (SUM (a.total_pages) — SUM (a.used_pages) ) AS UnusedPages ИЗ sys.tables t INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id INNER JOIN sys.partitions p = ON i.object_id_ .index_id = p.index_id ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.allocation_units a ON p.partition_id = a.container_id WHERE t.NAME = ‘Customers’ AND t.is_ms_shipped = 0 AND i.OBJECT_ID> 255 GROUP BY t.Name Ряды ЗАКАЗАТЬ ПО т. Наименование |
И этот запрос говорит нам:
Верно! SQL Server должен был прочитать все страницы таблицы, кроме одной! Возможно, вы думали, что он найдет соответствующую строку примерно на полпути? Это было бы ожидаемое время выполнения, не так ли? O (n / 2)? Но поскольку SQL Server выполняет операции упреждающего чтения, чтобы минимизировать количество операций чтения, он завершает чтение всех страниц данных.(Другая страница содержит метаданные.)
Если бы эта таблица была частью загруженной системы OLTP и имела миллионы строк и тысячи одновременных поисков, это сильно затруднило бы использование системных ресурсов. Даже если бы вы могли удерживать всю таблицу в пуле буферов, это сделало бы эти буферы недоступными для других запросов. В любом случае это сделает сервер слабым. Правильное индексирование — это лекарство!
Вопрос 3. Какие типы индексов доступны в SQL Server?
SQL Server поддерживает индексацию для различных нужд.Заимствуя документацию Microsoft, они доступны в SQL Server 2016:
Тип | Описание |
Кластеризованный | Кластерный индекс сортирует и сохраняет строки данных таблицы или представления по порядку на основе ключа индекса. Этот тип индекса реализован в виде структуры B-дерева, которая поддерживает быстрое извлечение строк на основе их значений ключей. |
Некластеризованный | Некластеризованный индекс можно определить в таблице или представлении с кластеризованным индексом или в куче.Каждая строка в индексе содержит значение ключа и указатель строки. Этот указатель указывает на строку данных в кластеризованном индексе или куче, имеющую значение ключа. Строки в индексе хранятся в порядке значений ключей, но не гарантируется, что строки данных будут находиться в каком-либо конкретном порядке, если они не находятся в кластеризованном индексе. |
Уникальный | Уникальный индекс гарантирует, что ключ не содержит повторяющихся значений, и поэтому каждая строка в таблице или представлении в некотором роде уникальна. |
Индекс с включенными столбцами | Некластеризованный индекс, расширенный за счет включения неключевых столбцов в дополнение к ключевым столбцам. |
Полный текст | Особый тип функционального индекса на основе токенов, который создается и поддерживается Microsoft Full-Text Engine для SQL Server. Он обеспечивает эффективную поддержку сложного поиска слов в данных символьной строки. |
Пространственный | Пространственный индекс предоставляет возможность более эффективно выполнять определенные операции с пространственными объектами ( пространственных данных ) в столбце с типом данных geometry .Пространственный индекс уменьшает количество объектов, к которым необходимо применить относительно дорогостоящие пространственные операции. |
Отфильтровано | Оптимизированный некластеризованный индекс, особенно подходящий для запросов, которые выбирают из четко определенного подмножества данных. Он использует предикат фильтра для индексации части строк в таблице. Хорошо спроектированный отфильтрованный индекс может повысить производительность запросов, снизить затраты на обслуживание индекса и снизить затраты на хранение индекса по сравнению с индексами с полной таблицей. |
XML | Уничтоженное и постоянное представление больших двоичных объектов (BLOB) XML в столбце типа данных xml . |
Источник: © 2017 Microsoft
Полнотекстовые, пространственные и XML-индексы выходят за рамки данной статьи. Мы сконцентрируемся на кластерных и некластеризованных индексах и рассмотрим некоторые из их расширений, включая уникальные и отфильтрованные индексы, а также полезность включенных столбцов.Хотя это не упомянуто выше, мы также не будем рассматривать в этой статье индексы columnstore или таблицы в памяти.
Как описано выше, кластеризованный индекс влияет на то, как данные фактически хранятся. В куче строки данных хранятся в произвольном порядке. Они пишутся везде, где подходят, с минимальной нагрузкой на ресурсы SQL Server, такие как буферный пул и подсистему ввода-вывода. С другой стороны, когда вы создаете кластерный индекс для таблицы, организация данных изменяется так, что теперь они упорядочены в соответствии с указанными ключами.Весь индекс организован в виде B-дерева («B» означает сбалансированный), где конечные узлы являются фактическими страницами данных, а один или несколько уровней узлов индекса построены поверх конечных узлов вплоть до единственного корневого узел. Результат дает некоторые гарантии относительно асимптотической производительности индекса. Большинство операций (поиск, вставка и удаление) выполняются в O (журнал n ), где n — количество записей в индексе.
Некластеризованный индекс разделяет концепцию B-дерева для узлов индекса с теми же гарантиями производительности.Однако такие индексы , а не влияют на организацию страниц данных, которые могут быть кластеризованы или нет. Некоторые дополнительные функции некластеризованных индексов:
- Уникальные индексы — где записи индекса должны быть уникальными, и SQL Server гарантирует, что они
- Отфильтрованные индексы — это индексы, построенные с предложением WHERE для ограничения того, что включается в индекс.
- Включенные столбцы — которые могут содержать подмножество неключевых столбцов как часть индекса.
Если вы обдумаете значение этих описаний, вы увидите, что таблица — это , — куча, или — кластеризованный индекс. Другие последствия заключаются в том, что, поскольку конечный узел кластеризованного индекса является страницей данных, нет необходимости во включенных столбцах (поскольку все столбцы находятся на странице данных) или отфильтрованных индексах (поскольку кластеризованный индекс — это вся таблица по определению) . Более тонкое понимание заключается в следующем: поскольку теория B-Tree не оговаривает уникальность ключа, кластеризованный индекс может иметь строки с повторяющимися ключами.В этом случае SQL Server добавит к индексу скрытый уникальный определитель (4-байтовое целое число), чтобы обеспечить уникальность.
Вопрос 4. Что происходит при создании кластерного индекса?
Как объяснялось в ответе на вопрос 3 выше, когда вы создаете кластерный индекс, порядок строк на страницах данных изменяется. Добавляя кластеризованный индекс к нашему рабочему примеру, команда проста:
СОЗДАТЬ КЛАСТЕРИРОВАННЫЙ ИНДЕКС CIX_Customers_CustomerID ON dbo.Клиенты (CustomerID); |
Мы можем просмотреть и запустить это в ApexSQL Plan. Во-первых, давайте посмотрим на примерный план выполнения:
Ориентировочный план показывает только операцию по созданию индекса. Это означает, что он обрабатывается внутри и / или SQL Server предпочитает не раскрывать подробности. Однако сделать вывод о том, что должно произойти, несложно:
- Прочтите все страницы таблицы
- Сортировать строки по указанному ключу
- Заполнять новые страницы отсортированными строками (до коэффициента заполнения)
- Закрепите новые страницы в постоянном хранилище
- Освободите страницы, используемые строками данных, перед созданием индекса.
Если мы действительно выполним это, мы сможем увидеть некоторые из этих действий:
Это вполне соответствует ожиданиям! При чтении справа налево содержимое таблицы считывается (сканирование таблицы), 100 000 строк отправляются на сортировку, затем отсортированный набор данных отправляется в операцию IndexInsert, которая создает узлы индекса. Оператор параллелизма указывает обеспечение для параллельной операции IndexInsert, которая может выполняться во многих параллельных потоках в зависимости от количества доступных процессоров.Наконец, новые строки вставляются в таблицу. Мы не видим оператора для освобождения неиспользуемых страниц, но тогда это фоновая операция, которую вы никогда не увидите в плане выполнения.
Теперь, когда у нас есть кластерный индекс, повлияет ли это на наш исходный запрос?
ВЫБРАТЬ * ОТ клиентов, у которых CustomerID = 50000; |
Теперь примерный план выглядит так:
Первоначальное сканирование таблицы было заменено поиском по кластерному индексу.Поможет ли это уменьшить количество операций ввода-вывода, используемых для получения этой строки? Посмотрим!
Это огромная разница в ! Исходные 2500 считываний сократились до трех. Поскольку мы знаем, что для этой строки есть только одна страница данных (поскольку строка имеет общую длину <8090 - тема для другой статьи), мы можем сделать вывод, что два других ввода-вывода предназначены для страниц, содержащих узлы индекса. Мы можем подтвердить это простым запросом:
ВЫБРАТЬ ИНДЕКС СВОЙСТВА (OBJECT_ID (‘dbo.Customers ‘), ‘ CIX_Customers_CustomerID ‘,’ IndexDepth ‘) AS [Глубина индекса] |
Что возвращает:
соответствует нашим ожиданиям, и ввод-вывод читает.
Графически наш кластерный индекс теперь имеет такую структуру:
Источник: © Microsoft.com
Вопрос 5. А как насчет некластеризованных индексов?
Пока что мы искали клиентов только по их идентификатору.Что, если бы мы вместо этого хотели искать клиента по имени? Что-то вроде этого, возможно:
ВЫБРАТЬ * ОТ клиентов ГДЕ Фамилия = «Майерс» И Имя = «Кейтлин»; |
Предполагаемый план выполнения сейчас:
о нет! Мы вернулись к операции сканирования. (На этот раз это сканирование кластерного индекса, поскольку, как упоминалось ранее, таблица является либо кучей, либо кластеризованным индексом, и мы просто включили в нее таблицу Customers.Но становится еще хуже! Фактическое количество операций ввода-вывода увеличилось на !
Это потому, что SQL Server теперь также использует узлы индекса при сканировании страниц данных. Что можно сделать в этой ситуации? Конечно, добавьте некластеризованный индекс!
Давайте воспользуемся этим DDL для создания индекса:
СОЗДАТЬ НЕКЛАСТЕРНЫЙ ИНДЕКС IX_Customers_LastName_FirstName ON dbo.Клиенты (Фамилия, Имя); |
Имея это на месте, давайте еще раз попробуем SELECT. На этот раз план выглядит так:
Теперь мы видим, что выполняется поиск по индексу с использованием нового индекса, за которым следует поиск по ключу. Поиск ключа необходим, поскольку мы написали:
ВЫБРАТЬ * ОТ клиентов… |
и SQL Server должен вернуться к страницам данных, чтобы получить другие столбцы в строке.Причина — поиск ключа из-за того, как SQL Server создает некластеризованные индексы. Вам будет простительно думать, что некластеризованный индекс содержит указатель на страницы, содержащие строку данных. На самом деле это не так. Вместо указателя (например, номера сектора на диске) некластеризованный индекс сохраняет ключ кластеризованного индекса , если есть кластеризованный индекс. Конечно, прежде чем мы добрались до этого места, мы поместили кластерный индекс в таблицу Customers! Как следствие, мы получаем ключевой поиск.Если вы догадались, что это означает отдельный поиск в кластерном индексе, вы были правы!
Итак, снижает ли некластеризованный индекс наши операции ввода-вывода? Давайте проведем реальный пробег и посмотрим:
Как показано, наблюдается существенное сокращение операций ввода-вывода. Возможно, вы ожидали всего 3 чтения, как в примере с кластеризованным индексом, который мы использовали ранее. Однако нет никакой гарантии, что в таблице присутствует только одна Кейтлин Майерс. Давайте проверим, что:
ВЫБРАТЬ СЧЕТЧИК (*) КАК Кейтлинс ОТ клиентов ГДЕ Фамилия = ‘Майерс’ И Имя = ‘Кейтлин’; |
возвращает:
Итак, чтение ввода-вывода на самом деле вполне реалистично.
Название «некластеризованный» происходит от того простого факта, что этот тип индекса не является кластеризованным. Что это такое, это B-дерево, построенное поверх таблицы (которая может быть сгруппирована или скопирована в куча). Таким образом, если есть также кластеризованный индекс, некластеризованный индекс живет рядом с кластеризованным индексом, и его записи указывают на конечный уровень этого индекса — страницы данных. Некластеризованный индекс имеет такую структуру:
Источник: © Microsoft.ком
Вопрос 6: А как насчет включенных столбцов? Чем они могут помочь?
Вы видели, что запрос, использующий некластеризованный индекс, должен искать другие столбцы с ключевым поиском в кластеризованном индексе. Что, если бы вы часто запрашивали только часть других столбцов? Что, если бы вы часто искали номер телефона клиента? Вот тут-то и пригодятся включенные столбцы. Если я изменю некластеризованный индекс следующим образом:
СОЗДАТЬ НЕКЛАСТЕРНЫЙ ИНДЕКС IX_Customers_LastName_FirstName ON dbo.Клиенты (Фамилия, Имя) ВКЛЮЧАЮТ (Домашний телефон); |
затем запустите этот запрос:
ВЫБРАТЬ HomePhone среди клиентов ГДЕ Фамилия = «Майерс» И Имя = «Кейтлин»; |
План выполнения меняется на это:
Больше никаких ключей! Чтения ввода-вывода также уменьшаются:
Итак, мы видим положительную пользу включенных столбцов.Это, естественно, вызывает вопрос: «Почему бы просто не добавить включенные столбцы в индекс в первую очередь?» Чтобы понять, почему, сначала рассмотрите следующее: хотя ключевые столбцы хранятся на всех уровнях индекса, неключевые столбцы хранятся только на конечном уровне . Во избежание путаницы, хотя некластеризованный индекс указывает на страницы данных, его листья являются частью самого B-дерева.
Почему бы не поместить включенные столбцы в ключи индекса? Причин несколько:
- Стоимость хранения.Если включенные столбцы не нужны для других типов поиска, их исключение из списка ключей позволяет сократить записи в указателе и получить более плоское B-дерево. Это приводит к меньшему количеству операций ввода-вывода индекса.
- Ограничения SQL Server. В настоящее время в индексе может быть не более 16 ключевых столбцов, и в целом эти ключевые столбцы не могут превышать максимальный размер индекса в 900 байт.
- Включенные столбцы могут быть типами данных, которые нельзя использовать в качестве столбцов индекса.Например, nvarchar (max), varbinary (max), xml и другие не могут быть ключевыми столбцами, но могут включать столбца.
Когда индекс содержит все столбцы, необходимые для удовлетворения запроса, он называется индексом , охватывающим . Включение стратегических столбцов в некластеризованный индекс может гарантировать, что наиболее частые запросы могут быть полностью удовлетворены из индекса без необходимости поиска ключей в кластеризованном индексе.
Хотя мы не упомянули об этом, вы можете поместить некластеризованный индекс в кучу — это таблица без кластеризованного индекса.В этом случае любой поиск на страницах данных является поиском RID. «R» означает строку, а RID состоит из виртуального адреса, который включает номер файла и номер страницы страницы данных, а также слот строки на странице данных.
Вопрос 7. Как насчет первичных ключей (и ключей в целом)?
До сих пор мы избегали обсуждения первичных ключей. Это не случайность. Слишком часто кластерные индексы и первичные ключи объединяются, как будто это одно и то же.Они не! Вот почему мы оставили их до сих пор. Лучше всего получить твердое представление о типах индексов, прежде чем вводить ключи.
Чтобы быть отношением в формальном, реляционно-алгебраическом смысле этого слова, таблица (то, что большинство РСУБД называют отношениями ) должна иметь ключ — некоторый столбец или набор столбцов, которые вместе взятые однозначно идентифицируют строку в Таблица. Однако ключ — это не индекс. Это может быть (и обычно так) поддерживается индексом , но в его основе ключ — это ограничение — условие, которое база данных должна поддерживать для сохранения ссылочной целостности.Вы можете увидеть разницу, создав первичный ключ для таблицы Customers в примере, который мы используем:
ИЗМЕНИТЬ ТАБЛИЦУ dbo.Customers ДОБАВИТЬ ОГРАНИЧЕНИЕ PK_Customers_CustomerID PRIMARY KEY (CustomerID); |
Обратите внимание, что оператор добавляет ограничение , а не индекс . Он добавляет именно такое ограничение в столбец CustomerID.Теперь, когда у нас уже есть как кластеризованный, так и некластеризованный индекс, это дает интересный результат. В обозревателе объектов SSMS теперь мы видим три индекса !
Новый был создан как вспомогательный индекс для реализации ограничения. Обратите внимание, что это некластеризованных. Если вы думали, что первичные ключи должны быть кластеризованными индексами, подумайте еще раз. Интересно, что SQL Server не распознал, что уже существует покрывающий кластерный индекс, и не использовал его.Я подозреваю, что построение индексов так, как мы это делаем здесь, хорошо для инструкций, но не оптимально для правильного проектирования, поэтому команда разработчиков SQL Server еще не работала над этим пограничным случаем и, возможно, никогда не сделает этого.
До того, как мы добавили ограничение первичного ключа, было возможно и допустимо добавлять новых клиентов с теми же идентификаторами клиентов, что и у существующих клиентов. Давай, попробуй! Однако теперь, когда ПК установлен, это больше невозможно.
Хотя может быть только один первичный ключ , могут быть и другие ключи, если другие комбинации столбцов действительно уникальны.При их создании используется аналогичный синтаксис:
ALTER TABLE dbo.Customers ADD CONSTRAINT AK_Customers_LastName_FirstName_HomePhone UNIQUE (Фамилия, Имя, Домашний телефон); |
Эта операция создает уникальное ограничение , а также добавляет индекс поддержки:
Первичные ключи необходимы, чтобы таблица соответствовала теории отношений.На практике они очень полезны (как и уникальные ключи) для ссылочной целостности и являются хорошим способом заставить базу данных проверять ваши предположения о входящих данных.
Вопрос 8: Должен ли мой первичный ключ также быть ключом кластеризованного индекса?
По умолчанию SQL Server создает кластерный индекс при создании новой таблицы с первичным ключом:
CREATE TABLE PrimaryKey (id INT IDENTITY PRIMARY KEY, name VARCHAR (50) ); |
Эта команда создает ключ, подкрепленный кластеризованным индексом (с именем, предоставленным системой):
Однако то, что это действие по умолчанию, не означает, что это всегда лучший выбор.Хотя первичный ключ должен поддерживаться индексом для реализации ограничения, индекс не нужно кластеризовать, как мы видели выше. Более того, цели первичных ключей и кластеризованных индексов могут не совпадать.
По сути, ограничение первичного ключа позволяет SQL Server поддерживать то важное свойство, что таблица не может иметь повторяющихся строк. Фактически, уникальные ограничения делают то же самое. Поскольку они поддерживаются индексами, ключи также полезны для поиска, поскольку
- Для любого ключа может быть только одна строка
- Индекс позволяет использовать операцию поиска, которая обычно требует меньше операций ввода-вывода.
С другой стороны, кластеризованные индексы могут обеспечить преимущество в производительности при чтении таблицы в порядке индекса. Это позволяет SQL Server лучше использовать чтение с упреждающим чтением, которое асимптотически быстрее, чем постраничное чтение. Кроме того, кластерный индекс не требует уникальности. Если две или более строк имеют один и тот же ключ кластеризованного индекса, добавляется уникальность, чтобы гарантировать, что все строки в индексе являются уникальными на .
Возвращаясь к нашей таблице клиентов, это совершенно правильная настройка индекса / ключа:
СОЗДАТЬ КЛАСТЕРНЫЙ ИНДЕКС IX_Customers_LastName_FirstName ON dbo.Клиенты (Фамилия, Имя); ИЗМЕНИТЬ ТАБЛИЦУ dbo.Customers ДОБАВИТЬ ОГРАНИЧЕНИЕ PK_Customers_CustomerID ПЕРВИЧНЫЙ КЛЮЧ НЕ ОБЪЕДИНЕН (CustomerID); |
Здесь мы предполагаем, что большинство операций чтения выполняется по фамилии, имени (кластеризованный индекс) и что большинство поисков выполняется по идентификатору клиента (первичный ключ). (SQL Server добавит уникальный указатель к кластеризованному индексу, поскольку он не знает, будут ли конфликты ключей или нет.Здесь важно тщательно продумать, какое расположение лучше всего подходит для нового стола. Проконсультируйтесь с бизнес-пользователями о том, как будет использоваться таблица. Помните, что большинство отчетов носит последовательный характер. Выберите соответствующую индексацию и проверьте ее. Используйте реальные рабочие нагрузки и посмотрите, соответствует ли фактическое использование схеме индексирования. Если нет, отрегулируйте его по своему усмотрению.
Вопрос 9: Что это за «отсутствующие индексы» в плане выполнения
Иногда в план выполнения включается сообщение об отсутствии индекса.Например, если я удалю индексы из таблицы Customer и попробую выполнить поиск по CustomerID, полученный план будет выглядеть следующим образом:
Текст, выделенный зеленым цветом выше, является именно таким сообщением. По сути, SQL Server говорит, что если бы в столбце CustomerID был индекс, стоимость всего запроса могла бы быть снижена на 99,8%! Это снизило бы стоимость почти до нуля. Вместо просмотра таблицы он может использовать операцию поиска по индексу.
Тогда возникает вопрос, следует ли вам всегда реализовывать отсутствующий индекс? Как это часто бывает, «как бывает!» это единственный верный ответ.Это годовой запрос, который выполняется без индекса за 10 минут? Возможно, вы можете оставить этот недостающий индекс в покое. Это запрос, который выполняется тысячи раз в секунду с загруженного сервера электронной коммерции? Возможно, вам стоит выполнить рекомендацию! Не думайте, что мама знает лучше! Перед тем, как что-либо делать, вам необходимо обдумать это и понять модели использования и стоимость индекса. Подумайте об этом…
Вопрос 10: Могу ли я иметь слишком много индексов?
На самом деле есть совет, гласящий, что вы должны просто проиндексировать каждый столбец в своей таблице, чтобы ни один план выполнения никогда не имел отсутствующего индекса.Это хороший совет? Опять же, это зависит от обстоятельств.
Базы данных хранилища данных часто имеют календарную таблицу. В этой таблице будет строка для каждой даты и столбцы для каждого возможного использования: MonthNumber, QuarterNumber, HalfYearNumber, MonthText, FullDateText, Is_Holiday, Is_BusinessDay и многие, многие другие. Такая таблица статична. Часто первичный ключ (и кластеризованный индекс) представляет собой целочисленный столбец или столбец даты с датой, соответствующей другим столбцам в строке. Эта таблица никогда (или редко) изменяется.Кроме того, он не слишком большой. (Сколько строк вам понадобится на столетие?) В такой таблице индексация каждого столбца может иметь смысл. Вы можете иметь отфильтрованные индексы для различных флагов, индексов по возрастанию и по убыванию, большинство из которых будут некластеризованными.
Теперь рассмотрим нашу таблицу клиентов. Если мы проиндексируем каждый столбец, что произойдет, когда мы добавим нового клиента?
1 2 3 4 5 6 7 8 9 10 11 12 13 140002 13 14 18 19 20 21 22 23 24 25 26 27 28 | ВСТАВИТЬ В [dbo].[Клиенты] ([Имя] , [Фамилия] , [Улица] , [Номер улицы] , [Подразделение] , [Город] , [Государственная провинция] , [ISO3_Country] ] , [EmailAddress] , [HomePhone] , [MobilePhone]) ЗНАЧЕНИЯ (‘Ford’, ‘Prefect’, ‘The Resraurant’, ’42’, ’42’, ’42’, ’42’, ’42’, ’42’ «Нет данных», «Конец Вселенной», «Невероятно», «FPP», «Ford @ HeartOfGold».com ‘, 2125551212, 31415 |
Фактический план выполнения для этого:
Все эти индексы необходимо поддерживать! Эта работа может быстро накапливаться, поэтому, если у вас нет статической таблицы (например, календарной таблицы), индексация каждого столбца обычно является плохой идеей!
Резюме
Правильная индексация таблицы SQL Server — ключ к обеспечению стабильной и оптимальной производительности.При разработке структуры индекса необходимо учитывать множество факторов. Почти ни одно из этих соображений невозможно сделать без консультации с бизнес-пользователями, которые понимают данные и то, как они будут использоваться, хотя вполне может оказаться, что после того, как новая таблица будет использоваться в течение некоторого времени, будут представлены другие параметры индексации. сами себя.
В этой статье сделана попытка ответить на некоторые из наиболее важных вопросов об индексировании в целом и, в частности, о том, как это делается в SQL Server.Однако на самом деле мы только поцарапали поверхность. Каждый вопрос, на который здесь дан ответ, может быть отдельной полной статьей или, возможно, серией статей! Кроме того, мы вообще не рассматривали другие типы индексов (например, XML-индексы) и не рассматривали объекты в памяти и то, как они меняют картину для новых выпусков SQL Server.
Следите за обновлениями, чтобы увидеть более подробные статьи об индексировании SQL Server.
Джеральд Бриттон — старший дизайнер решений SQL Server, автор, разработчик программного обеспечения, преподаватель и MVP платформы данных Microsoft.Он имеет многолетний опыт работы в ИТ-индустрии на различных должностях.Gerald специализируется на решении проблем производительности запросов SQL Server, особенно в том, что касается решений Business Intelligence. Он также является соавтором электронной книги «Начало работы с Python» и заядлым разработчиком Python, преподавателем и автором Pluralsight.
Вы можете найти его в LinkedIn, в Twitter на twitter.com/GeraldBritton или @GeraldBritton и на Pluralsight
Просмотреть все сообщения Джеральда Бриттона
Последние сообщения Джеральда Бриттона (увидеть все)Как определить и контролировать неиспользуемые индексы в SQL Server
Индексы SQL Server по сути представляют собой копии данных, которые уже существуют в таблице, упорядоченные и отфильтрованные различными способами для повышения производительности выполняемых запросов.Операторы поиска, сканирования и поиска используются для доступа к индексам SQL Server.
Операторы поиска — оператор поиска использует способность SQL Server выполнять поиск в индексах для получения строк из кластеризованных или некластеризованных индексов, и поиск может быть как физическим, так и логическим оператором. Индекс выполняет поиск только с квалифицированными строками и со страницами, которые содержат эти квалифицированные строки, и поэтому стоимость поиска меньше. Проще говоря, пытается получить только выбранные строки из таблицы.
Операторы сканирования — оператор сканирования просматривает кластеризованный индекс и предназначен для работы с каждой строкой в отсканированной таблице, независимо от того, квалифицирована она или нет. Оператор сканирования может быть эффективен для небольших таблиц или в ситуации, когда большинство строк квалифицировано. Проще говоря, сканирование извлекает все строки из таблицы.
Операторы поиска — оператор поиска, используется для извлечения неключевых данных из набора результатов, полученного из некластеризованного индекса.После получения строк из некластеризованного индекса для получения информации о столбцах из этих строк используются поисковые запросы.
В то время как правильное использование индексов SQL Server может обеспечить улучшенную производительность выполняемых запросов и, следовательно, SQL Server в целом, их неправильная установка или не установка их там, где это необходимо, может значительно снизить производительность выполняемых запросов. Более того, наличие ненужных индексов, которые не используются запросами, также может быть проблематичным.
Индексы SQL Server — отличный инструмент для повышения производительности запросов SELECT, но в то же время индексы SQL Server отрицательно влияют на обновления данных. Операции INSERT, UPDATE и DELETE вызывают обновление индекса и, таким образом, дублирование данных, которые уже существуют в таблице. В результате это увеличивает продолжительность транзакций и выполнение запроса и часто может привести к блокировке, блокировке, взаимоблокировке и довольно частым тайм-аутам выполнения. Для больших баз данных или таблиц на пространство хранения также влияют избыточные индексы.Критическая цель любого администратора базы данных SQL Server — поддерживать индексы, включая создание необходимых индексов, но в то же время удаление тех, которые не используются.
Поиск неиспользуемых индексов
SQL Server предоставляет значительный объем индексной информации через динамические административные представления (DMV). DMV dm_db_index_usage_stats отображает важную информацию об использовании индекса и может быть полезным инструментом для определения неиспользуемых индексов SQL Server. Когда индекс используется впервые, в DMV dm_db_index_usage_stats создается новая строка, которая впоследствии обновляется каждый раз при использовании индекса.Однако, как и в любом DMV, данные, представленные в dm_db_index_usage_stats , содержат только данные с момента последнего перезапуска службы SQL Server (перезапуск службы SQL Server сбрасывает данные в DMV). Поэтому очень важно, чтобы с момента последнего перезапуска SQL Server прошло достаточно времени, чтобы правильно определить, какие индексы являются хорошими кандидатами на удаление.
Простой запрос, который можно использовать для получения списка неиспользуемых индексов в SQL Server (обновленные индексы, не используемые ни в каких операциях поиска, сканирования или поиска), выглядит следующим образом:
1 2 3 4 5 6 7 8 9 10 11 12 13 140002 13 14 18 19 | ВЫБРАТЬ объектов.Название А.С. TABLE_NAME, indexes.name А.С. index_name, , dm_db_index_usage_stats.user_seeksdm_db_index_usage_stats.user_scans, dm_db_index_usage_stats.user_updates ОТ sys.dm_db_index_usage_stats INNER JOIN sys.objects ПО dm_db_index_usage_stats.OBJECT_ID = объекты .OBJECT_ID INNER JOIN sys.indexes ON indexes.index_id = dm_db_index_usage_stats.index_id И dm_db_index_usage_stats.OBJECT_ID = indexes.OBJECT_ID ГДЕ И dm_db_index_usage_stats.user_lookups = 0 И dm_db_index_usage_stats.user_seeks = 0 И dm_db_index_usage_stats.user_scans = 0 ORDER BYdm_db_index_usage_stats.user_updates DESC |
Вышеупомянутый запрос возвращает все неиспользуемые индексы всех типов. Этот запрос часто можно найти в Интернете, но он не является идеальным / полным вариантом.Использование такого запроса для поиска и очистки неиспользуемых индексов может привести к неожиданному поведению, поскольку этот запрос не принимает во внимание ограничения первичного ключа и уникального ключа при сборе неиспользуемых данных индекса. Индексы ограничений как первичного, так и уникального ключа могут быть «неиспользованными», но удаление этих индексов может быть проблематичным. Чтобы предотвратить этот сценарий, приведенный выше запрос необходимо уточнить, добавив две строки кода после WHERE, чтобы исключить первичный и уникальный ключи из списка как неиспользуемые и потенциально удаленные.
1 2 3 4 5 6 7 8 9 10 11 12 13 140002 13 14 18 19 20 21 22 | ВЫБРАТЬ объектов.Название А.С. TABLE_NAME, indexes.name А.С. index_name, , dm_db_index_usage_stats.user_seeksdm_db_index_usage_stats.user_scans, dm_db_index_usage_stats.user_updates ОТ sys.dm_db_index_usage_stats INNER JOIN sys.objects ПО dm_db_index_usage_stats.OBJECT_ID = объекты .OBJECT_ID INNER JOIN sys.indexes ON indexes.index_id = dm_db_index_usage_stats.index_id И dm_db_index_usage_stats.OBJECT_ID = indexes.OBJECT_ID WHERE indexes.is_primary_key = 0 — это условие исключает ограничение первичного ключа И индексов. is_unique = 0 — это условие исключает константу уникального ключа И dm_db_index_usage_stats. user_lookups = 0 AND dm_db_index_usage_stats.user_seeks = 0 AND dm_db_index_usage_stats.user_scans = 0 ЗАКАЗАТЬ BY dmatsuser_updates DESC |
В приведенном выше запросе перечислены все неиспользуемые запросы, которые не являются первичными и уникальными ключами, но также перечислены все неиспользуемые индексы, с которыми SQL Server не работал. Столбец user_updates в DMV dm_db_index_usage_stats подсчитывает, где индекс был обновлен, поскольку приложение внесло некоторые изменения в данные, поэтому индекс был обновлен. Для этого в предыдущий скрипт нужно добавить условий dm_db_index_usage_stats.user_updates <> 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 18 19 20 21 22 23 24 | ВЫБРАТЬ объектов.Название А.С. TABLE_NAME, indexes.name А.С. index_name, , dm_db_index_usage_stats.user_seeksdm_db_index_usage_stats.user_scans, dm_db_index_usage_stats.user_updates ОТ sys.dm_db_index_usage_stats INNER JOIN sys.objects ПО dm_db_index_usage_stats.OBJECT_ID = объекты .OBJECT_ID INNER JOIN sys.indexes ON indexes.index_id = dm_db_index_usage_stats.index_id И dm_db_index_usage_stats.OBJECT_ID = indexes.OBJECT_ID WHERE indexes.is_primary_key = 0 — эта строка исключает ограничение первичного ключа И индексов. is_unique = 0 — эта строка исключает уникальный ключ constarint И dm_db_index_usage_stats.user_updates <> 0 — Эта строка исключает индексы, SQL Server не работал с И dm_db_index_us. user_lookups = 0 И dm_db_index_usage_stats.user_seeks = 0 AND dm_db_index_usage_stats.user_scans = 0 ЗАКАЗАТЬ BY dm_db_index_usage_stats.user_updates DESC |
Итак, теперь, когда неиспользуемые индексы SQL Server идентифицированы и перечислены, можно определить, какие индексы можно безопасно отбросить, но, опять же, это нужно делать очень осторожно.
Какие неиспользуемые индексы не следует удалять?
Уникальные ограничения
Примером дополнительных причин для осторожности является то, что индекс может быть указан как неиспользуемый, но он может применять уникальное ограничение, и вполне вероятно, что оптимизатору запросов может понадобиться этот индекс.Оптимизатор запросов может использовать гарантию уникальности при определении того, какие логические преобразования и физические операции следует использовать для получения точных результатов. Оптимизатор запросов учитывает гарантию уникальности для выполнения определенных операций, но это не отражается в статистике использования индекса без физического доступа к индексу в окончательном плане выполнения. Имея это в виду, любое удаление уникального индекса или ограничения должно выполняться с максимальной осторожностью.
Использовать статистику
Еще одна вещь, с которой следует соблюдать осторожность, — это возможность того, что оптимизатор запросов использует статистику, связанную с этим индексом, даже в ситуациях, когда окончательный план выполнения не использует никакого доступа к этому индексу.Оценка количества элементов, загрузка кандидатов для статистики и, наконец, создание завершенного плана выполнения запроса — это полностью независимые действия.
Наконец, удаление индекса может привести к удалению и сопутствующей статистики индекса. Это может повлиять на качество плана выполнения запроса при перекомпиляции оператора. это связано с тем, что план выполнения запроса может использовать статистику индекса, даже если индекс физически не присутствует в окончательном плане выполнения, для вычисления оценки мощности, на которую в значительной степени опирается окончательный план выполнения.
Это лишь некоторые из потенциальных проблем, с которыми можно столкнуться при отбрасывании индекса, и поэтому такое действие должно быть запланировано путем проведения адекватного тестирования и с планом восстановления, если что-то пойдет не так.Кроме того, наличие некоторых неиспользуемых индексов SQL Server не обязательно указывает на проблему, но если количество неиспользуемых индексов растет с течением времени с некоторой более или менее постоянной скоростью или при внезапном росте, это должно быть проверены и, в большинстве случаев, протестированы
Падение индексов
Следующий сценарий создает сценарий удаления для всех неиспользуемых индексов. Он основан на предыдущем сценарии, который является более безопасным, но он предоставляется в качестве руководства, и любое удаление индексов осуществляется по собственному усмотрению пользователя.Идентификатор цели сценария, помогающий определить индексы, которые являются кандидатами на удаление, поэтому не указывайте это в пузыре.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 18 19 20 | ВЫБЕРИТЕ ‘DROP INDEX’ + OBJECT_NAME (dm_db_index_usage_stats.object_id) + ‘.’ + indexes.name AS Drop_Index, user_seeks, user_scans, user_lookups, user_updates FROM sys.dm_db_index_usage_stats 9000_dm_db_index_usage_statsINNER JOIN_index_usage_stats. .indexes ON indexes.index_id = dm_db_index_usage_stats.index_id И dm_db_index_usage_stats.OBJECT_ID = indexes.OBJECT_ID ГДЕ indexes.is_primary_key ИСКЛЮЧАЕТ первичный ключ .is_unique = 0 — эта строка исключает уникальный ключ constarint И dm_db_index_usage_stats.user_updates <> 0 — Эта строка исключает индексы, SQL Server не работал с И dm_db_index_us. user_lookups = 0 AND dm_db_index_usage_stats.user_seeks = 0 AND dm_db_index_usage_stats.user_scans = 0 ЗАКАЗАТЬ BY dmatsuser_updates DESC |
Полезных ресурсов:
Никола — компьютерный фанат с 1981 года и энтузиаст SQL с намерением стать уродом. Специализируется на аудите SQL Server, соблюдении нормативных требований и мониторинге производительности.
Любитель военной авиации и опытный моделлер. Любитель экстрима; парашютист и инструктор по прыжкам с тарзанки. Когда-то серьезно, теперь просто свободное время фотограф
Посмотреть все сообщения Николы Димитриевича
Последние сообщения Николы Димитриевича (посмотреть все) Серверsql — Почему в моем случае SQL выбирает неверный индекс?
Ваш запрос ссылается на четыре столбца :
- символ ID
- vTrdКупить
- тип ID
- barDateTime
В то время как кластерный индекс охватывает только три из них
- символ ID
- vTrdКупить
- тип ID
- бар Дата Время
Причина, по которой SQL Server игнорирует этот индекс, состоит в том, что он бесполезен для него.Индекс сначала сортируется по идентификатору символа
, и вам нужен не конкретный идентификатор символа, а набор случайных значений. Это означает, что он должен читать всю таблицу.
Следующий столбец в кластеризованном индексе — vTrdBuy
. Это не используется для того, чтобы помочь ему перейти к нужным строкам.
Глядя на запрос, два столбца очень специфичны в ограничении того, какие строки вы хотите вернуть:
ГДЕ typeID = 1
И barDateTime = 44991
Создание индекса, который начинается с typeID и barDateTime , действительно может помочь SQL Server перейти к строкам, которые вас интересуют.
Первый SQL Server может перейти прямо к строкам
typeID = 1.
Оказавшись там, он может перейти прямо к барам, где
barDateTime = 8 марта 2023 г.
Он может делать это, просматривая индекс, так как индекс упорядочен по столбцам в нем. Это очень быстро и исключает просмотр большинства строк.
Если вы создали индекс:
(
typeID
barDateTime
symbolID
)
он все равно может оказаться бесполезным, если запрос возвращает много строк.Чтобы завершить выполнение оператора SELECT, SQL Server по-прежнему требуется значение vTrdBuy . Он должен делать это, перебирая таблицу для , каждая из строк, соответствующих критериям (так называемый поиск по закладке ). Если строк слишком много (скажем,> 500), SQL Server просто забудет индекс и просто просканирует всю таблицу, потому что это будет быстрее.
Вы хотите предотвратить поиск закладок, позволив ему не возвращаться к таблице для пропущенного значения, вы хотите включить значение в индекс:
СОЗДАТЬ ИНДЕКС IX_mvTrdHidUhd_FancyCovering ON mvTrdHidUhd
(
typeID, barDateTime, symbolID, vTrdBuy
)
Теперь у вас есть индекс, который содержит все, что хочет SQL Server, в том порядке, в котором он хочет, и вам не нужно вмешиваться в физический порядок сортировки (т.е.е. кластеризация) физической таблицы.
Range Indexes and Lexicons (Руководство администратора) — Документация по продукту MarkLogic 10
MarkLogic Server позволяет вам создавать на уровне базы данных индексы и словари для элементов и атрибутов в соответствии с их QNames. В этой главе описаны эти указатели диапазонов и лексиконы. Включены следующие разделы:
Кроме того, вы можете создавать индексы диапазона для полей, как описано в разделе «Создание индекса диапазона для поля».
В этой главе описывается, как использовать интерфейс администратора для создания индексов диапазонов и лексиконов. Подробные сведения о программном создании индексов диапазона см. В разделе «Добавление индексов в базу данных» в Руководстве по задачам администрирования сценариев .
Общие сведения об индексах диапазона
В этой главе описаны типы индексов диапазона, показанные в таблице ниже. Существуют также индексы диапазона полей, как описано в разделе «Создание индекса диапазона для поля».
Тип | Описание |
---|---|
Индекс диапазона элемента | Индекс диапазона для элемента XML или свойства JSON. |
Индекс диапазона атрибутов | Индекс диапазона атрибута в элементе XML. |
Индекс диапазона пути | Индекс диапазона для элемента XML, атрибута XML или свойства JSON, как определено выражением XPath. |
Индекс диапазона полей | Индекс диапазона в поле. Дополнительные сведения см. В разделе «Настройки базы данных полей». |
MarkLogic Server поддерживает универсальный индекс для каждой базы данных для быстрого поиска текста, структуры и комбинаций текста и структуры, которые находятся в коллекциях документов XML и JSON.
Однако в некоторых случаях документы XML и JSON могут содержать числовую информацию или информацию о дате. Запросы к этим документам могут включать условия поиска, основанные на неравенствах (например, цена <100,00
или дата
ℜ≥ thisQtr
). Указание индексов диапазона для этих элементов, атрибутов и / или свойств JSON существенно ускорит оценку этих запросов.
Определение индекса диапазона также позволяет использовать конструкторы запроса диапазона (cts: element-range-query и cts: element-attribute-range-query) в операциях cts: search, что упрощает составление сложных выражений запроса диапазона использовать в поисках.Дополнительные сведения см. В главе «Использование запросов диапазона в выражениях cts: query» в Руководстве разработчика Search .
Аналогичным образом можно создать индексы диапазона типа xs: string
. Эти индексы могут повысить производительность запросов, которые сортируются по строковым значениям, а также используются для запросов лексики (см. Понятие словаря слов).
Если вы указываете индекс диапазона для элемента, и если у вас есть элементы с таким именем, которые имеют сложное содержимое (например, элементы с дочерними элементами), содержимое индексируется на основе приведения элемента к указанному типу индекс диапазона.Например, если вы укажете индекс диапазона типа xs: string
для элемента с именем h2
, тогда следующий элемент:
Это заголовок
жирным шрифтом . H2 >
проиндексировано со значением . Это выделенный жирным шрифтом заголовок
, который представляет собой значение, возвращаемое преобразованием элемента h2
в xs: string
. Такое же приведение типов применяется к индексам диапазона для атрибутов XML, свойств JSON и полей. Такое поведение позволяет индексировать сложное содержимое без предварительной обработки содержимого.
Кроме того, индексы диапазона могут улучшить производительность запросов, которые сортируют результаты с использованием предложения order by
и возвращают подмножество данных (например, первые десять элементов). Подробные сведения об этом порядке путем оптимизации с использованием индексов диапазона см. В разделе «Сортировка результатов поиска с использованием индексов диапазона» в руководстве Query Performance and Tuning Guide .
MarkLogic Server поддерживает индексы диапазона как для элементов, так и для атрибутов в широком спектре типов данных XML. По большей части этот список соответствует полностью упорядоченным типам данных XML:
Тип | Описание |
---|---|
внутренний | Целые положительные и отрицательные числа |
unsignedInt | Целые положительные числа (включая 0) |
длинный | Большие положительные и отрицательные целые числа |
беззнаковый длинный | Большие положительные целые числа (включая 0) |
поплавок | 32-битные числа с плавающей запятой |
двойной | 64-битные числа с плавающей запятой |
десятичный | Большие числа с плавающей запятой |
дата Время | Дата и время вместе |
время | Время (включая часовой пояс) |
дата | Полная дата (год, месяц, день) |
г Год Месяц | Только год и месяц |
г Год | Только год |
г Месяц | Только месяц |
г День | Только день |
год Месяц Продолжительность | Продолжительность лет и месяцев |
день Время Продолжительность | Продолжительность дней и времени |
струна | Строковые символьные данные |
любойURI | Строка URI |
Важно отметить, что перечисленные выше типы даты и времени соответствуют спецификации XML для даты и времени.В настоящее время другие форматы даты и времени не поддерживаются индексами диапазона MarkLogic Server. Для более подробного описания определения этих типов данных обратитесь к документам W3C XML Schema.
Индексы диапазона должны быть явно созданы с помощью интерфейса администратора, XQuery или JavaScript Admin API или REST Management API. Чтобы создать индекс диапазона для свойства JSON, используйте интерфейсы или функции индекса диапазона элементов. В следующей таблице представлена основная информация, необходимая для определения каждого вида индекса:
Тип индекса | Требуемая информация |
---|---|
Элемент XML | Имя элемента, пространство имен для элемента, тип данных значений, найденных в этом элементе. |
Атрибут XML | Имя атрибута, имя родительского элемента атрибута, пространство имен для элемента и тип данных значений, найденных в этом атрибуте. |
Свойство JSON | Имя свойства и тип данных значений, найденных в этом свойстве. |
путь | Выражение XPath и тип данных значений, найденных в элементе, атрибуте или свойстве JSON, выраженном XPath. |
поле | Имя поля и тип данных значений в поле. Вы также должны настроить определение поля. Подробнее см. Настройка полей. |
Индексы диапазонов заполняются в процессе загрузки документа и автоматически синхронизируются посредством последующих обновлений индексированных данных. Следовательно, индексы диапазонов должны быть указаны для базы данных до того, как любые документы XML или JSON, содержащие контент, который нужно проиндексировать, будут загружены в эту базу данных.В противном случае содержимое необходимо либо переиндексировать, либо перезагрузить, чтобы воспользоваться преимуществами новых индексов диапазона.
Используйте интерфейсы индекса диапазона элементов и API для создания индексов для документов JSON. Действуют некоторые ограничения. Дополнительные сведения см. В разделе «Создание индексов и словарей на основе документов JSON» в Руководстве разработчика приложений .
С индексом диапазона путей можно создать индекс того же типа, что и с индексом диапазона элементов или атрибутов. Индексы диапазона пути полезны в случаях, когда индекс диапазона элемента или атрибута не работает.Например, у вас могут быть документы с одним и тем же именем элемента, отображаемые под разными родительскими элементами, и вы хотите только проиндексировать элементы, появляющиеся под одним из родительских элементов. В этом случае для правильного индексации этого элемента требуется индекс диапазона путей.
При создании индекса диапазона со скалярным типом строки ( xs: строка
) укажите сопоставление, а также имя элемента / атрибута QNames или имя свойства JSON. Параметры сортировки определяют уникальный порядок строковых значений.Вы можете иметь несколько индексов диапазона для одного и того же элемента, атрибута или свойства JSON с разными сопоставлениями; то есть сопоставление является частью уникального идентификатора для индекса диапазона строк. Дополнительные сведения о сопоставлениях см. В главе «Кодировки и сопоставления» в Руководстве разработчика Search .
Поскольку индекс диапазона хранит типизированные данные, если данные, которые вы загружаете, не соответствуют этому типу или если они не могут быть приведены в соответствие с указанным типом, они не могут быть загружены в документ.Для каждого индекса диапазона вы можете указать, что делать с недопустимыми значениями: либо отклонит их
и загрузит документ, либо выдаст исключение и завершится ошибкой, либо проигнорирует их
и запишет ошибку в файл ErrorLog.txt
. По умолчанию отклоняет недопустимые данные
.
Индексы диапазона используют дисковое пространство и память. Это компромисс для повышения производительности. Кроме того, если у вас большой объем данных индекса диапазона и ваша система регулярно обновляется, вам может потребоваться увеличить размер ваших журналов.Подробные сведения о настройках журнала базы данных см. В разделе Параметры памяти и журнала.
Использование индексов диапазона для лексиконов значений
Помимо ускорения запросов сортировки и сравнения, MarkLogic Server использует индексы диапазона для разрешения запросов лексики значений элементов XML, XML, свойств JSON и полей. Это запросы, которые используют следующие API поиска:
Функции cts: values и cts: value-match работают с любым типом индекса диапазона и эквивалентны соответствующей специфичной для индекса функции при вызове со ссылкой на тот же тип индекс.Например, следующие два вызова функций эквивалентны:
cts: values (cts: element-reference (xs: QName ("some-element"))) cts: element-values (xs: QName ("some-element")
Чтобы использовать любой из этих API, вы должны создать индексы диапазона для элемента (ов), атрибута (ов), свойства (ов) JSON, или поля, указанные в запросе. Тип индекса диапазона должен соответствовать типу, указанному в API лексикона.
Подробнее о лексиконах см. в главе «Просмотр с помощью лексиконов» Search Developer's Guide .Дополнительные сведения об API-интерфейсах lexicon см. В MarkLogic XQuery и справочнике по функциям XSLT .
Понимание словарей
MarkLogic Server позволяет вам создавать словарный запас, который ограничен определенным элементом XML, атрибутом XML, свойством JSON или полем. Вы также можете определить словарный запас слов в сопоставлении. Словарь слов хранит все уникальные слова, которые хранятся в указанном элементе, атрибуте или свойстве JSON. Слова хранятся с учетом регистра и диакритических знаков, поэтому слова Ford
и ford
будут отдельными записями в лексиконе.
Лексиконы слов используются при поиске с использованием подстановочных знаков (когда подстановочные знаки включены). Дополнительные сведения см. В разделе «Общие сведения о поиске с использованием подстановочных знаков» в Руководстве разработчика Search Developer's Guide .
Чтобы использовать словарный запас, используйте следующие API поиска:
Общие сведения об индексах диапазона путей
Индекс диапазона путей позволяет определить индекс диапазона для элемента XML, атрибута XML или свойства JSON с помощью выражения XPath. Индекс диапазона путей может дать вам более точный контроль над тем, что индексируется.Например, если ваш контент содержит элементы с одинаковыми именами на нескольких уровнях, но вы хотите проиндексировать только один из них, вы можете использовать индекс диапазона путей для таргетинга только на этот.
В этом разделе описаны выражения XPath, которые можно использовать для определения индекса диапазона путей. По соображениям производительности MarkLogic Server ограничивает вас подмножеством XPath при определении индекса диапазона путей.
Примеры выражений пути индекса
В следующей таблице приведены примеры выражений XPath, которые допустимы и недопустимы для определения индекса диапазона пути.
Избегайте создания нескольких индексов пути, которые заканчиваются одним и тем же элементом / атрибутом, поскольку производительность приема ухудшается из-за количества индексов пути, заканчивающихся общим элементом / атрибутами.
Действителен | Неверно |
---|---|
// а | ./a |
/ а / б / с | / a / b [c = / p / q] |
/ a / b [c] | / a / b [c = 5 + 3] |
/ a / b [c = 5 и b = 3] | |
/ a / b [1] | |
// a / b [c <5] | |
// a / b [c = "test"] | |
/ а / * / с | |
а / б | |
/ а [./ b] / c | / a [/ b] / c |
а | |
/ a / (b | c) | / a / (/ b | / c) |
(/ a / b / c) [2] | |
автор [first-name = "John"] [last-name = "Smith"] | |
автор [first-name = "John" and last-name = "Smith"] | |
автор [first-name = "John" или first-name = "Sam"] | |
| |
/a/(./b | c) / d | / a / (/ a / b | / a / c) / d |
/ а / ребенок :: * / б | / a / parent :: * / b |
/ a [fn: match (@expr, 'is')] | / a / [fn: соответствует (fn: name (.), «Джо»)] |
/ a / fn: содержит («это») | /a/[fn:contains(fn:name(.),"Bob ")] |
Префиксы пространства имен разрешены во всех допустимых выражениях пути. Обратите внимание, что вы также можете использовать fn: match и fn: contains как часть выражения пути, но вы не можете использовать другие функции в выражении пути. Используйте cts: valid-index-path, чтобы проверить, действительно ли выражение пути для пути индекса.
Проверка допустимости выражения пути индекса
Вы можете использовать функцию XQuery cts: valid-index-path, чтобы проверить, можно ли использовать выражение XPath для определения индекса диапазона пути.Чтобы проверить правильность, скопируйте следующий запрос в Консоль запросов, измените его, чтобы использовать выражение пути, и запустите его.
xquery версия "1.0-ml"; cts: valid-index-path ("/ a / b", fn: true ())
Используйте второй параметр, чтобы указать, нужно ли проверять, настроены ли определения привязки пространства имен для префиксов пространства имен, используемых в выражении пути.
Просмотр настроек индекса диапазона элементов
Чтобы просмотреть индексы диапазона элементов, которые будут применяться к документам по мере их загрузки или переиндексации, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, индекс диапазона которой вы хотите просмотреть, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите просмотреть индекс диапазона.
- Щелкните значок «Индексы диапазона элементов».
Откроется страница конфигурации индекса элемента.
Определение индексов диапазона элементов
Чтобы определить индекс диапазона для элемента XML или свойства JSON, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать индекс диапазона, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать индекс диапазона.
- Щелкните значок «Индексы диапазона элементов» в древовидном меню под выбранной базой данных.
- Щелкните вкладку Добавить. На странице конфигурации добавления индексов диапазона отображается:
- Выберите тип элемента XML или свойства JSON, для которого вы хотите построить индекс диапазона.
- Если индекс имеет тип
xs: string
, появится поле сопоставления с сопоставлением по умолчанию. Если вы хотите, чтобы в индексе использовалось сопоставление, отличное от значения по умолчанию, введите URI сопоставления. Вы можете нажать кнопку «Построитель сопоставления», чтобы открыть мастер, который построит для вас URI сопоставления на основе языка и других вводимых параметров. Дополнительные сведения о сопоставлениях см. В главе «Поддержка языков в MarkLogic Server» в Руководстве разработчика Search . - Введите URI пространства имен элемента XML.Пропустите этот шаг, чтобы получить индекс свойств JSON.
Каждый элемент XML связан с пространством имен. Чтобы описание элемента было точным, необходимо указать пространство имен элемента XML. Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите имя элемента или свойства JSON в поле localname.
Локальное имя - это имя индексируемого элемента XML.Если у вас есть более одного элемента одного типа в одном пространстве имен, которое вы хотите проиндексировать, вы можете предоставить список имен элементов, разделенных запятыми.
- Выберите, нужно ли индексировать позиции значений диапазона для этого индекса. Установка позиций значений диапазона на
, истина
ускорит выполнение поиска, в котором используются cts: near-query и cts: element-query с этим индексом, но будет использоваться больше дискового пространства, чем при отключенных позициях (позиции значений диапазонаfalse
) . - В поле недопустимых значений выберите, разрешить ли вставку документов, содержащих элементы или свойства JSON, для которых настроен индекс диапазона, но значение этих элементов не может быть приведено к типу данных индекса. Его можно настроить для
игнорирования
илиотклонения
. По умолчанию сервер отклоняет вставку таких документов. Однако, если вы настроили недопустимые значения для, игнорировать
, документы, содержащие недопустимые значения элементов или свойств JSON, могут быть вставлены, но недопустимые значения не будут индексироваться.Запросы диапазона и функции лексики, которые в основном работают вне индекса диапазона, игнорируют существование таких документов в базе данных. - Чтобы добавить дополнительные индексы, нажмите кнопку «Другие элементы» и повторите шаги с 6 по 11 для каждого индекса по мере необходимости.
- Прокрутите вверх или вниз и нажмите ОК.
В базу данных добавлен новый индекс диапазона элементов или словарный запас слов элемента. Эти правила применяются к документам XML и JSON, загружаемым в указанную базу данных с этого момента.
Если вы включили переиндексирование для базы данных и указали элемент, который существует в документе, переиндексация будет выполняться в фоновом режиме. После завершения переиндексации новый индекс станет доступным для запросов.
Просмотр настроек индекса диапазона атрибутов
Чтобы просмотреть индексы диапазона атрибутов, которые будут применяться к документам по мере их загрузки или переиндексации, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите просмотреть индекс диапазона, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите просмотреть индекс диапазона.
- Щелкните значок Индексы диапазона атрибутов в древовидном меню под выбранной базой данных.
Откроется страница конфигурации индекса диапазона атрибутов.
Определение индексов диапазона атрибутов
Чтобы определить индекс диапазона для атрибута конкретного элемента, выполните следующие действия:
- Щелкните значок «Базы данных» в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать индекс, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать индекс.
- Под выбранной базой данных щелкните значок Индексы диапазона атрибутов в древовидном меню для индекса диапазона атрибутов.
- Щелкните вкладку Добавить. На странице "Добавить индексы диапазона атрибутов" отображается:
- Выберите тип атрибута XML, для которого вы хотите построить индекс диапазона атрибутов.
- Если индекс имеет тип
xs: string
, появится поле сопоставления с сопоставлением по умолчанию. Если вы хотите, чтобы в индексе использовалось сопоставление, отличное от значения по умолчанию, введите URI сопоставления. Вы можете нажать кнопку «Построитель сопоставления», чтобы открыть мастер, который построит для вас URI сопоставления на основе языка и других вводимых параметров. Дополнительные сведения о сопоставлениях см. В главе «Поддержка языков в MarkLogic Server» в Руководстве разработчика Search . - Введите URI пространства имен элемента XML, который содержит атрибут, который вы хотите проиндексировать, в поле URI родительского пространства имен.
Каждый элемент XML связан с пространством имен. Чтобы описание элемента было точным, необходимо указать пространство имен элемента XML. Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите имя элемента в поле родительского локального имени.
Локальное имя - это имя элемента XML, который содержит индексируемый атрибут. Если у вас есть более одного элемента в одном пространстве имен, которое содержит атрибут, который вы хотите проиндексировать, вы можете предоставить список имен элементов, разделенных запятыми.
- Введите URI пространства имен атрибута, который вы хотите проиндексировать, в поле URI пространства имен.
Каждый атрибут XML связан с пространством имен. Чтобы описание атрибута было точным, необходимо указать пространство имен атрибута XML. Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите имя атрибута в поле локального имени.
Локальное имя - это имя индексируемого XML-атрибута. Если у вас есть более одного атрибута в одном пространстве имен в указанном родительском элементе (ах), который вы хотите проиндексировать, вы можете предоставить список имен атрибутов, разделенных запятыми.
- Выберите, нужно ли индексировать позиции значений диапазона для этого индекса. Установка значения
true
ускорит выполнение поиска, в котором используются cts: near-query и cts: element-query с этим индексом, но будет использоваться больше дискового пространства, чем при отключенных позициях (позиции значения диапазонаfalse
). - В поле недопустимых значений выберите, следует ли разрешить вставку документов, содержащих атрибуты, для которых настроен индекс диапазона, но значение этих атрибутов не может быть приведено к типу данных индекса. Его можно настроить для
игнорирования
илиотклонения
. По умолчанию сервер отклоняет вставку таких документов. Однако, если вы настроили недопустимые значения на, игнорировать
, документы, содержащие недопустимые атрибуты, могут быть вставлены, но недопустимые значения атрибутов не будут индексироваться.Запросы диапазона и функции лексики, которые в основном работают вне индекса диапазона, игнорируют существование таких документов в базе данных. - Чтобы добавить дополнительные индексы, нажмите кнопку «Другие элементы» и повторите шаги с 6 по 13 для каждого индекса атрибута по мере необходимости.
- Прокрутите вверх или вниз и нажмите ОК.
Новый индекс атрибута добавлен в базу данных. Эти правила применяются к XML-документам, загружаемым в указанную базу данных с этого момента.
Если вы включили переиндексирование для базы данных и указали пару элемент-атрибут, которая существует в документе, переиндексация будет выполняться в фоновом режиме. После завершения переиндексации новый индекс станет доступным для запросов.
Просмотр настроек индекса диапазона путей
Для просмотра индексов диапазона путей, которые будут применяться к документам по мере их загрузки или переиндексации, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите просмотреть индекс диапазона, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите просмотреть индекс диапазона.
- Щелкните значок Индексы диапазона путей в древовидном меню под выбранной базой данных.
Откроется страница конфигурации индекса диапазона пути.
Определение префиксов пространства имен, используемых в индексах и полях диапазона пути
Когда вы определяете индекс диапазона пути для документов XML и ваш путь использует префиксы пространства имен, вы должны предварительно определить любые привязки пространства имен, используемые в выражении пути.Эти привязки пространств имен могут использоваться несколькими индексами диапазона путей.
Чтобы определить привязку пространства имен, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать привязку префикса пространства имен, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать привязку пространства имен.
- Щелкните значок Пространства имен путей в древовидном меню под выбранной базой данных.
- Щелкните вкладку Добавить. На странице конфигурации пространств имен путей отображается:
- В поле «Префикс» введите префикс пространства имен, который вы собираетесь использовать для элемента или атрибута в выражении XPath в индексе диапазона путей.
- В поле URI пространства имен введите URI пространства имен элемента или атрибута XML в выражении XPath.
- Нажмите ОК.
Определение индексов диапазона путей
Чтобы определить индекс диапазона, выраженный выражением XPath, выполните следующие шаги:
- Если вы создаете индекс диапазона путей для данных XML, создайте привязки для любых префиксов пространств имен, используемых в вашем индексе XPath выражение.Дополнительные сведения см. В разделе «Определение префиксов пространства имен, используемых в индексах и полях диапазона пути».
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать индекс диапазона, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать индекс диапазона.
- Щелкните значок Индексы диапазона путей в древовидном меню под выбранной базой данных.
- Щелкните вкладку Добавить.На странице конфигурации индекса диапазона пути отображается:
- Выберите тип элемента XML, атрибута XML или свойства JSON, для которого вы хотите построить индекс диапазона.
- Если индекс имеет тип
xs: string
, появится поле сопоставления с сопоставлением по умолчанию. Если вы хотите, чтобы в индексе использовалось сопоставление, отличное от значения по умолчанию, введите URI сопоставления. Вы можете нажать кнопку «Построитель сопоставления», чтобы открыть мастер, который построит для вас URI сопоставления на основе языка и других вводимых параметров.Дополнительные сведения о сопоставлениях см. В главе «Поддержка языков в MarkLogic Server» в Руководстве разработчика Search . - Введите выражение XPath в поле выражения пути. Для XML можно использовать любой префикс пространства имен, созданный на шаге 1. Выражения XPath обобщены в Кратком справочнике XPath в Справочном руководстве по XQuery и XSLT . Не все возможности XPath поддерживаются индексами диапазона путей. Дополнительные сведения см. В разделе «Общие сведения об индексах диапазона пути».
Вы можете использовать функцию cts: valid-index-path, чтобы проверить, является ли путь синтаксически правильным для использования в индексе диапазона путей.
У вас не может быть пути через корень фрагмента. Пути должны быть ограничены корнями фрагментов
- Выберите, нужно ли индексировать позиции значений диапазона для этого индекса. Установка значения
true
ускорит выполнение поиска, использующего cts: near-query,cts: element-query
и cts: json-property-scope-query с этим индексом, но будет использовать больше дискового пространства, чем выход из позиций (диапазон значений позиций, ложь
). - В поле недопустимых значений выберите, разрешить ли вставку документов, содержащих элементы XML, атрибуты XML или свойства JSON, для которых настроен индекс диапазона, но значение этих элементов, атрибутов или свойств не может быть приведено к данным индекса. тип.Его можно настроить для
игнорирования
илиотклонения
. По умолчанию сервер отклоняет вставку таких документов. Однако, если вы настроили недопустимые значения на, игнорировать
, документы, содержащие недопустимые такие значения, могут быть вставлены, но недопустимые значения не будут индексироваться. Запросы диапазона и функции лексики, которые в основном работают вне индекса диапазона, игнорируют существование таких документов в базе данных. - Чтобы добавить дополнительные индексы, нажмите кнопку «Другие элементы» и повторите шаги с 7 по 11 для каждого индекса по мере необходимости.
- Прокрутите вверх или вниз и нажмите ОК.
Новый индекс диапазона путей добавлен в базу данных. Эти правила применяются к документам XML или JSON, загружаемым в указанную базу данных с этого момента.
Если вы включили переиндексирование для базы данных и указали элемент XML, атрибут XML или свойство JSON, которые существуют в документе, переиндексация будет выполняться в фоновом режиме. После завершения переиндексации новый индекс станет доступным для запросов.
После того, как вы создали индекс диапазона путей, вы не можете изменить выражение пути. Вместо этого необходимо удалить существующий индекс диапазона путей и создать новый с обновленным выражением пути.
Просмотр параметров словаря слов элемента
Чтобы просмотреть словарь, который будет применяться к документам по мере их загрузки или переиндексации, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, индекс диапазона или лексику которой вы хотите просмотреть, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, словарь которой вы хотите просмотреть.
- Щелкните значок Словари слов элемента.
Откроется страница настройки словаря слова элемента.
Определение словаря слов элемента
Чтобы определить словарь для элемента XML или свойства JSON, выполните следующие действия:
- Щелкните значок «Базы данных» в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать словарь, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать словарь.
- Щелкните значок Словари слов элемента в древовидном меню под выбранной базой данных.
- Щелкните вкладку Добавить. На странице конфигурации Element Word Lexicon отображается:
- Если вы определяете лексику для элемента XML, введите URI пространства имен элемента XML.
Каждый элемент XML связан с пространством имен. Чтобы описание элемента было точным, необходимо указать пространство имен элемента XML.Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите элемент XML или имя свойства JSON в поле localname.
Локальное имя - это имя элемента XML или свойства JSON для индексации. Если у вас есть несколько элементов одного типа в одном пространстве имен, которое вы хотите проиндексировать, или несколько имен свойств, вы можете предоставить список имен, разделенных запятыми.
- Появится поле сортировки с параметрами сортировки по умолчанию. Если вы хотите, чтобы в лексиконе использовалось сопоставление, отличное от значения по умолчанию, введите URI сопоставления. Вы можете нажать кнопку «Построитель сопоставления», чтобы открыть мастер, который построит для вас URI сопоставления на основе языка и других вводимых параметров. Дополнительные сведения о сопоставлениях см. В главе «Поддержка языков в MarkLogic Server» в Руководстве разработчика Search .
- Чтобы добавить дополнительные словари, нажмите кнопку «Другие элементы» и повторите шаги с 6 по 8 для каждого словаря по мере необходимости.
- Прокрутите вверх или вниз и нажмите ОК.
Новый индекс диапазона или словарный запас добавлен в базу данных. Эти правила применяются к документам XML или JSON, загружаемым в указанную базу данных с этого момента.
Если вы включили переиндексирование для базы данных и указали элемент, который существует в документе, переиндексация будет выполняться в фоновом режиме. После завершения переиндексации новый индекс станет доступным для запросов.
Просмотр настроек словаря слов атрибутов
Чтобы просмотреть словарь, который будет применяться к документам по мере их загрузки или переиндексации, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, словарь которой вы хотите просмотреть, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, словарь которой вы хотите просмотреть.
- Щелкните значок Словари слов атрибутов в древовидном меню под выбранной базой данных.
Откроется страница словаря слов элемента и атрибута.
Определение словаря слов атрибута
Чтобы определить словарь для атрибута конкретного элемента, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите создать словарь, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите создать словарь.
- Под выбранной базой данных щелкните значок Словарь слов атрибута.
- Щелкните вкладку Добавить. На странице «Конфигурация словаря слова элемента и атрибута» отображается:
- Введите URI пространства имен элемента XML, который содержит атрибут, который вы хотите проиндексировать, в поле URI родительского пространства имен.
Каждый элемент XML связан с пространством имен. Чтобы описание элемента было точным, необходимо указать пространство имен элемента XML. Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите имя элемента в поле родительского локального имени.
Локальное имя - это имя элемента XML, который содержит индексируемый атрибут. Если у вас есть более одного элемента в одном пространстве имен, которое содержит атрибут, который вы хотите проиндексировать, вы можете предоставить список имен элементов, разделенных запятыми.
- Введите URI пространства имен атрибута, который вы хотите проиндексировать, в поле URI пространства имен.
Каждый атрибут XML связан с пространством имен. Чтобы описание атрибута было точным, необходимо указать пространство имен атрибута XML. Звездочка (*) не может использоваться для обозначения независимости пространства имен. Если оставить поле URI пространства имен пустым, будет указано универсальное безымянное пространство имен.
- Введите имя атрибута в поле локального имени.
Локальное имя - это имя индексируемого XML-атрибута. Если у вас есть более одного атрибута в одном пространстве имен в указанном родительском элементе (ах), который вы хотите проиндексировать, вы можете предоставить список имен атрибутов, разделенных запятыми.
- Появится поле сортировки с параметрами сортировки по умолчанию. Если вы хотите, чтобы в лексиконе использовалось сопоставление, отличное от значения по умолчанию, введите URI сопоставления. Вы можете нажать кнопку «Построитель сопоставления», чтобы открыть мастер, который построит для вас URI сопоставления на основе языка и других вводимых параметров.Дополнительные сведения о сопоставлениях см. В главе «Поддержка языков в MarkLogic Server» в Руководстве разработчика Search .
- Чтобы добавить дополнительные словари слов «элемент-атрибут», нажмите кнопку «Дополнительные элементы» и повторите шаги с 6 по 10 для каждого индекса атрибута по мере необходимости.
- Прокрутите вверх или вниз и нажмите ОК.
В базу данных добавлен новый индекс атрибута или словарный запас слов атрибута. Эти правила применяются к XML-документам, загружаемым в указанную базу данных с этого момента.
Если вы включили переиндексирование для базы данных и указали пару элемент-атрибут, которая существует в документе, переиндексация будет выполняться в фоновом режиме. После завершения переиндексации новый индекс станет доступным для запросов.
Определение лексиконов значений
Лексиконы значений реализуются с использованием индексов диапазона типа xs: string
для элементов, атрибутов, свойств JSON или полей, указанных в запросе. Следовательно, чтобы создать словарь значений, вы создаете индекс диапазона типа xs: string
для указанного элемента (ов), атрибута (ов), свойств JSON или полей.Используйте индекс диапазона элементов для словаря значений свойств JSON.
Удаление индексов или словарей диапазона
Чтобы удалить индексы или словари элементов или атрибутов для определенной базы данных, выполните следующие действия:
- Щелкните значок Базы данных в левом древовидном меню.
- Найдите базу данных, для которой вы хотите удалить индекс диапазона или словарный запас, в древовидном меню или в сводной таблице базы данных.
- Щелкните имя базы данных, для которой вы хотите удалить индекс диапазона или словарный запас.
- Определите, нужно ли удалить индекс диапазона элементов, индекс диапазона атрибутов, словарь слов элемента или словарь слов атрибутов.
- Щелкните значок «Указатель диапазона элемента», значок «Указатель диапазона атрибута», значок «Указатель диапазона пути», значок «Словарь слов элемента» или значок «Словарь слов атрибута». Откроется страница конфигурации для соответствующего индекса.
- Найдите индекс, который вы хотите удалить, и нажмите «Удалить».
- Отображается подтверждающее сообщение.Подтвердите удаление и нажмите ОК.
Индекс или словарный запас удален из базы данных.
Определение индексов диапазона полей
Поля предоставляют удобный механизм для запроса части базы данных на основе XML-элемента QNames или имен свойств JSON. Вы можете определить поле, а затем создать над ним индекс диапазона или словарный запас или словарный запас значений. Дополнительные сведения см. В разделе «Настройки базы данных полей».
Управление индексами - Руководство MongoDB
const pipeline = [ {$ indexStats: {}}, {группа , indexDoc: {$ push: "$$ ROOT"}, allShards: {$ addToSet: "$ shard"}}}, {$ unwind: "$ indexDoc"}, { $ group: { "_id": "$ indexDoc.name ", " shards ": {$ push:" $ indexDoc.shard "}, " specs ": {$ push: {$ objectToArray: {$ ifNull : ["$ indexDoc.spec", {}]}}}, "allShards": {$ first: "$ allShards"} } }, { $ project: { missingFromShards: {$ setDifference: ["$ allShards", "$ shards"]}, inconsistentProperties: inconsistentProperties setDifference: [ {$ reduce: { input: "$ specs", initialValue: {$ arrayElem По адресу: ["$ specs", 0]}, in: {$ setUnion: ["$$ value", "$$ this"]}}}, {$ reduce: { ввод: "$ specs", initialValue: {$ arrayElemAt: ["$ specs", 0]}, in: {$ setIntersection: ["$$ value", "$$ this "]}}} ] } } }, { { $ expr: {$ или: [ {$ gt: [{$ size: "$ missingFromShards"}, 0]}, {$ gt: [{$ size: " $ inconsis tentProperties "}, 0]}, ] } } }, {$ project: {_Name: $ 0: $ project: {_Nid: $ 0 $ ROOT._id ", inconsistentProperties: 1, missingFromShards: 1}} ];
Индексирование фильтров LIKE (насколько это возможно)
Очень часто предикаты фильтра индекса указывают на неправильное использование индекса вызвано неправильным порядком столбцов в объединенном индексе. тем не менее предикаты индексного фильтра также могут использоваться по уважительной причине - не для того, чтобы повысить производительность сканирования диапазона, но сгруппировать данные, к которым последовательно осуществляется доступ все вместе.
Где пункт
предполагает, что
не может служить предикатом доступа - хорошие кандидаты для этого
техника:
ВЫБЕРИТЕ first_name, last_name, secondary_id, phone_number
ОТ сотрудников
ГДЕ secondary_id =?
AND UPPER (last_name) LIKE '% INA%'
Помните, что LIKE
выражений с ведущими подстановочными знаками
не может использовать индексное дерево.Это означает, что
indexing LAST_NAME
не сужает диапазон отсканированного индекса - нет
независимо от того, индексируете ли вы LAST_NAME
или ВЕРХНИЙ (фамилия)
. Следовательно, это состояние никуда не годится
кандидат на индексацию.
Однако условие на SUBSIDIARY_ID
хорошо подходит
для индексации. Нам даже не нужно добавлять новый индекс, потому что SUBSIDIARY_ID
уже является ведущим столбцом в индексе для
первичный ключ.
- DB2
Объясните план -------------------------------------------------- ---------- ID | Операция | Ряды | Расходы 1 | ВОЗВРАТ | | 40 2 | НАЙТИ СОТРУДНИКОВ | 33 из 333 (9.91%) | 40 3 | RIDSCN | 333 из 333 (100,00%) | 12 4 | СОРТИРОВКА (УНИКАЛЬНАЯ) | 333 из 333 (100,00%) | 12 5 | IXSCAN EMPLOYEES_PK | 333 из 10000 (3,33%) | 12 Информация о предикатах 2 - SARG (Q1.SUBSIDIARY_ID =?) SARG (UPPER (Q1.LAST_NAME) LIKE '% INA%') 5 - НАЧАЛО (Q1.SUBSIDIARY_ID =?) СТОП (Q1.SUBSIDIARY_ID =?)
- Oracle
--------------------------------- ------------------------------ | Id | Операция | Имя | Ряды | Стоимость | -------------------------------------------------- ------------- | 0 | ВЫБРАТЬ ЗАЯВЛЕНИЕ | | 17 | 230 | | * 1 | ДОСТУП К ТАБЛИЦЕ ПО ИНДЕКСУ ROWID | СОТРУДНИКИ | 17 | 230 | | * 2 | СКАНИРОВАНИЕ ДИАПАЗОНА ИНДЕКСА | EMPLOYEEs_PK | 333 | 2 | -------------------------------------------------- ------------- Информация о предикате (определяется идентификатором операции): -------------------------------------------------- - 1 - фильтр (UPPER ("LAST_NAME") LIKE '% INA%') 2 - доступ ("SUBSIDIARY_ID" = TO_NUMBER (: A))
В приведенном выше плане выполнения стоимость увеличивается в сто раз.
от INDEX RANGE SCAN
до следующей таблицы ДОСТУП ПО ИНДЕКСУ ROWID
.Другими словами: доступ к таблице
вызывает больше всего работы. На самом деле это обычная закономерность, и это не проблема.
сам по себе. Тем не менее, это самый значительный вклад в
общее время выполнения этого запроса.
Доступ к таблице не обязательно является узким местом, если доступ к строки хранятся в одном блоке таблицы, потому что база данных может получить все строк за одну операцию чтения. Если одни и те же строки распределены по многим различные блоки, напротив, доступ к таблице может стать серьезным проблема с производительностью, потому что база данных должна получить много блоков по порядку чтобы получить все строки.Это означает, что производительность зависит от физическое распределение доступных строк - другими словами: это зависит от кластеризация строк.
Note
Корреляция между порядком индексации и порядком таблицы тест производительности - так называемая кластеризация индекса фактор .
Фактически можно улучшить производительность запросов, переупорядочив строки в таблице, чтобы они соответствовали порядку индекса. Этот способ однако редко применяется, потому что вы можете хранить только строки таблицы в одной последовательности.Это означает, что вы можете оптимизировать таблицу только для одного индекса. Даже если вы можете выбрать один индекс, для которого вы хотели бы оптимизировать таблицу, это все еще сложная задача, потому что большинство баз данных предлагайте только элементарные инструменты для этой задачи. Так называемый ряд В конце концов, секвенирование - довольно непрактичный подход.
Это именно то место, где секундная степень indexing - данные кластеризации. Вы можете добавить много столбцов в индекс, чтобы они автоматически сохранялись в четко определенном порядке.Это делает индекс мощным, но простым инструментом для кластеризации данных.
Чтобы применить эту концепцию к вышеуказанному запросу, мы должны расширить индекс
для покрытия всех столбцов от , где
предложение - даже если они не сужают диапазон сканирования индекса:
CREATE INDEX empsubupnam ON сотрудников
(secondary_id, UPPER (last_name) )
Столбец SUBSIDIARY_ID
является первым столбцом индекса, поэтому
его можно использовать как предикат доступа.Выражение UPPER (last_name)
покрывает фильтр LIKE
как предикат фильтра индекса . Индексирование верхнего регистра
представление экономит несколько циклов ЦП во время выполнения, но прямое
index на LAST_NAME
также будет работать. Вы узнаете больше о
это в следующем разделе.
- DB2
Объясните план -------------------------------------------------- ------ ID | Операция | Ряды | Расходы 1 | ВОЗВРАТ | | 15 2 | НАЙТИ СОТРУДНИКОВ | 0 из 0 | 15 3 | IXSCAN EMPSUBUPNAM2 | 0 из 10000 (.00%) | 15 Информация о предикатах 3 - НАЧАЛО (Q1.SUBSIDIARY_ID =?) СТОП (Q1.SUBSIDIARY_ID =?) SARG (Q1.LAST_NAME LIKE '% INA%')
Чтобы получить желаемый план выполнения, мне пришлось удалить
UPPER
из индекса и, где
-пункт. Начиная с DB2 LUW 10.5, индексирование на основе функций - довольно свежая функция - кажется, оптимизатор еще не полностью осознает это. Далее, используя соответствующие сопоставления для получения нечувствительного к регистру поведения в любом случае лучший вариант в DB2.- Оракул
------------------------------------------ -------------------- | Id | Операция | Имя | Ряды | Стоимость | -------------------------------------------------- ------------ | 0 | ВЫБРАТЬ ЗАЯВЛЕНИЕ | | 17 | 20 | | 1 | ДОСТУП К ТАБЛИЦЕ ПО ИНДЕКСУ ROWID | СОТРУДНИКИ | 17 | 20 | | * 2 | СКАНИРОВАНИЕ ДИАПАЗОНА ИНДЕКСА | EMPSUBUPNAM | 17 | 3 | -------------------------------------------------- ------------ Информация о предикате (определяется идентификатором операции): -------------------------------------------------- - 2 - доступ ("SUBSIDIARY_ID" = TO_NUMBER (: A)) filter (UPPER ("LAST_NAME") LIKE '% INA%')
Новый план выполнения показывает те же самые операции, что и раньше.В
Тем не менее себестоимость значительно снизилась. В предикатной информации
мы видим, что фильтр LIKE
уже применяется во время СКАНИРОВАНИЕ ДИАПАЗОНА ИНДЕКСА
. Ряды, не соответствующие
Фильтр LIKE
сразу отбрасывается. Доступ к таблице делает
больше не иметь никаких предикатов фильтра. Это означает, что он не загружает строки
которые не соответствуют , где
пункт.
Разница между двумя планами выполнения четко видна в
столбец «Строки».По оценке оптимизатора, запрос
в конечном итоге соответствует 17 записям. Сканирование индекса в первом плане выполнения
тем не менее обеспечивает 333 ряда. Затем база данных должна загрузить эти 333 строки.
из таблицы, чтобы применить фильтр LIKE
, который уменьшает
довести до 17 рядов. Во втором плане выполнения доступ к индексу не
доставить эти строки в первую очередь, поэтому база данных должна выполнить ДОСТУП К ТАБЛИЦЕ ПО ИНДЕКСУ ROWID
только 17 раз.
Следует также отметить, что стоимость ИНДЕКСА ДИАПАЗОН
Операция SCAN
выросла с двух до трех, поскольку дополнительный столбец
увеличивает индекс. С точки зрения прироста производительности это
приемлемый компромисс.
Предупреждение
Не вводите новый индекс с единственной целью фильтровать предикаты. Вместо этого расширьте существующий индекс и сократите затраты на обслуживание. С участием некоторые базы данных вы даже можете добавить столбцы в индекс для основного ключ, не являющийся частью первичного ключа.
Следующая анимация демонстрирует разницу между двумя планами выполнения:
Рисунок 5.1 Предикаты фильтра преднамеренного индекса
Этот тривиальный пример, кажется, подтверждает распространенную мудрость индексировать
каждый столбец из , где пункт
.
Однако эта «мудрость» игнорирует релевантность порядка столбцов, который
определяет, какие условия могут использоваться в качестве предикатов доступа и, таким образом, имеет
огромное влияние на производительность. Решение о порядке столбцов должно
поэтому никогда не оставляйте на волю случая.