Annexos

Instal·lació de PostgreSQL

Aquest petit tutorial permet instal·lar PostgreSQL 9.0.4, descarregat de l’adreça http://www.enterprisedb.com/products-services-training/pgdownload, per a un Ubuntu 10.10 a 32bits.

Assignem permisos d’execució al fitxer descarregat postgresql-9.0.4-1-linux.bin i l’executem des de la consola:

  1. sudo ./postgresql-9.0.4-1-linux.bin

Ens permetrà visualitzar la finestra de benvinguda de l’instal·lador gràfic.

Figura

Escollim el directori /opt/PostgreSQL/9.0 com a ubicació on s’instal·laran els arxius i directoris del servidor Postgres a la nostra màquina.

Figura

el directori data…

Figura

Assignem contrasenya al superusuari Postgres.

Figura

Assignem el port sobre el qual es duran a terme les comunicacions entre les aplicacions i el servidor (per defecte 5432).

Figura

Escollim la configuració local que s’assignarà en variables de configuració regional.

Figura

Figura

I comença la creació corresponent de fitxers i directoris.

Figura

Un cop finalitzada la instal·lació, l’assistent ens donarà la possibilitat d’executar Stack Builder, una aplicació que ens permetrà instal·lar altres components i eines per a PostgreSQL.

Figura

Si hem marcat l’opció de Stack Builder, s’iniciarà; seleccionem “PostgreSQL 9.0 on port 5432” i polsem “Next”.

Figura

Seleccionem les aplicacions, components i eines que volem instal·lar:

  • Slony I
  • Apache PHP
  • phpPgAdmin

i premem “Next”.

Figura

Quan el procés d’instal·lació ha finalitzat, podem comprovar si el servei Postgres està engegat.

  1. sudo netstat -putan

Especificació dels fitxers generats en la instal·lació de PostgreSQL.

La següent operació després d’instal·lar PostgreSQL és revisar el contingut dels fitxers generats en la instal·lació de Postgres. És necessari veure els continguts del directori /opt/PostgreSQL/9.0/data i entendre com estan organitzats i que conté cadascun.

  • PG_VERSION – Arxiu amb la versió de PostgreSQL.
  • base – Directori amb els subdirectoris per a cada base de dades.
  • global – Directori amb tots els subdirectoris per a tot el clúster.
  • pg_clog – Directori amb dades de transaccions.
  • pg_multixact – Directori amb dades de bloquejos compartits per fila.
  • pg_subtrans – Directori amb les dades de les transaccions.
  • pg_tblspc – Directori amb enllaços als tablespaces.
  • pg_twophase – Directori amb arxius d’estat per a transaccions preparades.
  • pg_xlog – Directori amb WAL logs.
  • postmaster.opts – Fitxer amb opcions d’arrencada d’administrador utilitzades.
  • postmaster.pid – Fitxer de bloqueig amb el PID de l’administrador i l’ID de shared mem usat.

Cada taula o índex està emmagatzemat en un arxiu independent. El número dels arxius es pot consultar al catàleg.

El catàleg de PostgreSQL

El catàleg conté una descripció de l’estructura de la base de dades i de les seves restriccions.

La informació s’emmagatzema en el catàleg com a metadades (anomenem metadadesles que permeten saber com estan definides les dades que emmagatzem). La utilitat principal és saber quines dades hi ha sense accedir-hi directament.

Aquí tenim un resum dels diferents objectes del catàleg per centrar-nos sobre el que estem parlant.

