Здравейте, какво трябва да означава надежност на индекса? В php mysql admin има колонка с число даващо някаква представа за надеждноста на индекса. Но какво означава това число, кога е по-добре - когато е по-малко или когато е по-голямо? Какво изобщо означава "надеждност" на индекса?

Това ми звучи като изключително лош превод от рода на един филм по Discovery наскоро в който скоростта на самолета в българсикя превод се измерваше в .... ноти

"300 knots" беше преведено като "300 ноти". Направо ми се доповръща ама нямаше на кого да се оплача.


Я си пусни phpmyadmin-а на английски и кажи как се казва там това число.

Да не е cardinality например?

Съдържаниет е скрито
Влезте за да го видите

Да, за "Cardinality" става дума.

Цялата теория на релационните бази данни е изведена от теорията на множествата.

В теория на множествата се дефинира едно нещо наречено "Кардинално число" или още "мощност" на множество. За изброимо множество кардиналното число е броят на елементите в множеството.

Е когато става въпрос за кардинално число на индекс то отговаря на броя на различните стойности в индекса.

При първичния ключ например винаги е равно на броя на редовете от таблицата.

Ако пък да речем имаш индекс върху колонка Пол с допустими стойности М, Ж то въпросното кардинално число ще е равно на 2.

По принцип по-голямо "разнообразие" в стойностите на един индекс предполага по-ефективна работа на тизи индекс (защото при попадение може да се "отсеят" по-малко стойности). Това не винаги е вярно, но при равномерно разпределение на стойностите е добър ориентир за това доколко даден индекс може да е полезен.

Да наречеш това число "Надеждност" е пълна глупост!

Всъщност по-съществено е съотношението между броя на елементите и броя на уникалните елементи в индекса а не самите числа.

"Идеалното" съотношение е 1:1 какъвто е случая при Първичен Ключ или уникален индекс.

Ето ти един пример:


mysql> SELECT COUNT(*) FROM t\G
*************************** 1. row ***************************
COUNT(*): 393216
1 row in set (0.00 sec)

mysql> show index from t\G
*************************** 1. row ***************************
Table: t

Key_name: col
Column_name: col
Cardinality: 101

Това е "лош" индекс защото в него има "само" 101 уникални стойности при "цели" 393216 реда.

Ако обаче редовете в таблицата бяха примерно 125 тогава същият този индекс щеше да е "добър".

Слагав всичко в кавички защото нещата са много относителни :)

Всъщност в моя пример индексът е много добър за конкретни заявки просто защото разпределението е неравномерно, но това е друга тема.

Съдържаниет е скрито
Влезте за да го видите

Редактирано от salle на 01.04.06 00:33.

A kak moje da se promeni tova 4islo? V smisal okzava s 4e imam kardinalno 4oslo na baza danni zadadeno na 68 s na4alna stoinost na id 59 i kraina 127. Az oba4e iskam da importna danni, koito sa mnogo pove4e ot 68. Kak da promenia tova 4islo.
Blagodaria vi predvaritelno.

.

Съдържаниет е скрито
Влезте за да го видите

>> Това е "лош" индекс защото в него има "само" 101 уникални стойности при "цели" 393216 реда.

Хмм... ти ме хвърли в размисъл..
по какъв точно начин този индекс е "лош"?

Ако приемем, че тези 393 216 реда са например за таблица Orders, а 101 на брой са клиентите за тези ордери, какво лошо има в индекса ако искаш да изкараш например всички ордери на клиент Х (който има да речем 5 000 ордера)?

За сравнение, ако имаш уникален индекс по поле "Номер на ордер", тогава ще имаш максимална кардиналност, но това ще ти помогне ли ако искаш да покажеш ордерите с номера между 70 000 и 75 000 (нека са поредни, т.е. пак 5 000 на брой). Предполагам, че скоростта за изпълнение в този случай би била горе-долу същата?

Уф, стана ми любопитно какво точно е вътрешното представяне на индексите в MySql (пък и въобще, в повечето бази как е), все трябва да е обяснено някъде, ама нещо сега точно нямам много време за това.
Може би ще да е дърво по кардиналните стойности на индексираните полета, в листата на което би следвало да са изброени "указателите" към съответните записи. Тези "указатели", ако индексът не е уникален, би следвало пак да са в някаква дървовидна структура, щото иначе не ми се мисли какво обхождане би станало при update-операциите, ако бяха свързани само в свързан списък например и този списък има много елементи:). Абе както и да е, отплеснах се нещо...