Не знам за вътрешните елементи на Microsoft SQL Server, но мога да отговоря за MySQL, който сте маркирали за вашия въпрос. Подробностите могат да варират за други реализации.
Q1. Точно така, не е необходимо допълнително място за клъстерирания индекс.
Какво се случва, ако изпуснете клъстерирания индекс? Машината InnoDB на MySQL винаги използва първичния ключ (или първия ненулев уникален ключ) като клъстериран индекс. Ако дефинирате таблица без първичен ключ или изпуснете първичния ключ на съществуваща таблица, InnoDB генерира вътрешен изкуствен ключ за клъстерирания индекс . Този вътрешен ключ няма логическа колона за препратка към него.
В2. Редът на редовете, върнати от заявка, която използва неклъстериран индекс, не е гарантирана. На практика това е редът, в който се осъществява достъп до редовете. Ако имате нужда от връщане на редове в определен ред, трябва да използвате ORDER BY във вашето запитване. Ако оптимизаторът може да заключи, че желаният от вас ред е същият като реда, в който ще има достъп до редовете (ред на индекса, независимо дали чрез клъстериран или неклъстериран индекс), тогава може да пропусне стъпката за сортиране.
В3. Неклъстерираният индекс на InnoDB няма указател към съответния ред в лист от индекса, той има стойност на първичния ключ. Така че търсенето в неклъстериран индекс всъщност представлява две търсения в B-дърво, първото за намиране на листа на неклъстерирания индекс и след това второ търсене в клъстерирания индекс.
Това е двойно по-скъпо от едно търсене в B-дърво (повече или по-малко), така че InnoDB има допълнителна функция, наречена Адаптивен хеш индекс . Често търсените стойности се кешират в AHI и следващия път, когато заявка търси кеширана стойност, тя може да направи търсене O(1). В кеша AHI той намира указател директно към листа на клъстерирания индекс, така че елиминира и двете Търсене в B-дърво, част от времето.
Доколко това подобрява общата производителност зависи от това колко често търсите едни и същи стойности, които са били търсени преди. Според моя опит е типично съотношението между търсенията на хеш спрямо търсенията без хеш да бъде около 1:2.
Q4. Създайте индекси, за да обслужват заявките, които трябва да бъдат оптимизирани. Обикновено клъстерираният индекс е първичен или уникален ключ и поне в случая на InnoDB това е задължително. Нито age нито salary вероятно ще бъде уникален.
Може да ви хареса моята презентация, Как да проектирате индекси, наистина .
В5. InnoDB автоматично създава индекс, когато декларирате уникално ограничение. Не можете да имате ограничението без съществуващ индекс за него. Ако нямате индекс, как механизмът ще гарантира уникалност, когато вмъкнете стойност? Ще трябва да потърси цялата таблица за дублирана стойност в тази колона. Индексът помага да се направят уникалните проверки много по-ефективни.