Figura Objectes del catàleg a PostgreSQL

  • pg_aggregate: funcions d’agregat
  • pg_am pg_am: mètodes índex d’accés
  • pg_amop: operadors de mètode d’accés
  • pg_amproc: accés als procediments de mètode de suport
  • pg_attrdef: valors de les columnes per defecte
  • pg_attribute: columnes de la taula (“atributs”)
  • pg_authid: identificadors d’autorització (rols)
  • pg_auth_members: relacions d’autorització identificador de membres
  • pg_cast:casts (conversions de tipus de dades)
  • pg_class: taules, índexs, seqüències, vistes (“relacions”)
  • pg_constraint: restriccions de comprovació (CHECK), les restriccions d’unicitat (UNIQUE), restriccions de clau principal (PRIMARY KEY), les restriccions de clau forana (FOREIGN KEY)
  • pg_conversion: codificació de la informació de conversió
  • pg_database: bases de dades dins d’aquest grup (CLUSTER) de base de dades
  • pg_db_role_setting: configuracions per rol i per base de dades
  • pg_default_acl: privilegis per defecte per als tipus d’objectes
  • pg_depend: dependències entre els objectes de base de dades
  • pg_description: descripcions i comentaris sobre els objectes de base de dades
  • pg_enum: etiquetes enumerades (ENUM) i definicions de valor
  • pg_foreign_data_wrapper: definicions de dades de contenidors forans
  • pg_foreign_server: definicions de servidors forans
  • pg_index: informació addicional d’índexs
  • pg_inherits: taula de jerarquia d’herència
  • pg_language: llenguatges de programació per a l’escriptura de funcions
  • pg_largeobject: pàgines de dades d’objectes grans (LOB)
  • pg_largeobject_metadata: metadades per a objectes grans (LOB)
  • pg_namespace: esquemes
  • pg_opclass: mètodes d’accés a les classes
  • pg_operator: operadors
  • pg_opfamily: famílies de mètodes d’accés
  • pg_pltemplate: dades de plantilla per als llenguatges procedimentals
  • pg_proc: funcions i procediments
  • pg_rewrite: consulta de les regles de reescriptura
  • pg_shdepend: dependències dels objectes compartits
  • pg_shdescription: comentaris sobre els objectes compartits
  • pg_statistic: planificador d’estadístiques
  • pg_tablespace: espais de taules dins d’aquest grup de base de dades
  • pg_trigger: disparadors (triggers)
  • pg_ts_config: configuracions de cerca de text
  • pg_ts_config_map: configuracions de mapatge de cerca de trossos de text
  • pg_ts_dict: diccionaris de cerca de text
  • pg_ts_parser: analitzadors de cerca de text
  • pg_ts_template: plantilles de cerca de text
  • pg_type: tipus de dades
  • pg_user_mapping: assignacions d’usuaris als servidors forans

Annex 4: Índexs a PostgreSQL

Els SGBD utilitzen índexs per accedir de manera més ràpida a les dades. L’SGBD PostgreSQL crea un índex automàticament per a cada restricció de tipus primary key i unique, i permet crear més índexs.

És lògic crear índexs per facilitar l’accés per a les columnes que necessitin accessos ràpids o molt freqüents. L’administrador de l’SGBD té, entre altres tasques, avaluar els accessos que s’efectuen a la base de dades, i decidir, si escau, establir índexs nous. Però també és tasca de l’analista i/o dissenyador de la base de dades dissenyar els índexs adequats per a les diferents taules, ja que és la persona que ha ideat la taula pensant en les necessitats de gestió dels usuaris.

La definició d’índexs és una part important del disseny físic de bases de dades i té una influència cabdal en el rendiment dels processos aplicatius que accedeixen a les bases de dades.

Com hem vist en els apartats anteriors, la majoria dels processos aplicatius en línia d’alta prioritat accedeixen a les dades per mitjà dels índexs.

Exemple d’accés a base de dades amb índex o sense

Tenim una taula de clients d’una empresa. Els atributs de cada client són el nom i cognoms, el DNI o NIF, l’adreça, el telèfon, etc.

Tenim un programa de consulta de la taula de clients. La consulta es fa a partir del DNI o NIF del client.

  1. SELECT
  2. FROM
  3. WHERE
  4. .........
  5. clients dni = :hv1

Si hi ha un índex definit sobre la columna DNI, l’optimitzador de l’SGBD molt probablement l’haurà triat com a camí d’accés òptim. En aquest cas, l’SGBD farà uns quants accessos al fitxer d’índex per seleccionar la clau i la localització de les dades. A continuació n’hi ha prou amb un accés directe a les dades per obtenir tota la informació del client sol·licitada pel programa de consulta.

Ara pensem què hauria passat si no disposéssim d’aquest índex. L’SGBD hauria hagut de llegir seqüencialment tota la taula fins a localitzar el client amb el DNI sol·licitat.

Òbviament, el fet d’accedir a la base de dades, amb índex o sense, no té importància quan es tracta de taules amb molt poques files; en canvi, el tema s’agreuja a mesura que la taula creix (pensem que hi ha taules que contenen milions de files).

Per tant, una de les raons importants per crear un índex a la taula és reduir el nombre d’accessos que l’SGBD haurà de fer per localitzar les dades.

