Hoe is deze records/fanout-logica afgeleid voor het geval zonder statistieken in de Query Planner van MySQL?

Als u absoluut geen gegevens heeft over uw probleem, bent u genoodzaakt een schatting te maken.

De algemene vorm van die formule wordt uitgelegd in de opmerkingen:

• als we slechts één sleutelkolom gebruiken (x ) van een index met meerdere kolommen (met c kolommen), krijgen we a rijen (1% van het totaal aantal rijen). Dus voor x=1 , het resultaat is a per definitie.
• als we de waarde weten voor elke sleutelkolom van een index met meerdere kolommen, krijgen we het aantal rijen per hele sleutel (b ); dus voor x=c , krijgen we b rijen (dat is 1 of 10 ) per definitie.
• tussenin (als we sleutelwaarden gebruiken voor meer dan 1 sleutelkolom, maar niet alle), voor elke extra bekende sleutelwaarde, kunnen we enkele extra rijen uitsluiten:we hebben a-b rijen die niet behoren tot het geval waarin we onze volledige . kennen sleutel (die b . zou hebben rijen), en per definitie worden ze uitgesloten in verhouding tot de verhouding van bruikbare sleutelkolommen ((x-1)/(c-1) ).
• De -1 in (x-1)/(c-1) is slechts een verschuiving (u kunt gewoon verschillende namen van variabelen gebruiken), omdat we alleen de extra hoeven te tellen kolommen, maar c en x is de telling inclusief de eerste kolom. (In een tijdreeks noem je de parameter voor de eerste kolom t=0 , en de -1 doet precies dat).

Dus tot slot krijgen we a - (a-b) * (x-1)/(c-1) (a voor de eerste sleutelkolom minus de rijen die we proportioneel uitsluiten). Dit is (als je die uitdrukking een beetje transformeert) precies de gegeven formule. Een snelle sanity check:voor x=1 (x-1=0 ), de tweede term is 0 en we krijgen a , zoals gedefinieerd door de eerste voorwaarde; voor x=c , krijgen we a-(a-b)=b zoals gedefinieerd door de tweede voorwaarde.

Het is niet onredelijk om deze ansatz te maken met deze aannames, maar je kunt waarschijnlijk een andere formule vinden die net zo logisch is. Beweren dat het beter is, zou echter een moeilijkere taak zijn.

Dan is er nog de kwestie van het kiezen van de waarden (b=10 en 1% in dit geval). U kunt uiteraard elke waarde kiezen. Om dit te doen zonder betrouwbare gegevens, behalve een onderbuikgevoel, is er een concept genaamd de Fermi-schatting :

U kiest in feite alleen de orde van magniet (1, 1000000, 1/100) voor uw invoerparameters, en u krijgt een redelijke orde van grootte voor uw resultaat.

Dus hoeveel rijen verwacht u dat een niet-unieke sleutel dekt? Het is meer dan 1, anders zou je er een unieke sleutel van maken, maar is het meer 2, 10 of 100? 10 is waarschijnlijk een goede gok (het dekt een waarde van ongeveer 3 tot 30 in die schatting). Dus hoewel deze cijfers afkomstig kunnen zijn van een 2 jaar durende wereldwijde enquête over sleuteldistributie, worden geschatte waarden in machten van 10 meestal op een dergelijke manier afgeleid. Als je absoluut zeker wilt zijn, vraag het dan aan de ontwikkelaar.

En de verplichte xkcd voor dit soort onderwerpen:Wat als? Verf de aarde