Please enable JavaScript.

Coggle requires JavaScript to display documents.

SQL (stored procedures (have a security benefit in that you can grant…

- - - - to struktura danych używana w systemach zarządzania bazami danych do efektywnego wyszukiwania, wstawiania, usuwania i sortowania danych. B-drzewo jest zrównoważoną strukturą drzewiastą, która pozwala na szybkie wykonywanie operacji na dużych zbiorach danych. Indeksy B-drzewa są najczęściej używanym typem indeksów w relacyjnych bazach danych.
      - operacje wyszukiwania, wstawiania i usuwania mają złożoność O(log n).
      - B-drzewo wspiera operacje zakresowe (<, >, BETWEEN) oraz sortowanie (ORDER BY), co czyni je wszechstronnym narzędziem do optymalizacji zapytań.
    - - Używa funkcji haszującej do mapowania wartości indeksu na pozycje w tabeli. Indeksy haszowe są bardzo szybkie przy dokładnych wyszukiwaniach, ale nie wspierają operacji zakresowych.
      - CREATE INDEX idx_username_hash ON Users USING hash (Username);
      - Kolizje haszowe:
        W przypadku dużych zbiorów danych istnieje ryzyko kolizji haszowych, gdzie różne wartości kolumny przekształcają się na ten sam hasz. Kolizje muszą być odpowiednio obsłużone, co może wprowadzać dodatkową złożoność.
      - Indeksy haszowe nie wspierają operacji sortowania (ORDER BY), co ogranicza ich zastosowanie w zapytaniach wymagających uporządkowania wyników.
      - W systemach przetwarzających bardzo duże zbiory danych, gdzie kluczowe są szybkie wyszukiwania dokładnych wartości, indeksy haszowe mogą znacząco poprawić wydajność.
    - - specjalny rodzaj indeksu używany w systemach baz danych do efektywnego wyszukiwania tekstu w dużych zbiorach danych tekstowych. Indeksy pełnotekstowe są zoptymalizowane pod kątem przeszukiwania wolnych tekstów, takich jak dokumenty, wiadomości e-mail, artykuły, opisy produktów i inne dane tekstowe, które mogą zawierać setki lub tysiące słów.
      - Indeksy pełnotekstowe pozwalają na szybkie wyszukiwanie słów i fraz w dużych zbiorach danych tekstowych, znacznie przyspieszając operacje wyszukiwania w porównaniu do prostych wyszukiwań z użyciem klauzuli LIKE.
      - Umożliwiają zaawansowane zapytania tekstowe, takie jak wyszukiwanie słów kluczowych, wyszukiwanie przybliżone, wyszukiwanie z użyciem operatorów logicznych (AND, OR, NOT), wyszukiwanie fraz, sortowanie wyników według trafności (relevance) i wiele innych.
      - Tokenizacja i normalizacja tekstu:
        Indeksy pełnotekstowe zazwyczaj wykonują tokenizację (podział tekstu na słowa) i normalizację (usuwanie znaków przestankowych, konwersja do małych liter itp.) tekstu, aby poprawić wydajność i dokładność wyszukiwania.
      - CREATE FULLTEXT INDEX idx_content ON Articles (Title, Content); SELECT * FROM Articles WHERE MATCH(Title, Content) AGAINST('database indexing');
      - Indeks pełnotekstowy zazwyczaj składa się z tabeli odwrotnych, gdzie słowa są mapowane na listy dokumentów, które zawierają te słowa.
    - - specjalny rodzaj indeksu używanego do zarządzania danymi przestrzennymi w bazach danych, które zawierają informacje geograficzne lub geometryczne.
      - Używany w bazach danych przestrzennych do przyspieszenia zapytań przestrzennych, takich jak wyszukiwanie punktów w obszarze, współrzędne geograficzne, kształty i inne obiekty geometryczne.
      - Indeksy przestrzenne są zoptymalizowane do obsługi zapytań dotyczących obiektów geometrycznych, takich jak punkty, linie i wielokąty, oraz operacji przestrzennych, takich jak wyszukiwanie punktów w określonym obszarze, znajdowanie najbliższych sąsiadów, czy sprawdzanie przecięć geometrycznych.
      - Typy indeksów przestrzennych:
        
        Indeks R-drzewa (R-tree):
        
        Najpopularniejszy typ indeksu przestrzennego, który używa struktury drzewiastej do indeksowania obiektów geometrycznych. R-drzewa dzielą przestrzeń na hierarchiczne przedziały (prostokąty), które zawierają obiekty geometryczne.
        
        Indeks kwadratowy (Quad-tree):
        
        Indeks dzieli przestrzeń na cztery kwadraty (lub prostokąty) i rekurencyjnie dzieli każdy kwadrat na mniejsze kwadraty, aż do osiągnięcia pewnego poziomu szczegółowości. Jest używany głównie do indeksowania danych 2D.
        
        Indeks siatkowy (Grid index):
        
        Przestrzeń jest podzielona na regularną siatkę komórek, a każda komórka zawiera listę obiektów geometrycznych, które do niej należą. Indeksy siatkowe są proste i szybkie w użyciu, ale mogą być mniej efektywne dla dużych zbiorów danych.
    - - Indeks, który zawiera wszystkie kolumny potrzebne do odpowiedzi na zapytanie, eliminując konieczność dodatkowego dostępu do danych tabeli. Może znacznie poprawić wydajność zapytań, które mogą być obsługiwane w całości przez indeks.
    - - Indek, który przechowuje wskaźniki tylko dla podzbioru wierszy w tabeli spełniających określone kryterium (filtr). Może znacznie poprawić wydajność zapytań operujących na wąsko zdefiniowanych podzbiorach danych.
  - - - has WHERE keyword
      - only contains rows that meet WHERE condition
      - only allowed with non-clustered indexes as clustered need to contain all of the data
  - - - Bardzo wydajne wyszukiwanie i sortowanie.
      - Szybsze operacje odczytu dla zapytań zakresowych (BETWEEN, <, >).
      - Wyszukiwanie danych na podstawie indeksu klastrowanego jest szybkie, ponieważ indeks bezpośrednio wskazuje na dane
    - - Wstawianie, aktualizowanie i usuwanie danych może być wolniejsze, ponieważ wiersze muszą być fizycznie przesuwane w celu zachowania uporządkowania danych.
      - Przeprojektowanie indeksu klastrowanego może być kosztowne, zwłaszcza w przypadku dużych tabel.
    - - B-tree clustered index
  - - - Indeksy zajmują dodatkowe miejsce na dysku, co może być znaczące w przypadku dużych tabel.
    - - Operacje wstawiania (INSERT), aktualizacji (UPDATE) i usuwania (DELETE) mogą być wolniejsze, ponieważ indeksy muszą być aktualizowane za każdym razem, gdy dane są modyfikowane.
    - - Zarządzanie wieloma indeksami może być złożone, a nieoptymalne indeksowanie może prowadzić do obniżenia wydajności.
- - - - Zawiera metadane dotyczące strony, takie jak typ strony, identyfikator strony, stan strony (wolne miejsce, zajętość), informacje o transakcjach, itp.
    - - Strona zawiera wiele wierszy danych, które są rzeczywistymi rekordami przechowywanymi w tabeli. Każdy wiersz danych zawiera kolumny tabeli.
    - - Na końcu strony znajduje się tablica offsetów, która wskazuje lokalizacje poszczególnych wierszy na stronie. Tablica ta pomaga DBMS w szybkim dostępie do konkretnych wierszy.
- - - - pessimistic
        
        is when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks. To use pessimistic locking you need either a direct connection to the database (as would typically be the case in a two tier client server application) or an externally available transaction ID that can be used independently of the connection.
        In the latter case you open the transaction with the TxID and then reconnect using that ID. The DBMS maintains the locks and allows you to pick the session back up through the TxID. This is how distributed transactions using two-phase commit protocols (such as XA or COM+ Transactions) work.
    - - optimistic
        
        Optimistic assumes that nothing's going to change while you're reading it
        
        is a strategy where you read a record, take note of a version number (other methods to do this involve dates, timestamps or checksums/hashes) and check that the version hasn't changed before you write the record back.If the record is dirty (i.e. different version to yours) you abort the transaction and the user can re-start it.
  - - - Multi-Version Concurrency Control
      - This mechanism tries to reduce locking to a bare minimum so that: Readers don’t block Writers and Writers don’t block Readers
        The only use case that can still generate contention is when two concurrent transactions try to modify the same record since, once modified, a row is always locked until the transaction that modified this record either commits or rolls back.
      - In order to specify the aforementioned Reader/Writer non-locking behavior, the Concurrency Control mechanism must operate on multiple versions of the same record, hence this mechanism is called Multi-Version Concurrency Control (MVCC).
      - https://vladmihalcea.com/how-does-mvcc-multi-version-concurrency-control-work/ - good explanation
      - Initially, all database systems employed 2PL for implementing Serializable transactions, but, with time, many vendors have moved towards MVCC (Multi-Version Concurrency Control) concurrency control mechanisms. Nowadays, only SQL Server uses the 2PL algorithm by default.
    - - The 2PL protocol splits a transaction into two sections.
        
        expanding phase (locks are acquired, and no lock is allowed to be released)
        
        shrinking phase (all locks are released, and no other lock can be further acquired).
      - For a database transaction, the expanding phase means that locks are allowed to be acquired from the beginning of the transaction until its end, while the shrinking phase is represented by the commit or rollback phase, as at the end of a transaction, all the acquired locks are being released.
      - The 2PL algorithm offers Strict Serializability, which is the golden standard when it comes to data integrity. Strict Serializability means that the outcome is both Serializable and Linearizable.
      - The 2PL (Two-Phase Locking) algorithm is one of the oldest concurrency control mechanisms used by relational database systems to guarantee data integrity.
      - Some database systems, like PostgreSQL, MySQL, or SQL Server, offer the possibility of acquiring read and write locks on a given tuple or range of tuples. Other database systems, like Oracle, only allow write/exclusive locks to be acquired via the FOR UPDATE clause.
      - 2PL protocol defines a lock management strategy for ensuring strict serializability.
      - Let's assume that Both Alice and Bob acquire a read lock on a given 'post' record via a SELECT FOR SHARE PostgreSQL clause.
        When Bob attempts to execute an UPDATE statement on the post entry, his statement is blocked by the Lock Manager because the UPDATE statement needs to acquire a write lock on the post row while Alice is still holding a read lock on this database record.
        Only after Alice’s transaction ends and all her locks are being released, Bob can resume his UPDATE operation.
        Bob’s UPDATE statement will generate a lock upgrade, so his previously acquired read lock is replaced by an exclusive lock, which will prevent other transactions from acquiring a read or write lock on the same post record.
        If Alice starts a new transaction and issues a SELECT FOR SHARE query with a read lock acquisition request for the same post entry, the statement is blocked by the Lock Manager since Bob owns an exclusive lock on this record.
        After Bob’s transaction is committed, all his locks are released, and Alice’s SELECT query can be resumed.
        example
      - When using 2PL, every read requires a shared lock acquisition, while a write operation requires taking an exclusive lock.
  - - - A read or share lock prevents a resource from being written while allowing other concurrent reads.
    - - A write or exclusive lock disallows both read and write operations on a given resource.
- - - - If the currently running transaction rolls back, the undo log will be used to reconstruct the in-memory pages as of the start of the transaction.
      - While this structure is called undo log in Oracle and MySQL, in SQL Server, the transaction log plays this role. PostgreSQL does not have an undo log, but the same goal is achieved with a multi-version table structure since tables can store multiple versions of the same row. However, all these data structures are used to provide rolling back capability which is a mandatory requirement for Atomicity.
      - Because the in-memory changes can be accessed by multiple concurrent transactions, a Concurrency Control mechanism (e,g, 2PL and MVCC) must be employed so to ensure data integrity. Therefore, once a transaction has modified a table row, the uncommitted changes are applied to the in-memory structures while the previous data is temporarily stored in an undo log append-only structure.
    - - Once a transaction commits, the in-memory changes must become persisted. However, that does not mean that every transaction commit will trigger an fsync (flush). In fact, that would be very detrimental to application performance. However, from the ACID transaction properties, we know that a committed transaction must provide Durability, meaning that committed changes need to be persisted even if we unplug the database engine.
      - So, how does a relational database provide Durability without issuing an fsync on every transaction commit?
        That’s where the redo log comes into play. The redo log is also an append-only disk-based structure that stores every change a given transaction has undergone. So, when a transaction commits, every data page change will be written to the redo log as well. Compared to flushing an invariable number of data pages, writing to the redo log is very fast since sequential disk access is way faster than Random access. Hence, it also allows transactions to be fast.
      - While this structure is called redo log in Oracle and MySQL, in SQL Server, the transaction log plays this role as well. PostgreSQL calls it Write-Ahead Log (WAL) instead.
      - When are the in-memory changes flushed to the disk?
        A relational database system uses checkpoints to synchronize the in-memory dirty pages with their disk-based counterparts. To avoid congesting the IO traffic, the synchronization is usually done in chunks during a larger period of time.
  - - - Po awarii prądu, gdy system zostanie ponownie uruchomiony, DBMS zaczyna proces odzyskiwania (recovery).
    - - DBMS odczytuje dziennik transakcji, aby zidentyfikować wszystkie transakcje, które zostały zatwierdzone (COMMIT) przed awarią. Dziennik transakcji zawiera wpisy, które szczegółowo opisują zmiany wprowadzone przez każdą transakcję.
    - - DBMS wykonuje operację "redo" dla wszystkich zatwierdzonych transakcji. Oznacza to, że ponownie stosuje zmiany zapisane w dzienniku transakcji do danych w bazie danych, aby upewnić się, że wszystkie zmiany są prawidłowo odzwierciedlone na dysku.
    - - DBMS wykonuje operację "undo" dla wszystkich transakcji, które nie zostały zatwierdzone przed awarią. Oznacza to, że wycofuje wszelkie zmiany wprowadzone przez te transakcje, aby przywrócić spójność bazy danych.
    - - Idempotentne operacje redo:
        
        Operacje redo są idempotentne, co oznacza, że wielokrotne zastosowanie tej samej operacji ma ten sam efekt, co pojedyncze zastosowanie. Dzięki temu, jeśli operacja jest stosowana ponownie podczas procesu redo, nie zmienia to stanu danych, jeśli operacja została już zastosowana wcześniej.
      - Zapisywanie nagłówka strony (Page Header):
        
        Każda strona danych w bazie danych zawiera nagłówek, który przechowuje informacje takie jak numer LSN (Log Sequence Number) ostatniej operacji, która została zastosowana do tej strony. DBMS używa LSN do śledzenia i kontrolowania, które operacje z dziennika transakcji zostały już zastosowane do danej strony.
      - LSN (Log Sequence Number):
        
        LSN jest unikalnym identyfikatorem dla każdej operacji w dzienniku transakcji. Podczas procesu redo, DBMS porównuje LSN zapisane w nagłówku strony z LSN w dzienniku transakcji. Jeśli operacja ma LSN mniejsze lub równe temu, które jest już zapisane w nagłówku strony, operacja jest pomijana, ponieważ została już zastosowana.
  - - - kluczowy komponent systemu zarządzania bazą danych (DBMS), odpowiedzialny za zarządzanie wszystkimi aspektami transakcji w systemie.
      - Menedżer transakcji inicjuje nowe transakcje oraz zapewnia prawidłowe zakończenie transakcji przez operacje COMMIT (zatwierdzenie) lub ROLLBACK (wycofanie).
    - - Atomowość (Atomicity): Gwarantuje, że wszystkie operacje w transakcji są wykonane w całości lub wcale. Jeśli którakolwiek operacja w transakcji zawiedzie, cała transakcja jest wycofywana.
      - Spójność (Consistency): Zapewnia, że transakcje przekształcają bazę danych z jednego spójnego stanu w inny spójny stan.
      - Izolacja (Isolation): Gwarantuje, że jednoczesne wykonywanie transakcji nie powoduje niezgodności danych. Każda transakcja działa w izolacji od innych.
      - Trwałość (Durability): Zapewnia, że po zatwierdzeniu transakcji jej wyniki są trwałe i zachowane nawet w przypadku awarii systemu.
    - - Zarządzanie rozpoczęciem i zakończeniem transakcji:
      - Zapewnienie właściwości ACID:
      - Zarządzanie dziennikiem transakcji (Transaction Log):
      - Obsługa blokad i zarządzanie współbieżnością: Menedżer transakcji zarządza mechanizmami blokowania, które są używane do kontrolowania dostępu do danych przez równocześnie wykonywane transakcje. Zapewnia to izolację transakcji i unikanie konfliktów.
      - Odzyskiwanie po awarii (Recovery):
        Menedżer transakcji koordynuje proces odzyskiwania danych po awarii, wykorzystując dziennik transakcji do ponownego zastosowania zatwierdzonych transakcji (redo) oraz wycofania niezatwierdzonych transakcji (undo).
- - - - this can be easily broken when dealing with distributed computing, e.g. having 2 databases - one for reads only and one for updates and reads. When two clients connect to them and retrieve e.g. bank account balance, but then first client submits withdrawal operation but this change wasn't replicated to the second (read-only) database yet, we may be left in inconsistent state when trying to perform the same operation with second client which still thinks sees stale data.
      - this can be fixed with expanding transaction to 2 databases, but this quickly becomes unmaintainable if response time is a problem or some nodes are down. For this reason, in a distributed system, a consensus protocol like Paxos or Raft is a much better alternative to provide linearizability.
    - - Linearizability is not limited to distributed systems and databases. When using Java, reads and writes are not guaranteed to be linearizable unless the modifying variable is volatile or if both the write and the read are executed from within a synchronized block.
      - Because most computer systems use multiple CPU cores, and each core has its own cache, a write operation might only change the variable in the CPU cache. For the change to propagate to the main memory, the write-behind CPU cache needs to be flushed, and that’s exactly what the volatile keyword actually does.
- - - - Atomicity (all-or-nothing)
        
        Atomicity takes individual operations and turns them into an all-or-nothing unit of work, succeeding if and only if all contained operations succeed.
        
        A transaction might encapsulate a state change (unless it is a read-only one). A transaction must always leave the system in a consistent state, no matter how many concurrent transactions are interleaved at any given time.
      - Consistency (validation)
        
        Consistency means that constraints are enforced for every committed transaction. That implies that all Keys, Data types, Checks and Trigger are successful and no constraint violation is triggered.
      - Isolation (revert-on-fail)
        
        Transactions require concurrency control mechanisms, and they guarantee correctness even when being interleaved. Isolation brings us the benefit of hiding uncommitted state changes from the outside world, as failing transactions shouldn’t ever corrupt the state of the system. Isolation is achieved through concurrency control using pessimistic or optimistic locking mechanisms.
        
        isolation levels
        
        READ_UNCOMMITTED
        
        Normally, the Read Uncommitted isolation level is rarely needed (non-strict reporting queries where dirty reads are acceptable), so Read Committed is usually the lowest practical isolation level.
        
        If you have a transaction that runs a batch processing task and you want to know its progress, you could start a new transaction in the Read Uncommitted isolation level and due to Dirty Reads, you will see how much progress the other transaction has done.
        
        READ_COMMITTED
        
        REPEATABLE_READ
        
        SERIALIZABLE
        
        The Isolation Level (I in ACID) allows you to trade off data integrity for performance. The weaker the isolation level, the more anomalies can occur, and in this article
        
        anomalies
        
        dirty read
        
        diagram and second
        
        This anomaly is only permitted by the Read Uncommitted isolation level, and, because of the impact on data integrity, most database systems offer a higher default isolation level
        
        A dirty read happens when a transaction is allowed to read uncommitted changes of some other running transaction. This happens because there is no locking preventing it. In the picture above, you can see that the second transaction uses an inconsistent value as of the first transaction had rolled back.
        
        Each transaction is allowed to see its own changes because otherwise the read-your-own-writes consistency guarantee is compromised.
        
        When the underlying database uses MVCC (Multi-Version Concurrency Control), the database engine can use the undo log which already captures the previous version of every uncommitted record, to restore the previous value in other concurrent transaction queries.
        
        Phantom read
        
        diagram
        
        A phantom read happens when a second transaction inserts a row that matches a previous select criteria of the first transaction. We, therefore, end up using stale data, which might affect our business operation. This is prevented using range locks or predicate locking.
        
        If a transaction makes a business decision based on a set of rows satisfying a given predicate, without range locks, a concurrent transaction might insert a record matching that particular predicate. This phenomenon is problematic when the current transaction makes a business decision based on the first version of the given result set.
        
        diagram 2
        
        The SQL standard says that Phantom Read occurs if two consecutive query executions render different results because a concurrent transaction has modified the range of records in between the two calls
        
        Nevertheless, preventing this anomaly is fairly simple. All you need to do is use a higher isolation level like Serializable. Or, if the underlying RDBMS supports predicate locks, you can simply lock the range of records using a share (read) lock or an exclusive (write) range lock as explained in this article.
        
        This phenomenon is typical for both Read Uncommitted, Read Committed and Repeatable Read isolation levels. The default isolation level being either Read Committed (Oracle, SQL Server or PostgreSQL) or Repeatable Read (MySQL) does not prevent this anomaly.
        
        Non-repeatable read
        
        A non-repeatable read manifests when consecutive reads yield different results due to a concurring transaction that has just updated the record we’re reading. This is undesirable since we end up using stale data. This is prevented by holding a shared lock (read lock) on the read record for the whole duration of the current transaction.
        
        diagram and second_diagram
        
        If one transaction reads a database row without applying a shared lock on the newly fetched record, then a concurrent transaction might change this row before the first transaction has ended.
        
        This phenomenon is problematic when the current transaction makes a business decision based on the first value of the given database row (a client might order a product based on a stock quantity value that is no longer a positive integer).
        
        If a database uses a 2PL (Two-Phase Locking) and shared locks are taken on every read, this phenomenon will be prevented since no concurrent transaction would be allowed to acquire an exclusive lock on the same database record. If DB uses MVCC then by verifying the current row version, a transaction can be aborted if a previously fetched record has changed in the meanwhile.
        
        Repeatable Read and Serializable prevent this anomaly by default. With Read Committed, it is possible to avoid non-repeatable (fuzzy) reads if the shared locks are acquired explicitly (e.g. SELECT FOR SHARE).
        
        This phenomenon is typical for both Read Uncommitted and Read Committed isolation levels. The problem is that Read Committed is the default isolation level for many RDBMS like Oracle, SQL Server or PostgreSQL, so this phenomenon can occur if nothing is done to prevent it.
        
        Nevertheless, preventing this anomaly is fairly simple. All you need to do is use a higher isolation level like Repeatable Read (which is the default in MySQL) or Serializable. Or, you can simply lock the database record using a share(read) lock or an exclusive lock if the underlying database does not support shared locks (e.g. Oracle).
      - Durability
        
        A successful transaction must permanently change the state of a system, and before ending it, the state changes are recorded in a persisted transaction log. If our system is suddenly affected by a system crash or a power outage, then all unfinished committed transactions may be replayed.
- - - - CMD Parser
        
        Data once received from Protocol Layer is then passed to Relational Engine. “CMD Parser” is the first component of Relational Engine to receive the Query data. The principal job of CMD Parser is to check the query for Syntactic and Semantic error. Finally, it generates a Query Tree
        
        Semantic check:
        This is performed by Normalizer.
        In its simplest form, it checks whether Column name, Table name being queried exist in Schema. And if it exists, bind it to Query. This is also known as Binding.
      - Optimizer
        
        The Optimizer works to ensure that a requested Query Response is as efficient as possible by eliminating redundant tasks and finding the optimal plan. It does not, however, guarantee that a certain plan is the optimal one.
      - Query Executor
        
        The query executor produces the data fetching logic’s behaviour when the Storage Engine delivers the data to the Protocol layer. When the Storage Engine supplies data to the Executor, the behaviour is published to the Protocol layer. After the behaviour is published, the final data is given to the user.
  - - - It acts as an interface between query executor and Buffer Manager/Transaction Logs.
        Access Method itself doe\s not do any execution.
      - Depending upon the result, the Access Method takes the following steps:
        If the query is DDL, SELECT statement, the query is pass to the Buffer Manager for further processing.
        And if query if DDL, NON-SELECT statement, the query is pass to Transaction Manager. This mostly includes the UPDATE statement.
- - - - index scan is where SQL server reads the whole of the index looking for matches - the time this takes is proportional to the size of the index.
      - in certain situations an index scan can be faster than an index seek (sometimes significantly faster) - usually when the table is very small, or when a large percentage of the records match the predicate.
      - When SQL Server does a scan it loads the object which it wants to read from disk into memory, then reads through that object from top to bottom looking for the records that it needs.
    - - index seek is where SQL server uses the b-tree structure of the index to seek directly to matching records time taken is only proportional to the number of matching records.
      - In general an index seek is preferable to an index scan (when the number of matching records is proprtionally much lower than the total number of records), as the time taken to perform an index seek is constant regardless of the toal number of records in your table.
      - When SQL Server does a seek it knows where in the index that the data is going to be, so it loads up the index from disk, goes directly to the part of the index that it needs and reads to where the data that it needs ends.
    - - When SQL Server is looking for your data probably one of the largest things which will make SQL Server switch from a seek to a scan is when some of the columns are you looking for are not included in the index you want it to use. Most often this will have SQL Server fall back to doing a clustered index scan, since the Clustered index contains all the columns in the table. This is one of the biggest reasons (in my opinion at least) that we now have the ability to INCLUDE columns in an index, without adding those columns to the indexed columns of the index. By including the additional columns in the index we increase the size of the index, but we allow SQL Server to read the index, without having togo back to the clustered index, or to the table it self to get these values.