Valdrà la pena, doncs, plantejar-nos les qüestions següents:

  • Quan hem de definir un índex?
  • Quan i com l’hem de definir des del punt de vista de rendiment?
  • Quines característiques ha de tenir?

Ja heu après a definir índexs i en quins casos és convenient de fer-ho.

A continuació, plantejarem una sèrie de consideracions que cal tenir en compte des del punt de vista del rendiment:

  1. Conveniència dels índexs
  2. Inconveniència dels índexs
  3. Altres consideracions per definir índexs eficients:
    • Índex sobre columnes molt actualitzades
    • Índexs ascendents o descendents
    • Índexs que no es fan servir per a cap programa d’aplicació
    • Exemples d’ús d’índexs
    • Exemple de creació d’índexs. Taules de l’esquema empresa
    • Optimitzador de l’SGBD

Conveniència dels índexs

És convenient definir un índex en els casos següents:

  1. Volem garantir la unicitat d’alguns atributs. Definint un índex únic, l’SGBD garanteix en tot moment que no hi ha duplicitat de valors en l’atribut. La definició dels índexs: en la majoria dels SGBD, la definició d’una columna de la taula amb l’atribut únic porta implícita la definició de l’índex. En altres SGBD, cal definir l’índex de manera explícita. La definició de les claus primàries: en la majoria dels SGBD, la definició d’una clau primària porta implícita la definició d’un índex únic i no nul (NOT NULL). En altres SGBD, cal definir l’índex de manera explícita.
  2. Volem garantir l’ordenació de les files dins la taula. Quan es defineix un índex agrupat (cluster index), l’SGBD organitza la taula seguint l’ordre de l’índex esmentat.
  3. Com hem vist en els apartats anteriors, sovint els processos aplicatius per lots, accedeixen a les taules grans de manera seqüencial. Per tant, l’elecció de l’índex agrupat té una importància cabdal. Cal elegir com a índex agrupat el que afavoreix els processos per lots crítics de més durada. En els sistemes grans, l’SGBD és molt eficient en processos seqüencials.
  4. Tenim relacions d’integritat referencial entre dues taules o més. La clau primària constitueix, obligatòriament, un índex de la taula pare. Les claus foranes formen, en la majoria dels casos, un altre índex. Pensem que entre dues taules relacionades amb integritat referencial, quan s’insereix o s’esborra una fila, en molts casos, l’SGBD ha d’anar a comprovar l’existència de la clau relacionada a l’altra taula. En aquests casos, és molt recomanable de disposar d’índex sobre les claus foranes per tal d’optimitzar els accessos de comprovació del mateix SGBD.
  5. Cal analitzar la clàusula WHERE de les sentències SQL d’accés a base de dades dels programes més importants. Si no es disposa del codi, n’hi ha prou d’analitzar el pseudocodi del programa. S’ha d’estudiar la possibilitat de millorar cada accés a la taula si es defineix un índex amb les columnes de la clàusula WHERE. D’aquest estudi surten els índexs candidats a ser definits per millorar els accessos. Cal seleccionar els índexs candidats que proporcionen més avantatges i crear-los.
  6. Hi ha processos aplicatius que utilitzen les clàusules ORDER BY o GROUP BY. Definint un índex amb les columnes que formen part de l’ORDER BY o GROUP BY, eliminem la necessitat que l’SGBD classifiqui les files, ja que l’índex proporciona l’ordre que es vol.
  7. Combinació (join) entre dues taules o més. En un procés de combinació entre dues taules, el punt més crític és la manera en què s’estableix l’enllaç entre les dues taules, per mitjà dels predicats de la clàusula WHERE. Si definim un índex a cada taula amb les columnes que formen els predicats d’enllaç, tant de la primera taula com de la segona, aconseguirem, en la majoria dels casos, que l’optimitzador triï els índexs per fer l’enllaç i, per tant, es millora el temps d’execució.
  8. És més difícil preveure quins són els índexs més útils per a les consultes (queries) no planificades. No obstant això, d’acord amb els requeriments dels usuaris, es poden preveure, inicialment, els possibles accessos i criteris de classificació més habituals. D’aquests requeriments es dedueix la necessitat d’utilitzar índexs, que cal definir si encara no existeixen. Més endavant, amb el pas del temps, aquests requeriments solen canviar i n’apareixen de nous, per la qual cosa convé replantejar la necessitat dels índexs i fer els canvis oportuns.

Inconveniència dels índexs

No és convenient definir índex en els casos següents:

1. Si la taula té poques files. O més ben dit, si les files de la taula ocupen poques pàgines. L’estructura del fitxer d’índex podria arribar a ser tan o més gran que el fitxer de dades. En aquest cas, resulta més eficient llegir unes quantes pàgines de dades en lloc de llegir l’arbre de l’índex i a continuació la pàgina de dades corresponent. Per tant, és millor, en aquest cas, que el dissenyador de la base de dades no defineixi aquest índex, perquè l’optimitzador de l’SGBD, quan fa l’anàlisi del camí òptim d’accés a la taula petita, no s’enganyi i no triï l’accés per mitjà de l’índex pensant que pot ser més eficient. Per tant, moltes vegades no cal definir índexs en taules petites. Exemples: taules de codis (taula de codis de província, taula de codis postals, etc.).

2. Si el nombre de valors diferents que pren és molt petit; és a dir, si es tracta d’un índex que discrimina molt poc. Per exemple, un índex sobre la columna sexe de la taula de clients. Es tracta d’un índex que discrimina molt poc perquè té molts duplicats. Per tant, és millor no definir aquest índex per no induir l’optimitzador a error. En algunes versions de SGBD més avançades, és el mateix optimitzador que s’adona que l’índex discrimina molt poc, i decideix no utilitzar-lo.

3. Si els programes d’aplicació pretenen d’utilitzar l’índex amb predicats no indexables, és a dir, que l’SGBD és incapaç de suportar. Suposem que hem definit un índex sobre la columna població. En cas d’aquesta SELECT, l’SGBD no pot fer servir l’índex perquè el predicat NOT EQUAL no és indexable. Per tant, en aquest cas l’índex no té utilitat. Recordem que un predicat NOT EQUAL no és indexable, mentre que el predicat EQUAL sí que ho és.

Exemple d’índex amb predicat no indexable

Volem seleccionar tots els clients de fora de la ciutat de Barcelona.

  1. SELECT
  2. FROM
  3. WHERE
  4. ......
  5. clients poblacio NOT EQUAL ‘BARCELONA’

4. Si les aplicacions fan tractaments massius de la taula.

<iocstl textE> Exemple de tractament massiu de la taula

Volem tractar tots els clients que tenen un saldo superior a un valor determinat.

  1. SELECT
  2. FROM
  3. WHERE
  4. ......
  5. clients saldo > :hv9

La taula de clients pot arribar a ser molt gran. El nombre de clients amb un saldo superior al valor especificat també pot arribar a ser molt elevat. Sabem que els grans SGBD són molt eficients en tractaments seqüencials de la base de dades. Per tant, en aquest cas, és més ràpid llegir tota la taula de clients seqüencialment que no pas llegir l’arbre d’un índex hipotètic sobre la columna saldo, per acabar llegint un nombre elevat de files de la taula de clients.

En casos com aquest, el dissenyador de la base de dades no hauria de definir cap índex sobre la columna saldo. Així, l’optimitzador de l’SGBD triarà la lectura seqüencial (sequential scan) de la taula.

Altres consideracions per definir índexs eficients

Altres consideracions per definir índexs eficients. El nombre d’índexs definits en cada taula té un cert impacte en el rendiment. Quan s’insereix una fila nova a la taula, l’SGBD actualitza automàticament els fitxers d’índexs amb l’entrada nova. Passa el mateix en cas d’actualització d’un camp que forma part d’algun índex. El cost de mantenir els fitxers d’índexs és directament proporcional al seu nombre. Per tant, convé eliminar índexs superflus i que no són estrictament necessaris. Vegem-ne alguns casos amb detall:

Índex sobre columnes molt actualitzades

Cal evitar que els índexs tinguin columnes que s’actualitzen molt sovint. La raó és reduir el treball que fa l’SGBD quan es modifica una columna de la taula que forma part d’un índex. L’SGBD actualitza automàticament el contingut de la clau al fitxer d’índex, amb les corresponents actualitzacions de l’arbre d’índex, si s’escau.

<iocstl textG> Exemple d’índex sobre columnes molt actualitzades

  1. Definir un índex sobre la columna saldo de la taula de comptes corrents d’una entitat bancària. Moltes de les operacions bancàries actualitzen la columna saldo. Es tracta d’operacions en línia, molt utilitzades, i que requereixen un bon temps de resposta. Per tant, cal analitzar cada un dels accessos a la base de dades i reduir-los al mínim imprescindible.
  2. Disposar d’un índex sobre la columna saldo implica que totes aquestes transaccions que actualitzen la columna saldo farien una doble actualització, a la taula i al fitxer d’índex. En molts casos resulta prohibitiu, pel cost, que és molt elevat, mantenir l’índex esmentat sobre la columna saldo.</iocstl>

Índexs ascendents o descendents

La majoria dels índexs es defineixen sobre claus en ordre ascendent (opció per omissió). Determinats processos poden necessitar seqüències de claus descendents.

<iocstl textG> Exemples d’índexs ascendents i descendents

Tenim la taula de clients amb un índex definit per fer recerques segons l’edat:

  1. CREATE INDEX ind3 ON clients (data_naixement ASC) .......

Sequential scan: un sequential scan és un procés de lectura seqüencial i massiu de la taula que el mateix SGDB desencadena automàticament.

Suposem que hi ha programes d’aplicació amb els accessos següents:

  1. SELECT
  2. FROM
  3. WHERE
  4. .......
  5. clients
  6. data_naixement = :hv8

I altres programes amb accessos del tipus:

  1. SELECT
  2. FROM
  3. WHERE
  4. ORDER BY
  5. .......
  6. clients
  7. .................
  8. data_naixement DESC

El primer programa farà servir l’índex ind3 perquè qualifica la columna data naixement amb un predicat indexable. El segon programa no pot fer servir l’índex ind3 perquè demana una ordenació decreixent per data de naixement i l’índex ind3 és creixent.

Fixem-nos que en aquest cas n’hi ha prou que modifiqui la definició de l’índex ind3 i el faci decreixent. Serviria per als dos processos anteriors. En el primer procés resulta indiferent el fet que l’índex sigui creixent o decreixent, mentre que en el segon procés és indispensable que l’índex sigui decreixent.

En aquest exemple, si no hi ha cap altra raó que justifiqui que ind3 sigui creixent, el podem transformar en decreixent per solucionar la problemàtica anterior. </iocstl>

Índexs que no fa servir cap programa d’aplicació

Si es detecta que no hi ha cap programa d’aplicació que faci servir un índex determinat, es pot esborrar? Anteriorment hem vist que mantenir qualsevol índex representa un cert cost per a l’SGBD, per tant, cal reduir el nombre d’índexs als estrictament necessaris. No obstant això, hem de pensar que hi ha determinats índexs que són necessaris, malgrat que les aplicacions no els utilitzin directament. Vegem-ne alguns casos:

  1. Un índex únic garanteix la unicitat de les claus. Per exemple, en un índex únic definit sobre la columna DNI de la taula de clients, l’SGBD ens garanteix que a la base de dades no hi ha cap client repetit. Suposem en aquest cas que no hi ha cap programa d’aplicació que accedeixi a la taula de clients a partir del DNI. Resulta temptador eliminar aquest índex que ningú no fa servir. A més a més, es podria pensar que el programa d’aplicació que dóna d’alta els clients a la taula, abans d’inserir un client nou, fes la comprovació per veure si el client ja estava donat d’alta a la taula, i actuar en conseqüència. Malgrat tot aquest raonament, no hem d’oblidar mai que l’SGBD fa el control d’unicitat de claus amb una fiabilitat total, mentre que, si el control es fa des dels programes d’aplicació, resulta més costós, perquè cal desenvolupar un codi nou per a cada cas que es vol controlar, i hi ha la possibilitat de cometre errors.
  2. Índexs d’ús futur. Determinats índexs es defineixen d’acord amb els requeriments expressats pels usuaris. Si un índex determinat no es fa servir avui en dia, pot ser perfectament que es faci servir en el futur, si així s’ha previst en els requeriments dels usuaris. El disseny d’una base de dades no es fa només pensant en les necessitats actuals, sinó preveient les futures.

Exemples d'ús d'índexs

A la pràctica, la diferència entre un accés a base de dades utilitzant, o no, un índex pot ser enorme.

Els índexs són uns elements del disseny físic de la base de dades que tenen com a finalitat millorar el rendiment de les aplicacions quan accedeixen a les taules. Els índexs no formen part del disseny lògic de la base de dades i, per tant, no estan inclosos a l’estàndard SQL.

La definició de la clau primària i de les claus foranes formen part del disseny lògic de la base de dades, i així consten a l’estàndard SQL. En canvi, els índexs que es defineixen per millorar l’accés a les taules, responen a requeriments de rendiment de les aplicacions. Per tant, correspon al disseny físic de la base de dades.

La sentència CREATE INDEX és present a tots els SGBD amb opcions molt similars. A més a més, incorpora clàusules per definir l’espai per a índex i clàusules d’enllaç amb els elements físics propis (els fitxers d’índexs).

PostgreSQL crea índexs per a les claus primàries de totes les taules. Quan calgui crear índexs addicionals, utilitzarem l’expressió de l’exemple següent:

  1. CREATE INDEX persona_nom_index ON Persona ( nom );

La sentència CREATE INDEX és la instrucció proporcionada pel llenguatge SQL per crear índexs.

Té la sintaxi següent:

  1. CREATE INDEX [<nom_esquema>.]<nom_índex>
  2. ON <nom_taula> (col1 [ASC|DESC], col2 [ASC|DESC], ...);

Si no s’especifica el criteri d’ordenació, s’ordena de manera ascendent.

La sentència DROP INDEX és la instrucció proporcionada pel llenguatge SQL per eliminar índexs.

Té la sintaxi següent:

  1. DROP INDEX [<nom_esquema>.]<nom_índex>;

Vegem-ne alguns exemples:

Exemple de creació d’índexs. Taules de l’esquema **empresa**

El dissenyador de les taules de l’esquema empresa va considerar oportú crear els índexs següents:

  1. -- Per tenir els empleats indexats pel cognom:
  2. CREATE INDEX EMP_COGNOM ON EMP (COGNOM);
  3.  
  4. -- Per tenir els empleats indexats pel departament al qual estan assignats:
  5. CREATE INDEX "EMP_DEPT_NO+EMP" ON EMP (DEPT_NO,EMP_NO);
  6.  
  7. -- Per tenir els clients indexats pel nom:
  8. CREATE INDEX CLIENT_NOM ON CLIENT (NOM);
  9.  
  10. -- Per tenir els clients indexats pel representant (+ codi de client):
  11. CREATE INDEX "CLIENT_REPR+CLI" ON CLIENT (REPR_COD, CLIENT_COD);
  12.  
  13. -- Per tenir les comandes indexades per la data (+ número de comanda):
  14. CREATE INDEX "COMANDA_DATA+NUM" ON COMANDA (COM_DATA, COM_NUM);
  15.  
  16. -- Per tenir les comandes indexades per la data de tramesa (+ número de comanda):
  17. CREATE INDEX COMANDA_DATA_TRAMESA ON COMANDA (DATA_TRAMESA);
  18.  
  19. -- Per tenir les línies de detall indexades per producte (+ comanda + número de línia):
  20.  
  21. CREATE INDEX "DETALL_PROD+COM+DET"
  22. ON DETALL (PROD_NUM,COM_NUM,DETALL_NUM);

Fixem-nos que, en els casos en què es vol que el nom contingui el símbol +, cal indicar-ho entre cometes dobles.

Tots aquests índexs s’afegeixen als existents a causa de les restriccions de clau primària i d’unicitat. La figura mostra tots els índexs definits en l’esquema empresa.

Optimitzador del SGBD

En cada un dels accessos a taules que té programat una aplicació, l’optimitzador de l’SGBD analitza quin és el millor camí d’accés a la base de dades. L’anàlisi es fa durant el procés de construcció del pla d’accés (en anglès, BIND plan).

L’optimitzador fa l’anàlisi tenint en compte els elements següents:

  • Els índexs que s’han definit a cada taula.
  • Les dades estadístiques sobre el nombre de files, i el nombre de claus de cada índex. Aquestes dades estadístiques, cal generar-les periòdicament i emmagatzemar-les al catàleg de l’SGBD.
  • La cardinalitat de les claus de cada índex.
  • El nombre de files que l’SGBD preveu que haurà d’explorar per satisfer la instrucció SQL.
  • El nombre resultant de files afectades per l’accés SQL.
  • Etc.

L’optimitzador de l’SGBD tria quin creu que és el camí òptim d’accés a la taula. L’optimitzador entén com a òptim l’accés que preveu que tindrà un cost inferior, quant a consum de recursos (temps de CPU) i un temps de resposta millor. En molts casos, aquesta tria comporta fer servir algun dels índexs definits per a la taula.

Anar a la pàgina anterior:
Exercicis